Knowledge Reflections (1):
Lessons From The Past
David J. Skyrme
"We learn from others, but we also learn from our own experiences"
So writes Esko Kilpi, founder of a Finnish knowledge management consultancy, in setting the scene for ENTOVATION's Spring Meeting open seminar at Helsinki's Lifelong Learning Institute Dipoli.
As preparation for this meeting he has forced those presenting to "sense and reflect" about our involvement with knowledge management over the last decade or so.
I will cover sensing - discerning insights into where knowledge management has come from and where it is heading - in a future article.
In this article I share some reflections, which although from a consultant's perspective apply equally to those who are internal consultants or active in using knowledge management to achieve organizational benefits.
A commonly mentioned technique in the knowledge manager's toolkit is lessons learned.
Even though many organizations pay lip service to this, my experience suggests that it is often not taken seriously.
For example, many project management methodologies call for post project reviews at the end of the project, yet I have had to remind clients about following their own approved procedures.
Even where lessons are documented, how much use is made of them? Several things can be done to make them more accessible:
- Create well-structured and interesting knowledge assets - a common format helps create familiarity; it also lends itself to tagging sections with attributes that aid retrieval; adding a video clip of a real situation brings home an important point.
- Provide relevant contextual material - a lesson should be put into its context; an abstract should explain its essence and where it is applicable - what problem? what organizational context? to achieve what objective? and so on.
Provide a structure (or metadata) for users (and search/retrieval tools) to filter relevant lessons (see the example of Beep in Knowledge Digest).
- Provide pointers to people - some of the best knowledge transfer takes place not through reading passive assets, but through active knowledge exchange.
This can be through communities of practice, but also from direct pointers to experts from the relevant lessons.
- Encourage user feedback - how often do you change your buying decisions (e.g. on Amazon.com) after you read what your peers have said.
For lessons learned this can go further in that additional experiences can be used to update the authoritative guidance.
- Build the lessons into your business processes and guidance - in the military (the originator of After Action Reviews and a strong advocate of lessons learned), lessons are analyzed and later reflected in updated doctrine, plans and procedures.
In your organization, do system and process owners systematically review feedback and lessons, and update their offerings and guidance? Do training course use the latest 'best practice'?
- Put in approval 'triggers' - one way of ensuring that knowledge is re-used is to ask for evidence of consulting lessons learned when approval is sought for an initiative, such as a new product development or marketing campaign.
Now put this organizational approach into your personal context? When you plan an intervention or assignment, are you truly drawing on your vast reservoir of knowledge resources?
This is where reflection can help. But you have to make time for it. As Esko says:
"Often we do not have sufficient time to process those learning experiences."
I've taken the time, and what follows are some of my personal learnings.
Patterns in the Past
Two strong patterns stand out. The first is that the nature of knowledge management assignments is changing.
This is a reflection of both the growing general understanding of the subject, but also of the increased pressure to "show results".
People today don't want the theory, they want the practical tools, techniques, the "how-tos", the pitfalls to avoid.
And they want evidence of bottom line impact.
They also want help in integrating knowledge management into day-to-day activities, into operational systems and into the core of the business: "if knowledge management is to get my attention, it must help real people in real jobs" was how one of my clients expressed it.
The other pattern is the different needs at different levels of maturity within an organization - or part of one.
For every organization that is high up the maturity curve, others are just starting, while some "forget what they knew" (as their knowledge pioneers move on) and need to re-invigorate their programme and go back down the curve.
And all the time new techniques and situations emerge and the technology moves on so what was maturity yesterday is not so today.
The three main stages, and requirements that I discern are:
- Getting started - a formal programme or project (not necessarily called knowledge management).
At this stage clients want some inputs as to what to do. They want some analysis of needs, diagnosis of problems.
They may need help with justifying investment. They need a roadmap forward - a viable strategy and plan with resources, milestones and deliverables.
What they also need - but often do not realize it - is greater clarity of the issues.
Here knowledge audits, KM assessments (see for example, the Know-All tool and discovery workshops with multiple stakeholders can often yield valuable insights into the baseline from which they are starting.
- Expanding - KM is rolling out beyond the pilot stage. If the plans are working out OK, most teams take ownership and pride in what they are doing.
They may want an independent expert to give them a check that they are on course and ask for suggestions of improvement, but regular involvement will be minimal.
Those striving to be the best will want help with benchmarking and may need periodic reassessments of progress.
It is the 'stalled initiatives', the impenetrable barriers and where expectations have not been met that help is often needed.
Usually these are beyond and above knowledge management where high level consultancy skills come into their own.
Even if you know that your own organization is "screwed up" it is sometimes better to engage an external messenger to deliver the message.
- Integration - KM is increasingly integrated into the business. At this stage organizations seek peer review and learning partners.
They want to cocreate new opportunities, often with others in their supply and customer network.
KM specializations are less important than connections and communities (though as noted earlier, other parts of an organization or other aspects of its KM is likely to be at earlier stages of the maturity curve).
There are of course, other patterns, mostly related to the current "flavour of the month" - employee portals, content management, communities, taxonomies and other aspects of knowledge management have received special attention (and investment) at the appropriate time.
The Consultant's Knowledge Role and Added Value
A consultant has knowledge and skills, but the roles that they play in every assignment are different.
I've identified several roles, shown below roughly in order of client involvement and personal challenge and satisfaction for the consultant:
- Knowledge transmitter - the client just want to be told what to do; they may just throw a few documents at you and give you a couple of interviews; but in this mode you don't get under the skin of the organization.
Will they act on what you tell (or toss over the wall at) them?
- Knowledge source - they see you as an expert and just want to pump you for your knowledge.
You may give a presentation or run a workshop, but they will ask lots of questions, the context of which is not immediately clear to you, so your answers may be off the mark for their particular situation.
- Knowledge lens - the client wants a new perspective on their problem. You may bring them experience from another industry or another discipline. This can give them valuable insights and new ideas to pursue.
- Knowledge refiner / synthesizer - many 'studies' take this form. The organization has much of the knowledge it needs to move forward. It's your job to pull it all together and to put it in context with external exemplars.
You are helping "make sense of a mess" and make recommendations for action.
- Knowledge bridge - building on the previous role, this more tightly knits the contribution of knowledge into value for the organization.
As well as building bridges between KM and the business, other bridges that often need spanning with outside help are those between the technologists and their users, process-focussed people with creativity/opportunistic people, financial analysts and sales functions and so on.
- Facilitator - a good facilitator can harness the wealth of knowledge that exists. Further they will engender a sense of ownership by those involved, by helping them arrive at a jointly developed solution.
- Business partner - in this role, you really are part of the team, not an outsider. You live your talk. You put your recommendations into practice.
As such you have a real stake in the outcome - internal consultants may be rewarded according to the success of the business; external consultants may have a financial stake in a joint venture.
- Mentor / coach - typically a one-to-one business (and increasingly personal) relationship with a senior manager. You are his or her 'sounding board' and special advisor.
As you move through the roles they become less knowledge domain based and more skills based.
Also, an increasing proportion of the knowledge transfer takes place through face-to-face involvement and not through documents (which in the earlier roles are in danger of becoming "shelfware").
One of the problems is that roles and expectations are often not clear at the outset.
Clients' "terms of reference" describe problems and business requirements, often without specifying the processes and role expected (this can be useful since it gives you discretion).
Internally, where formal transactions are not involved, even the general terms of reference are often unclear.
It is important early in the process to tease out and clarify expectations ("what is a successful outcome to this piece of work?") and to understand the 'culture' of the organization and the 'chemistry' of key stakeholders.
What unexpressed needs do your clients really want addressed from your involvement? What is your added value? It is likely to be some combination of the following:
- An extra body, an extra mind (they weren't allowed to hire anyone but were short of people!)
- New knowledge, new perspectives (much fed in through the different roles above)
- New connections - your wide network of contacts may be highly useful to them
- Ability to clarify the problem and identify opportunities
- Rationalizing their intuitions - you provide solid data to support a business case
- Prioritization and planning - you show a road map and guide them to activities that give the best return on investment
- Objectivity - a consultant is relational and logical, are they not?
- A change agent - you overcome the problem of a "prophet in their own land"
- Someone to blame when things go wrong!
Over a long period of KM consulting, I have found little need to revise the seven critical success factors identified in the 1997 study Creating the Knowledge-based Business (coauthored with Debra Amidon) for a knowledge initiative, viz.:
Strong link to a business imperative
A compelling vision of the role of knowledge and a viable KM architecture
Knowledge leadership - champions and active senior level sponsorship
A knowledge creating and sharing culture - openness, readiness to experiment, take risks etc.
Well developed information and communications systems - a good infrastructure (e.g. intranet) and set of KM tools
Systematic organizational knowledge processes - for discovering, gathering, organizing, retrieving, disseminating, protecting etc.
Continuous learning - back to lessons learned, both within any KM initiative and the wider organization.
As a consultant you are constantly checking to see that these essential ingredients are in place - or warn of the consequences. More subtly, you are keeping a wary eye out for the pitfalls.
What Doesn't Work - Common Pitfalls
Here is my list of ten recurring pitfalls (do we ever learn?):
IT is seen as the solution - how often is it only after the IT has been bought that it suddenly dawns that changed processes, user training and even extra content creators and editors are needed?
Narrow, often single perspective - an HR person may see KM only from a people lens; an IT person only a technical solution. A holistic perspective is needed.
Fragmentation - not only is knowledge dispersed, but there have been many times when I have discovered existing related (even almost identical) projects of which my client was unaware.
Do you have an up to date internal projects database?
Mechanistic - clients who want the 'tick box' or step-by-step approach. Knowledge management isn't like that. Flexible frameworks are the order of the day.
Impatience for a 'quick fix'. Changing organization structures, processes and especially cultures and behaviours takes time (often several years). But if a good audit has taken place, there are usually several achievable 'quick wins' that contribute to the long-term aims.
No time, wrong time! People must make time to make changes or to embed KM. If people can't book time to KM activities (under whatever heading!) then commitment is lacking. Also consider carefully who has the time (or will make the time) to carry out your KM plans?
Organization in chaos. A particularly bad time to start almost any KM initiative is when an organization is in turmoil or the middle of restructuring or downsizing. Other things are on people's minds - perhaps even your own if jobs are at stake.
Use the time to refresh your knowledge or update your personal intellectual capital inventory (see I3 UPDATE No. 57).
The management 'nod'. Your plans are approved and everyone agrees them, but nothing happens. There is a distinct difference between approach and commitment.
Senior management must genuinely feel pain or the opportunity to gain to be committed. That's part of the 'selling' of KM that is needed (see Making the Business Case - I3 UPDATE No. 52).
Wrong language and skills. KM must expressed in the current language that the organization's understand. Information may strike a chord more than "explicit knowledge"; likewise "knowledge in people's heads" rather than "tacit knowledge".
And there are specialist skills needed in KM, such as librarian skills and facilitation skills. Are these skills in place?
Failing the "what's in it for me?" test. Whenever you are asking people to change their habits or do something new, then you have to appeal to their self interest.
"Keeping your job" may motivate a few people, but your good performers will need something more concrete and positive.
Much of KM (and any change management programme come to that) is human psychology after all.
Several of these pitfalls a consultant has little control over. How often do we find ourselves in the situation of "if I were you I wouldn't start from here?" You have to work within the current organizational context as it is, not as you would like it to be.
A good consultant will paint the vision of a more desirable future and guide the willing (and even those initially unwilling) on the path to prosperity. That's the challenge I relish and I hope many of you do to. KM is beneficial and rewarding.
This article concludes in the next issue by looking at What's The Same, What's Different in my KM consulting then (around 1995) and now (2003), concluding with my personal Lessons Learned.
In the meantime, why not start reflecting on your own KM experiences, and share them with our readers.
Go To Part 2 - Making Sense of KM
I3 Update / Entovation International News:
Current Issue - Archive
- Knowledge Digest - Events