Friday, 9 December 2016

Incentivising KM by setting "impossible" targets

Nobody will look for knowledge from others, if they think they already know what to do.

This is the way humans work. If you give people challenges thay know how to solve, they have no incentive to look for new knowledge. Instead they will just rely on their own knowledge (after all – they know its provenance, and they trust it more than they trust anyone else’s knowledge).

This means that the best way to promote learning and re-application of knowledge across an organisation, is to give people challenges they don't know how to meet, but which others have already solved.

These "impossible" challenges push people out of the comfort zone of “I know how to do this”, into a zone of “this is tough – I’d better see what knowledge is out there that can help me”. Then they will look for knowledge from others, to help them solve the problem.

Ford did this in the days of the Ford Best Practice Replication System. Through applying continuously decreasing operating budgets, they forced their plants into a situation where they had to learn in order to deliver.

John Browne (the BP CEO in the 90s and early 00s) did this in BP. He expected every project to deliver better than the previous project, and his budget allocations and performance targets reflected this. He forced continuous improvement in delivery and cost, and the only way to continuously improve was to continuously learn. For the project manager, these "stretch goals" were seriously uncomfortable ("How the h*** does he expect me to cut the budget by another 20%?”) and it pushed them to seek advice, look for the best of the best, and build upon the entire knowledge base of the organisation. As a result, these stretch targets were drivers of innovation, knowledge management and continuous improvement.

It's a question of receptivity. You can't transfer knowledge unless the recipient is receptive.
To be receptive, they need to have feel a need to learn, and they have to think that their own personal knowledge is not enough to solve the challenge.

Tough targets alone are not the answer.

Do not think that I am just advocating setting arbitrary stretch goals which cannot be reached, That would be crazy; demoralising to staff and suicide for the organisation.

Instead I am advocating challenging people to do at least as well, if not better, than their colleagues, and combining this with a KM system that makes it possible to learn from these collagues. 

In both the Ford and BP cases, the strong delivery push from management was coupled with an effective knowledge management framework. Just increasing the pressure without providing systems for learning would not have worked – it would have added stress to the organisation. Increasing the pressure while also providing good KM, on the other hand, provided the incentives for knowledge to flow around the system to where it was needed (driven by “demand Pull”), and fuelled continuous performance increase over a number of years.

So remember, if you want to promote a knowledge seeking culture in your company (and a knowledge seeking culture is a far better driver of KM than a knowledge sharing culture), then your senior managers may need to push people out of the comfort zone where they can rely on what they already know.

Thursday, 8 December 2016

Don't wait for knowledge to be volunteered - go ask.

One of David Snowden's principles is that "Knowledge can't be conscripted, it can only be volunteered". However waiting passively for voluntary contributions is the wrong way to populate a KM repository.

I Know The Answer!
Originally uploaded by ngader
Knowledge can't be conscripted, it can only be volunteered, and often it won't be volunteered until you ask.

This is an outsome of the problem of the Unknown Knowns. Often people don't don't realise they have learned something, until they are asked about it, or have the chance to discuss it.

Sometimes you find organisations who have set up a system whereby people are required to identify lessons or new knowledge themselves, and then to add them into a knowledge repository. I am not a huge fan of volunteer systems like this; I don't even like them for collecting innovation suggestions. I think you capture only a small proportion of the lessons this way, because people are not aware that they have learned anything, and if they are aware, they often discount the learning as "not important". Also, self-written knowledge are often superficial, because there hasn't been the depth of dialogue and questioning to get to the lesson.

I am not arguing for forcing people to share knowledge, but I am suggesting that you don't wait for the volunteers to come to you. Instead you give people scheduled facilitated conversation-based opportunities where they can become aware of what they know, and which provide a safe and encouraging environment for them to volunteer the knowledge when asked.

There are two main approaches for doing this; reactive, and scheduled.

The reactive approach requires someone to identify particular successes and failures from which to learn. The failures can be obvious, such as HSE incidents or significant project overruns, and many companies have mandatory processes for reviewing these failures. But how do you spot the successes? Maybe you can use your company benchmark metrics, and pick the best performing units for review. Perhaps you could work with the knowledge from the manufacturing plant that never had an accident, as well as from the one with frequent accidents. Maybe you can look for the best sales team, and look to learn the secrets of their success. Or maybe you can do both successes and failures - I did a very interesting study not long ago for an organisation that measures staff engagement using the Gallup survey. We picked the ten top scoring sales teams, the ten bottom scoring teams and the ten teams which had shown the most improvement over the previous year, and interviewed the team leader and a team member of each one, to pick out the secrets of successful staff engagement.

Another organisation we have worked with uses global consultants and Technical Directors to identify opportunities for learning and knowledge transfer. They travel the world, reviewing activity at different centres, and will identify good practice which needs to be repeated, as well as opportunities to learn from mistakes.

An alternative approach, common within project-based organisations, is to schedule learning reviews and knowledge exchange within the activity framework. These could be

  • After Action Reviews on a daily basis during high-intensity learning, or after each significant task 
  • Peer Assists early in each project stage, or during project set-up
  • Retrospects (or some other form of Post Project review) at the end of each project stage, or at each project review gate
  • A Knowledge Handover meeting at the end of a project, to discuss new knowledge with other projects
  • A Technical Limit meeting during the detailed planning stage, to bring in knowledge from people with detailed experience
  • A Retrospect (or some other form of review) at the end of a bid process, when the company knows if the bid has been successful or unsuccessful.

There are many advantages to the scheduled approach. Firstly, success and failure are components of every project, and if every project is reviewed, lessons may be identified which can avoid the big mistakes later on. Secondly, if lessons identification is scheduled, it becomes a clear expectation, and the company can monitor if the expectation is being met. This expectation is common in many organisations, thought the rigour with which the expectation is met seems to vary. Finally, by scheduling and facilitating the learning dialogue, you can uncover the knowledge that nobody knows they know, until they start to discuss it.

Don't rely on people volunteering their knowledge spontaneously - instead set up scheduled processes which provide a request and a context for volunteering. 

Wednesday, 7 December 2016

Reduce, re-use, recycle knowledge

We are all into recycling. Recycling conserves sparse resources. But what about intellectual recycling? Maybe this is what KM is all about?

Let’s follow this train of thought for a bit. Let’s think of a busy team with very constrained resources (people, time, energy, budget). Let’s suggest they apply some green principles to their knowledge work. Let’s suggest they consider Reduce, Reuse, Recycle.

Reduce. Maybe they don’t need to do this knowledge work at all. Maybe they can actually reduce the amount of work they need to do. There are various processes available, such as Rightscoping, Technical Limit, or customer interrogation, designed to reduce unnecessary work. This could save a lot of their resources

Re-use. If they do need to do the work, perhaps they can reuse solutions which already exist. Perhaps they can reuse something off-the-peg, which has been applied elsewhere in the business. This can save almost as much intellectual resource as reducing the work.

Recycle. If there is no solution they can use off-the-peg, perhaps they can recycle existing ideas. Perhaps they can take what has already been done, and adapt it for their own situation; re-craft it for their own context, and improve it to fit their need. This requires resource, but nowhere near as much as creating the solution from scratch. Peer Assist could be a powerful tool here.

If they can’t reduce, can’t reuse and can’t recycle, then they have to create or invent their own solution. This is the most costly approach.

I can imagine a knowledge planning meeting, where a team divides their project into tasks, and asks, for each task, can we reduce? Can we reuse? Can we recycle? Or do we need to create and invent? This could be an excellent format for ensuring that innovation is focused only on those tasks and activities where innovation is needed. Think of the intellectual resources that could be conserved by such a recycling approach!!

Tuesday, 6 December 2016

How valid is your knowledge?

Knowledge stores need to determine the various validity levels of the knowledge they contain.

Knowledge comes in different levels of trust, and you need to make it clear to the reader what level applies to the documentation they are reading. There are three main levels

1. Mandatory, or “Must Do”. This is the level of company standards, and everybody reading this particular process documentation needs to be very clear that they need to follow exactly what’s written. If there is a major problem, they need to get in touch with the process owner and discuss it with them, but that the default should be to follow this documentation exactly.

2. Advisory, or “Should Do”. This is the level of best practices, and everybody reading this particular process documentation needs to be clear that this is the best way to approach this particular process, based on current company knowledge. However there is always the possibility to improve on best practice, and if somebody can find an even better way, then that’s great. So Advisory process is advised, but not compulsory. However if people ignore advisory knowledge and things go wrong, some awkward questions may be asked.

3. Suggested, or “Could Do”. This is the level of good ideas or good practices that others in the organisation have used, which the reader should feel free to reuse or re-adapt to his or her own context. These good ideas can still save the reader a lot of time and effort, but there is no real requirement to copy them.

In BP drilling in the late 1990s, corporate process documentation was divided into these three levels of validity, and these were labelled Principles, Processes and Practices. This labelling made it very clear to the reader how much scope they had to vary the process from what was in the documentation.

My colleague Tom, in his book Knowledge Management for Operations and Manufacturing, tells about the BP Operations Excellence toolkit, which illustrates this well.
The BP Operations Excellence toolkit is structured around the level of
validation that has been applied to the knowledge. At one level there is the
highly vetted, approved knowledge in the form of corporate standards and
required practices, which are referenced under the heading ‘The BP Way’. At the
opposite end of the spectrum is the knowledge in the Question and Response
system, eCLIPS, which is totally unvetted. BP went a step further and provided a
'health guide' to the advice you were receiving.

Captured knowledge is presented in a hierarchy, as follows;

  • The "BP Way" These tools describe the way BP does business (ie BP policy). This should be the first place to look when identifying ways (the "what" and "how").
  • Good Practices These describe good practices identified for the relevant elements by either experience from operating assets or subject matter experts.
  • Community discussion forum This section links you to any questions (and responses) that have been asked about the relevant element and allows you to ask the Community if you have been unable to find an answer in the toolkit. All entries are purely voluntary and are not validated by Subject Matter Experts. 

This hierarchy is very important as it gives the reader a sense of how reliable the knowledge might be. Thus if the advice provided is in the form of The "BP Way" then the reader knows that this is a fully validated and approved policy or procedure and can be followed with confidence. At the bottom end of the scale, advice provided via the community forum, which is not validated, needs to be treated with a lot more caution.

Monday, 5 December 2016

Procedures are the corporate memory

People come and go, but the corporate procedures remain as the place where know-how is stored.

Image from wikimedia commons
Learning implies memory. If there is no memory, there can’t be learning. A baby learns through stimuli and responses from the outside world, comparing these to existing mental models held in her memory, and updated her mental models over time.

But where is the memory of an organisation, that allows such learning to be developed?

You can’t rely on the memory of the employees to be the totality of the memory of the organisation, as employees come and go, and the human memory is, after all, a fragile and unreliable thing, prone to all sorts of cognitive bias.

In addition to this human organisational memory, we can make a strong case for organisational structures, operating procedures and processes also forming a major component of organisational memory. Processes and procedures are built up over time, and represent the company view of “how we do things”. Employees follow the processes, and repeat “how things are done”. The processes hold and propagate the patterns for behaviour, and for the way work is conducted. If the organisation is to learn, these processes must evolve over time.

The concept of evolving processes as part of the learning loop is recognised by many learning organisations.  Lessons are identified and gathered, and then used to update processes and procedures. As more lessons are gained, so the processes evolve, and this evolution preresents the way the organisation learns.

One of the learning professionals in the UK Military said to me “what is doctrine (the Army name for procedures), if not the record of lessons learned?” For the Army, the Doctrine is the memory.

Friday, 2 December 2016

KM- one of a kind, or one among equals?

Is Knowledge Management unique, or is it one discipline among many?

There are two opposing views of KM.

The first view is that Knowledge Management is a unique discipline, unlike any other.

The second view is that KM is one management discipline among many.  I would like to explain and justify this second view.

Knowledge Management represents a way of managing work, paying due attention to the value and effect of an intangible (namely, knowledge). And it's not the only management discipline which deals with intangibles. Risk management, Quality management, customer relationship management, brand management, reputation management, security management, safety management - all deal with intangibles. For me, the closest of these to KM is risk management. Knowledge and risk are allied - you reduce risk through application of knowledge. Knowledge of risks and how to handle them is some of the most valuable operational knowledge.

At a recent knowledge management training course, I presented this view of KM as one of many management disciplines. I was speaking in the context of project management, and I suggested that KM could be added to the list of management sub components of project management, and therefore added the accountability of the project manager. But after the talk, a young man came to see me and argued very strongly that I was completely wrong, and that knowledge management is unique, and cannot be bundled with other disciplines, as it is quite unlike anything else.

I suppose in a way he is correct - there are some unique elements in KM - but in another way I would rather not treat KM as a standalone. The great value of treating KM as "one among equals" - as another component of good management discipline along with risk management, safety management and the others - is that you can then place it within the same governance framework as you do the other disciplines. You can position it in the same structures and expectations. You can review it using the same review processes (the stage reviews of the project management framework, for example). In other words, you can embed it easily within "normal work".

So perhaps the answer is "both and" rather than "either or". We can treat KM an one discipline amog many, but one with unique attributes and unique challenges. 

Thursday, 1 December 2016

KM principles froim the US Army

I blogged last month about knowledge principles from the UK government. Here is another set from the US Army.

Here you can find a document by the United States Army, listing (and illustrating) their 12 Knowledge Management principles.

These principles are as follows:

1. Train and educate knowledge management leaders, managers and champions.

2. Reward knowledge sharing.

3. Establish a doctrine of collaboration (they explain the principles of collaboration as 1. Responsibility to Provide - 2. Empowered to Participate - 3. User-driven)

4. Use every interaction as an opportunity to acquire and share knowledge.

5. Prevent knowledge loss.

6. Protect and secure information and knowledge assets.

7. Embed knowledge assets (links, podcasts, videos, documents, simulations, wikis and others) in standard business processes and provide access to those who need to know.

8. Use legal and standard business rules and processes across the enterprise.

9. Use standardized collaborative toolsets.

10. Use open architectures to permit access and searching across boundaries.

11. Use a robust search capability to access contextual knowledge and store content for discovery.

12. Use portals that permit single sign-on and authentication across the global enterprise, including partners.

An interesting list, and also interesting to see what's missing - nothing there about institutionalising capture and reuse, nothing there about accountabilities and ownership for knowledge, nothing there about linking KM to the primary issues; presumably because these three are all now firmly embedded in the US Army structure and ethos.

Nothing about "learning before, during and after" - in fact nothing there about the processes of KM itself. I would not use this list as a generic list - it must work for the US Army, but I suggest that it would need modification to be used elsewhere.

But nevertheless, it is a very interesting and instructive set of principles.

Blog Archive