The weakness of the human brain as a long term knowledge store

---

Brain
Originally uploaded by dierk schaefer

We know that knowledge starts as tacit, and has to be used while tacit. in other words, people learn as individuals, and have to internalise knowledge before they can use it again. Also we know that knowledge is very difficult to externalise, and to turn from tacit to explicit. So perhaps the temptation is to leave knowledge in tacit mode. Why bother to try externalising, or capturing, knowledge? Why not leave it in people's memories, and connect up the people? That's partly the idea behind communities of practice, knowledge-focused social networks and crowdsourcing. Keep the knowledge tacit - connect up the people - leave the knowledge in the brains.

Let me give you a story which illustrates the risks involved with this.

You may have read my posts about the bird island exercise, and the link between knowledge and performance that it demonstrates. In this exercise, a team approaches a task with no knowledge, knowledge is bought into the room through an AAR, a Peer Assist, and a Knowledge Asset. With each introduction of knowledge, the team sees an increase in performance, as shown in the performance metrics.

One day, I was faced with a class where one member had already done the exercise a few months previously. I wondered what to do about this - whether to appoint him as umpire, let him sit out and observe, or let him join in and use what he could remember. I decided to let him join in.

He started the exercise with huge confidence. "I know how to do this" he said, and jumped into action, putting materials together according to his memory of the exercise. The problem was, his memory was not that great! Over those few months, he had forgotten many of the small details that were the key to success. He built one element of the construction beautifully, but could not remember how it was connected to the rest. As a result, his team design failed, and his team got the lowest score for their first construction, even though (in theory) they had more knowledge than anyone else.

You know the saying "a little knowledge is a dangerous thing"? It's more like "incomplete knowledge is a dangerous thing". He knew enough to disrupt the team process, and take over team design and innovation, but not enough to create a good product.

So why did this happen? If he had had the knowledge once, why did he not have it now? Basically, because the human brain is a poor long-term knowledge store. It is poor for three reasons

• We forget. Over time we forget the small details that make the big difference. Sometimes it doesn't take a lot to help us remember, and for this guy, a photograph of the final tower, or a diagram, or a simple design checklist, would have been enough to help him remember.
  
• We post-rationalise. Memories can become falsified. I have had memories which I would have sworn were factual, which on checking have turned out to be incorrect. We often remember the things we were involved with, and forget the roles of others, which was the case with the guy on the course - her remembered his part of the construction, but forgot how it was held together with other parts.
  
• Human brains disappear. They are attached to legs. They leave the company as the people leave. They move to other countries, other departments, other companies. They retire. They become unavailable and inaccessible.

Heads leak, they reinvent, and they leave. Would you leave crucial assets in an insecure repository like this? Would you leave your money in a safe that had a hole in the back, renumbered or erased many of the banknotes, and one day would walk out through the front door? No you would not! So if you have crucial knowledge that must be kept safe, don't entrust it solely to the human brain!

Now I am not saying that everything must be written down, I am not saying that communities and networks are a waste of time, and I am not saying that we should not connect people. What I am saying is that Connect and Collect must be in balance, and that explicit knowledge supports and reinforces tacit knowledge. The photographs, the diagrams, the checklists, the processes and procedures, the knowledge embedded in structures and systems, all have a key role to play in ensuring long-term, reliable organisational memory.

Knowledge Management vision

---

Holga Telescope Cliche
Originally uploaded by boliston

I was giving a training course yesterday in Stockholm, and almost as an afterthought, when debriefing the Bird Island game, I mentioned Lord Browne's vision for knowledge management, which we used extensively within BP, and which he mentions in his article "unleashing the power of learning" (a fantastic article, well worth the download fee, and still fresh after more than a decade).

His vision was as follows

“Most activities or tasks are not onetime events. Our philosophy is fairly simple:
Every time we do something again, we should do it better than the last time”

One of the participants came up to me afterwards, and said that this had been an "Aha!" moment for him, and that this simple vision had graphically linked KM and business value.

It reminded me again of how powerful this particular vision is. It is something everyone can buy into - nobody wants to do things worse than the last time! - but it carries significant implications about KM. Because, to do things better than last time, we need to know HOW it was done last time, WHAT was identified last time as improvement opportunities, and HOW these opportunities can be put into effect. We need a complete set of knowledge from "the last time", then we need to innovate beyond this if necessary. And don't forget - "the last time" may have been in another country, or done by another team, or done several years ago.

So there needs to be a system of identifying new knowledge and new lessons as part of activity, and there needs to be a system of carrying this new knowledge and new lessons forward to new activity, and there needs to be ways and means of assessing these and looking for further innovations and improvement opportunities, and there there needs to be a system of performance metrics behind all this. That's what will drive down the learning curve.

Knowledge management culture and Leadership

---

Leadership
Originally uploaded by pedrosimoes7

I blogged yesterday about knowledge and culture - but where does this culture come from? Is it an output of knowledge management - do people develop the culture as a result of seeing and experiencing the benefits of Knowledge Management? Or is it an input set by leadership? Do leaders have to set the culture, before you can apply KM?

To be honest, it's a bit of both. If you wait for the culture to change first, then you wait for ever. And indeed, KM processes are in themeselves culture change agents. I remember the staff at Toledo refinery, and how engaged they became after we introduced the program of After Action reviews; such as the Boilermaker who told us "I have been doing this work for 20 years, and no one has ever asked me what I thought before". So KM will change culture, but culture can also be directed and reinforced through the actions of leadership (by which I mean leaders at all levels).

I know that company culture change is possible - I have seen it happen. The big culture change program at BP - "project 1990" - took a huge amount of time and effort, but delivered a fantastic culture of empowered, networked teams striving for performance. The safety revolution in the energy, mining and construction industries has been dramatic, despite the sceptics, and has resulted in countless lives being saved. More recently, the move to a diversity and inclusion culture within the UK public sector has been successfully driven by focused attention from leadership.

So KM processes can change the culture from the bottom, and leaders can promote and reinforce the culture from above. The two work hand in hand, and then together you change the culture unit by unit, project by project, team by team, community by community.

So what are the cultural levers that leadership can pull? We believe there are three.

Firstly they need to communicate strongly their commitment to KM, and their KM expectations for the company. Much as the HSE vision can be articulated as "we will do no harm to people, or to the environment", so the KM vision can be articulated as "every time we do something, we will do it better than the last time". Or more specifically "we will never repeat a mistake, nor fail to replicate a success". But the expectation then needs to step down one level, and explain HOW this will be done. Maybe every project needs a KM plan. Maybe each project stage should end with a Retrospect. Maybe each SME is to take accountabiility for the value and use of the tacit and explicit knowledge base. Maybe ..... but you will develop your own expectations for your own company.

Secondly, compliance (or engagement) with these expectations must be monitored, and rewards and reconigition must be consistent with this level of compliance or engagement. If the company expects you to learn from the past, then they must see this, recognise it, reinforce it and reward it. They must not reward the team leader who neglected the lessons, got into trouble, and pulled the fat out of the fire by personaly heroics. They need to reward the team leader who learned not to get into trouble in the first place. KM activity needs to be monitored, the monitoring metrics need to be transparent, and rewards need to be consistent with this.

Thirdly, leadership need to invest resource. One of the most telling signs of whether your leaders beleive in something, is whether they will back this beleif with time with money, and with posts. They need to set up the necessary support structures such as the central KM team, the required software, the community leaders, the community space. They need to set time aside to take part in retrospects or knowledge exchanges. They need to be "on the pitch", not "in the stands"

The dynamics of culture change underpin our KM implementation process at Knoco, which is why we always recommend a step-wise, culturally focused change campaign.

What is the KM culture shift?

---

Happy Ramadhan, Eid Mubarak - عيد فطر مبارك
Originally uploaded by Hamed Saber

We hear a lot about creating a "knowledge sharing culture" or a "learning culture", so I thought I would share with you what I believe is the big culture shift that KM both requires and facilitates.

But first let me tell you a story. When I joined BP in the late 80s (being at the time a geologist in Britoil, which BP took over), I went to an internal Geology conference in Houston Texas. It was rater a scary affair. At the time, the internal culture in BP was very much one of internal intellectual competition. Knowledge was treated as personal competitive advantage – your own should be defended and promoted, that of others should be shot down. So throughout the conference, people stood up and presented their papers, then tried to defend them from blistering attacks from the audience (I may be exaggerating a little, but that’s how it struck me at the time).

A decade later I was on the organizing board of a similar BP internal Geology conference, in San Diego, and I remember vividly a pair of presenters starting their presentation with the words “We are stuck. We have a problem we don’t know how to solve. We would like to explain it to you, and to see if you, the audience, can help”. What a change in culture! What a difference! No more “defend and attack”, but instead an openness to listen and learn.

In those intervening 10 years, BP had been through a deliberate process of culture change, bringing in a culture of Openness, Performance-focus, Networking and Empowerment. This was the culture change that made KM implementation so much easier in BP. So how do we characterize this change in culture as it relates to knowledge? For me it is a profound shift from the individual to the collective

• From “I know” to “We know”
• From “Knowledge is mine” to “Knowledge is ours”
• From “Knowledge is owned” to “Knowledge is shared”
• From “Knowledge is personal property” to “Knowledge is collective/community property”
• From “Knowledge is personal advantage” to “Knowledge is company advantage”
• From “Knowledge is personal” to “Knowledge is inter-personal”
• From “I defend what I know” to “I am open to better knowledge”
• From “not invented here (i.e. by me)” to “invented in my community”
• From “New knowledge competes with my personal knowledge” to “new knowledge improves my personal knowledge”
• From "other people's knowledge is a threat to me" to "our shared knowledge helps me"
• From “Admitting I don’t know is weakness” to “Admitting I don’t know is the first step to learning”

That shift from “I know” to “we know” – from “Knowledge is mine” to “Knowledge is ours” is a huge one, and counter-cultural to many of us. People can find it scary, but once it has been achieved, it is like living in a different, and far better, world.

Video on Knowledge Management metrics

---

In this video I explain 4 types of metrics you can use to measure your Knowledge Management implementation




see more knowledge management video here

Implementation of KM as a series of corporate decisions

---

On the topic of implementing KM, here's a section from an article I wrote a while back, on KM implementation as a staged change process. This assumes that if an organisation is going to change, then the senior leadership need to be bought into the change. Sure you can start KM lower down and demonstrate some success, but to really make the change stick, at some stage you need to engage leadership. This is where staged decision making comes in.

Implementing Knowledge Management into an organisation will not happen accidentally. It happens by a deliberate decision. Or rather, it happens by a series of decisions. Very few company presidents or CEOs will wake up one morning and “decide” to implement KM. Instead, like any other practice, implementation is a series of decisions, and each decision rests on a basis of necessary evidence.

The chain of decisions is as follows.

1. The decision to investigate what Knowledge Management would mean for us as an organisation, and whether we need to address it corporately. This is a decision to set up a task force, or to commission some studies to gain some idea of whether KM is something the company needs to invest in. The task force will assess the current state of KM in the organisation, and decide whether it is good enough, or whether improvement is needed.

2. The decision that the organization needs improved Knowledge Management, and to find out how much investment is required. If the task force and studies show that improvement in KM is needed, then further work is needed to scope out the scale of the implementation, to set strategic direction, and to do a first-pass costing of what the implementation exercise might cost. More assessment may be needed to fully map out the scale of the interventions needed.

3. The decision to set up a KM implementation program, with a full-time team and budget. Once the organisation understands the scope of the KM implementation exercise, they fund a team and get going. At this stage they will have a KM strategy and implementation plan, and can start work testing KM approaches and technologies in the organisation, to see if they deliver the expected benefit.

4. The decision to pilot KM in high profile areas. If the small scale trials are successful, and KM has not fallen flat on it’s face or run into political road blocks, then the company may decide to scale up, and run some full scale pilots to fully road-test an integrated KM system. By this time, KM is becoming quite high profile, and quite high cost.

5. The decision to roll out KM as a required discipline to the whole organisation. The pilots were successful, the value of KM to the business and to the employees is proven, and the integrated KM system is robust. Now is the decision – not to be taken lightly! – whether to roll out a KM system to the whole organisation, as a part of the company management framework. This is the point of no return.

6. Once KM is embedded, the decision to stand down the implementation team and hand over to management within the business. Once roll-out is over, the company has to decide when to stand down the implementation team, and hand responsibility for KM over to a steady state organisation




Staged investment and decision points

Treating KM as a series of incremental decisions has two main benefits. Firstly, it allows incremental investment rather than ‘trust me, it will work out ok’ management. This is sensible prudent decision-making. The figure above shows that the investment in each stage will be a little larger than the previous stage – a task force costs less than a team, which costs less than a series of pilots, which costs less than a roll-out campaign. Each incremental increase in cost is built on a decision, which depends on the results of the previous stage, and on how well KM has proven itself. And at any point up until decision 5, the company can change its mind, because it is not fully committed. Beyond step 5 the company is committed to roll-out.

And that’s the second advantage. If each decision is made by the right people, based on the right information and the right criteria, then you shouldn’t have to revisit the decisions later. Each decision should be documented, and should stand on its own merits; without assuming a benefit that hasn’t been delivered yet. You shouldn’t have to keep rejustifying, and remaking decisions. So who are the right people to make the decisions? They need to be senior, and they need to have authority to spend the money.

Decision number 5 – the decision to roll out KM – needs to be made at the highest level. You need the support of the CEO to make a company-wide change like this. But by the time it comes to decision 5, you will have a series of successful trials and pilots that demonstrate that KM works in your organisation, and delivers real value.

Even if it is the CEO who makes the decision to commit to KM roll-out, you need the other key senior managers to support the decision, which is why we always suggest that a KM implementation program sets up a senior steering team, to help guide the KM program to a point where the commitment decision can be made to everyone’s satisfaction. Buy-in is a group activity not a single person activity.

Relearning the lessons

---

Here is an interesting blog post from Stephanie Barnes, asking why KM implementations never seem to learn the lessons of the past.

I think it may be because people who own KM initiatives are human beings, and as prone as other human beings to rush in without "learning before". So they reinvent the wheel yet again. That's why KM is needed in the first place - to influence people to access and reuse knowledge, because it's not natural human behaviour; not even for the KM implementors.

Personally I think it is highly regrettable. Those of us who have been working with KM for over a decade (since '92 in my case, with BP for 7 years, then consulting) have a very well developed understanding of how KM implementation should be done, and it is really frustrating seeing people jumping in and repeating the mistakes from the past. The worst thing about this is that partial KM implementations, which deliver minor results then fizzle out, devalue KM, and spread a feeling that "KM doesn't work"

But it does work, and there is a body of experience to explain how it can be made to work. See for example our web page on KM implementation or our Masterclass articles on staged KM implementation, referenced on our publications page.

7 lessons for change

---

A great blog post from Seth Kahan about leading KM change at World Bank.

Tom and I know that implementing KM is a change process, and our implementation model is based on staged change, so a lot of what Seth writes about, really resonates with us. Here are his 7 lessons

1. Communicate so people get it and spread it.
2. Identify and energize your most valuable players.
3. Understand the territory of change.
4. Accelerate evolution through communities.
5. Blow through bottlenecks and logjams.
6. Create dramatic surges in progress.
7. Keep your focus when change comes fast.


re numbers 1,2,3 - thats where you need your stakeholder mapping and your communication planning

re number 4 - it may be communities, it may not, but it will certainly be through networking. (I say it may not, as there have been some cultures we have worked with, where communities fell flat)

re number 5 - well, yes, so long as you don't run people over! I have seen KM programs come to grief when people get bulldozed. Blow through, but without colateral damage!

re number 6 - absolutely! Thats where you need to select your pilots - select them to succeed

Re number 7 - we call it "be prepared for outrageous success". Many times we have seen companies prepared for difficulties, but caught on the back foot when KM takes off like a rocket.

Thanks Seth, good post

Does organisation size affect knowledge sharing behaviours? Apparently not.

---

Here's another really interesting plot from this blog, and from the same study I commented about here.


As the blog authors conclude, "Looking at this graph, there is no real difference between the different organizational sizes and the reported knowledge behavior". This is a very interesting conclusion, and suggests that regardless of company size, natural human nature applies.

Now the knowledge management solution you apply to help ease the correct behaviours, and the governance process you put in place to influence the behaviours, will be very different depending on company size (and also on the extent of geographic dispersal). But this study suggests that the human cultures and behaviours will be the same.

Video on Lessons learned - how to define a quality lesson

---

Here's my latest on YouTube. Another link in the chain of how to define a good lessons learning system



see more knowledge management video here

Free knowledge management plan template.

---

"Learn Before Doing" is one of the core mantras of Knowledge management. However there is often a lack of definition as to what this learning entails, and a lack of focus and clarity on who is accountable for what learning.

Knowledge management plans are a way to deliver that focus and clarity. A Knowledge Management plan is a document for a specific project, which details; "What knowledge is needed by the project" "What knowledge will be created by the project" "What system of processes, technologies and roles will be used to manage knowledge within the project" and "What actions need to be taken to implement the system"

To help project teams start to understand the concept of the plan, we have uploaded a simple KM plan template to the downloads section of our website. This is suitable for small projects, but too mickey-mouse to work for large, high profile or critical projects, where you will need something bespoke.

Please, download it, try it, and give us feedback!

Knowledge Management and the thorn in the lion's paw

---

In a conversation with Mary Abrahams on her excellent Legal KM blog Above and Beyond KM, Mary said that "the ones who need and use the knowledge systems the most work on the front lines and are far removed from senior management".

I completely disagree with this viewpoint, that KM is something that naturally operates at a low level. I know its a common viewpoint, that knowledge is something the fontline workers do, and so KM needs to be focused at them, but it misses a huge lot of value, and a huge opportunity. Why not look at how KM can help at a management level? I see KM as a mechanism for decision support, and you get as much value from influencing the relatively rare but very high value descisions that project managers, divisional managers and senior managers make, as you do from supporting the much more common but much lower value decisions of the front line staff.

One of the most valuable pieces of work we did in BP, for example, was at senior management level, taking the lessons from the Amoco merger and applying them to the Arco acquisition. There we were working with the CFO, the chief counsel, one of the VPs - very senior level people, and massively valuable learning that really accelerated the Arco process, and made for a much smoother ride.

One of my clients likened their senior-level approach to "KM removing the thorn from the lion's paw". If you do that, the lion will always be on your side! The biggest decisions are made at the highest level, and there the need for knowledge may be greatest and the application of knowledge can yield the best return. Thats where some of the thorniest issues can be resolved through the application of Knowledge.

Try applying KM to some of senior managers' big topics - mergers, acquisitions, divestments, integrations, New Market Entry, business restructuring, recession survival. Not only do you deliver huge value, you get instant buy-in from the very people you need on your side.

Knowledge Management and Central heating

---

A spot by the radiator
Originally uploaded by eob

This is an analogy I have use a couple of times, to describe why Knowledge Management needs to be implemented as an integrated system.

There is a tendency for people to pick up on one component of KM (Intranets, say, or search engines, or communities, or Lessons Capture), to implement it, and to find that nothing changes as a result. That's because Km is an integrated system, of people, process and technology, involving connecting and collecting, including the business units and the central functions. Knowledge passes through several hands, and the "pipes" need to be in place to allow it to flow, and the "stores" need to be in place to provide a stock of knowledge.

It's like putting in place a central heating system. If all you put in is the boiler, then in the basement you have a lovely tank of hot water, but it doesn't get put into the house where it's needed. If all you put in is the radiators, then you can snuggle by them all you want, but they won't get warm. And if you put in the boiler and the radiators but no pump, you have a house with some warm areas, and some freezing cold areas.

The boiler is your central coordination of knowledge, by the SMEs and the community leaders, plus the central stores of knowledge in the Intranet, the Wikis, the communities. The pipes and radiators are the means by which this knowledge reaches the business, adds value, and returns from the business; the peer assists, the after action reviews, the community forums, the KM planning sessions. The pump is the governance framework of leadership expectation and resource support.

And what happens if you don't monitor and maintain this integrated KM system? The same thing that happens if you don't maintain your central heating system. The boiler fails, the pipes fur up, the radiators leak, the valves stick, the pump runs dry, and the house becomes damp and cold and uninhabitable.

It's our job as KM professionals to install the system, with all its components, and to keep it maintained and operational. If you need to talk through what a complete KM system might look like for your organisation, give us a call.

Knowledge Maturity

---

Lewis & Clark Expedition
Originally uploaded by jennlynndesign

I published an article in Inside Knowledge a year ago about knowledge maturity, explaining how management approaches need to change as knowledge matures. As part of the article, I used this analogy for the maturity of knowledge, which I still think is a good one.

A story of maturing knowledge

"The piece of knowledge we will look at is “how to navigate overland from the east coast to the west coast of the USA.” There was a time, in the 1800s, when this knowledge did not exist. There were no maps, no roads, and no routes. There were settlements of immigrant Americans on the east coast (and a few on the west), and nations of Native Americans within the continental interior, but no consistent body of knowledge about how to navigate across the continent. However the government of the USA saw the knowledge of how to cross the country as representing crucial future strategic knowledge. If a route could be discovered across the continent, it opened up the possibility of major expansion.

"The only way to gain this knowledge was to do a bit of pure research, and in 1805 the US government commissioned Lewis and Clark to “explore the unknown”. This was a risky venture. Of course the terrain was not fully unknown, and Lewis and Clark researched the existing maps (mostly pretty speculative and largely blank), and made use of Native American guides and advisors. They pieced together what was known, worked with people with local knowledge, explored the gaps, and created what was effectively a knowledge product – a new map, which for the first time depicted the American interior.

"By 1840, others had followed Lewis and Clark, making use of the new map, and exploring alternatives and shortcuts. By this stage, much of the knowledge of overland travel was held by a small number of experts, the “frontier scouts” such as Buffalo Bill Cody. They knew the terrain, knew the risks, spoke the language of the First Nations, and were able to make this knowledge available to the Army, to settlers, and to the first wagon trains of travellers. By the time of the 1849 gold rush, this knowledge was of huge value, and the scouts gained wealth and status through their knowledge; often legendary status.

"Eventually the trails became established, and towns sprang up at convenient points. Settlers arrived, and from the 1870s onwards the trails became colonised. For the settlers, knowledge of how to travel to the next town became crucial, and knowledge of the trail became held communally. The community knew which bridges were sound, which passes were blocked, where the clean drinking water was, and which detours were advisable. It would have been possible to navigate across the USA by asking directions from the settler communities, provided they were willing to help a stranger.

"By the 1900s, reliable roads were in place. The trails had become fully established roads, gravel roads or black-tops. Permanent bridges crossed the rivers, permanent passes led through the mountains. The knowledge now could be codified, as the trails were unlikely to change significantly. The government surveyors surveyed the roads, and road maps became publicly available. As the motor car became common, maps were produced by the oil companies, and sold at gas stations along the route (knowledge being supplied at the point of need). No longer did the traveller need to ask for directions (unless they found themselves lost, or “off the map”).

"The roads still changed, new roads were still built, and the road maps were updated in order to reflect up-to-date knowledge.

"From 1920 onwards, the road maps were supplemented by road signs, and the familiar shield-shaped US road signs were established along the main overland routes. If you were following one of the trunk roads such as the famous Route 66 , you did not need a map. You just followed the road signs. The knowledge of how to navigate was now completely embedded in the road infrastructure, at least for the major routes. The details – the back roads and the town roads – did not have the benefit of the direction signs. If you got off the main road, you still needed a map, and if you got off the map, you might still need to ask directions. However for the major routes, the knowledge was fully embedded.

"Now, of course, the knowledge has been embedded one stage further. In our cars (and in new cars, this can come as factory standard) we have satellite Global Positioning Systems (GPS) systems, which contain full and detailed knowledge of the cross-country routes. You can sit in your driveway in Manhattan, enter an address in San Diego, and the GPS system will navigate you from door to door. You need no map, you need no road signs, the need for human decision making is minimised. The knowledge of whether to turn right or left is provided to you, a few 100 metres before the turning. Some systems will even warn you of hold-ups and congestion, and re-route you. Lewis and Clark would have been amazed. However, to access this knowledge you need the GPS system and you need access to the current GPS reference maps, otherwise it may still try to lead up a road that is no longer there, or over a bridge that was replaced a few months ago".

We can see from the story how, as the knowledge matures, the management approach changes as follows

1. Knowledge creation and innovation (though based on a full review of current knowledge)
2. Knowledge held by few experts (for whom this knowledge was linked to personal status)
3. Knowledge held by community (provided they are willing to share it with outsiders)
4. Knowledge codified in documents (maps, available at the point of need, but you can go "off the map" - into areas where you need to ask teh community for detaqiled knowledge)
5. Knowledge embedded in the infrastructure (very useful for major routes, but you can still get onto "unmarked backroads" - areas where knowledge is not embedded and you need the codified or community knowledge)
6. Knowledge embedded with the user (the ultimate knowledge solution, provided you have the newest version).

Let me know if you would like a full reprint of the article.

Quantified KM success stories number 7 - MAKE winners

---

It's a fairly well known quantification, but it's an interesting high level comparison. The Global MAKE awards summary contains the following text.

"Business leaders, analysts and investors constantly ask: “What are the economic and competitive advantages of pursuing a business strategy based on knowledge leadership?” Based on the findings of the 2008 Global MAKE study, the benefits of this approach are tangible and significant.

Successfully managing enterprise knowledge yields big dividends. The 2008 Global MAKE Winners trading on the NYSE/NASDAQ showed a Total Return to Shareholders (TRS) for the ten-year period 1997-2007 of 16.3% – over twice the average Fortune 500 company median".

Whether or not you can directly link that "twice the total return" to knowledge management, or whether you conclude that the successful companies are also the ones that invest in KM, the statistic is still a powerful one.

The confusion continues

---

Another daft definition of KM, to continue my rant from my previous post. Here's one I found on the web today

Knowledge management is a way of efficient assembly, alteration, preservation as well as control of data inside businesses, alongside systems made to make the most from that information. It points specifically to utilities and techniques made to preserve information and information compiled by individuals who make up the establishment.

A definition that, in two sentences, mentions data once and information three times, and knowledge not at all (other than in the term being defined). Is it any wonder there is so much confusion between information management, data management and knowledge management, with definitions such as this?

For a better definition, see the definition video on our page of knowledge management videos

Does age have any influence over knowledge sharing activity?

Here is a really interesting set of data on age and behaviour in knowledge processes, taken from this blog (now missing)

The authors of the blog draw out various conclusions based on this data, but for me, there is only one real conclusion.

I can see no significant difference at all in knowledge sharing behaviour with age, with the exception of the over 60s. Over the rest of the graph, there seems to be no significant correlation between age and sharing behaviour. The 55-59 year olds (baby boomers) score higher than the 35-39 years old’s (Gen X) in many categories, for example.

Let's look at the TOTAL score for the categories (I have had to try to estimate the scores from the graph)and let's assume this total score is an indicator of total willingess to seek and share

20-24, 25.5
25-29, 25.05
30-34, 23.95
35-39, 25.3
40-44, 25.55
45-49, 25.15
50-54, 26
55-59, 24.5
60-64, 21.5

Now, take away the last point, and tell me if there is any trend! With the over 60s removed, all the figures are within plus or minus 5% of the mean.

To me, this data shows there is no statistically significant age trend when it comes to knowledge seeking and sharing, apart from over 60s, and I would want to know more about this older sample set before judging whether their result is significant. (In the UK, for example, women over 60 would mostly be retired, except in special circumstances. So maybe the over 60s are disproportionately senior, or disproportionately from a particular country, or disproportionately male)

The conclusion that there is no statistically significant age trend when it comes to knowledge seeking and sharing may be counter-intuitive to those who assume baby boomers behave differently from Gen X and Gen Y when it comes to knowledge sharing, but is broadly in line with a similar study done by shell.

(The demographics behind the study are being published, but I believe there are only 4 people in the youngest category, and only 19 in the oldest, so both of these points must come with larger error bars. Also note that the axis of this graph starts at 2. Plot it with the axis starting at zero, and the lack of trends becomes even more obvious).

KM and safety management - where the analogy breaks down

---

I had a comment today on my youtube video "What is knowledge Management?", from Oska 7574, as follows

Thank you Nick
I like the safety management thing but at the end of the year I might have no accidents , for instance, then i will deem my safety management as good one. Then tell me what about KM and its success measurements? How we continue in the comparison or the analogy to reach real understanding for the benefits of KM a management approach?

My answer was as follows

All analogies break down somewhere, and one of the major differences between KM and Safety Management is that a safety incident is very visible; as lost time, or as an injury. A lost time incident is far more visible than a lost knowledge incident.

Therefore safety management is easier to implement, because the outcomes are so visible.

However, intangible metrics are used in Safety - near misses, or high potential incidents, are only recorded because people take time to record them. They don't result in accidents or lost time, but are a leading indicator. An equivalent leading indicator in KM would be the number of lessons with closed-out actions in a learning system, or the number of questions answered in a community forum.

Also outcome-based metrics can be applied to knowledge management, the ultimate output being continuous performance improvement. See my blog post on learning curves, and our website page on valuation of KM.

More free video available from our website video page

Lessons learned; good and bad

---

Last week I blogged about lessons learned, and spent a bit of text talking about 'what makes a good lesson'. I'd like to amplify that, and talk about what makes a BAD lesson, so that we know what to avoid.

I did a google search for "lessons learned from.." and found some good examples, some poor examples, and some mxed examples, but it would be wrong to publically criticise someone else's website, so I will give you some generic examples of bad lessons, and then a specific good lesson.

You can find a lot of lessons that are historical statements.

Example "Organisations may not have anticipated or prepared for the effects of this risk"
Example "The integrated information campaign was delayed by the lack of advance planning"
Example "The boat was late arriving, and the engineer was not suitably qualified"

In each of these cases, I really want to ask the question - "So what have we learned? How do we ensure organisations are prepared? How do we ensure future campaigns are not delayed? How do we ensure future boats arrive on time, and with the suitable personnel on board?" So we need to do a bit of analysis, and look for root causes, and then genericise the lesson for future use. we need to turn it into a recommendation, really.

You can find a lot of lessons that are woolly and full of unquantified terms like "early" and "more"

Example "A project of this kind will require extensive planning, which must be started early"
Example "Budgets for this sort of work need to be larger"
Example "Make sure the project team is adequately staffed, with all the key skills represented, from the pre-tender stage"

In each of these cases, I want to ask for more detail. They are too woolly to be helpful. I want to know, how much planning? An extra year planning? An extra day? How early should it start? How much bigger should the budgets be - double, treble, 100 times bigger? What does adequate staffing look like? Which are the key skills? And so on.

So how about a good Lessons Learned example? You can actually find many of them on the web, for example at the NASA lessons database, from which I have taken this example as an example of a well written lesson.

Lesson(s) Learned:
A 10% budgetary reserve is inadequate for a technology validation mission. The EO-1 experience suggests that 15% is a minimum and 20% would be preferred. Three characteristics peculiar to technology validation missions require this additional reserve. Accurately assessing the maturity of an advanced technology is very important. Considerable reserve can be quickly expended in maturing a technology to reach flight status consistent with the aggressive schedule typical of such missions. In a related way, using reserve to overcome whatever difficulties may be encountered in the fabrication of "first-time" flight hardware is another activity that can quickly consume considerable reserve. Lastly, the exact performance needed to effectively validate the advanced technology may not be fully understood until rather late in the definition process and this may increase the cost of the spacecraft.

Recommendation:
Future technology validation missions should carry a minimum budgetary reserve of 15% at the Confirmation Review.

Why do I like this example? It's clear, its quantified, it's written as a recommendation, it's backed up with a good argument, and most importantly, someone reading the lesson would know exactly what to do next time. Which is, I suppose, my primary criterion for a lesson. It needs to be reusable.

Great interview on the value and pitfalls of collaboration

---

A great video interview from Oliver Marks with Morten Hansen, where he makes some great points suggesting that collaboration "for the sake of it" is a poor strategy, and that bad collaboration is worse than no collaboration at all. Also, he concludes that improving the technology e.g. through use of Enterprise 2.0, will not neccessarily change a bad culture and may easily make it worse.

What is a Lesson Learned?

---

I have been thinking a lot recently about "what is a lesson learned", largely in the context of our company offering on lesson-learning and our recent development of lessons management software (for more on lesson learning, see my book).

There's a lot of fuzziness about the topic, and this can really hamper the delivery of value through lessons identification, sharing and re-use. Let's start with the question - "What is a lesson learned". Here are a few definitions, many taken from the web, many of them (as we will see) flawed.

• "A Lesson Learned is knowledge or understanding gained by experience that has a significant impact for an organisation. The experience may be either positive or negative. Successes are also sources of Lessons Learned. Lessons Learned Systems tend to be more organisation-specific than Alert Systems". 
• "A Lesson Learned documents the experience gained during a project. These lessons come from working with or solving real-world problems. Collecting and disseminating lessons learned helps to eliminate the occurrence of the same problems in future projects". 
• “a potential mode of failure (a risk) and the possible actions to mitigate that risk”.
• A lesson learned is an experience or outcome of a particular course of action -- either positive or negative -- that is important enough to be communicated to one's peers.
• "The knowledge acquired from an innovation or an adverse experience that causes a worker or an organization to improve a process or activity to work safer, more efficiently, or with higher quality"
• Knowledge derived from the reflection, analysis and,conceptualisation of experience that has potential to improvefuture action

We can conclude from this that lessons are knowledge, and that they come from experience, and that they can help, or impact, the work of others. But does that make them "Learned"?

There is a very valuable distinction to be made between Lesson Learned and Lessons Identified, and anyone who has worked in this field for a while will have met companies which keep identifying the same lesson over and over, but never learning it (see excellent picture above). I would suggest that many of the definitions above are for Lessons Identified rather than Lessons Learned. Look at the language in the definitions; "collecting and disseminating lessons learned helps" - yes, disseminating lessons may help, but what about applying them? "Important enough to be communicated to one's peers" - what about "important enough to be re-applied by one's peers"?

Let's look at the steps a lesson has to go through before it can be considered to be "Learned".


1. Reflect on Experience. Think back (and discuss as a team)what happened.
2. Identify learning points. Where was there a difference between what was planned, and what actually happened? Either a positive or a negative difference.
3. Analyse. Why was there a difference? What were the root causes?
4. Generalise. What is the learning point? What should be done in future activity to avoid the pitfall, or repeat the success? At this stage we have a Lesson Identified. It will be a useful lesson, if others can learn from it, and for others to learn from it, it needs to be instructional.

At this stage, let me have a short digression on "What makes a good Lesson". We tend to use the phrase "Specific Actionable Recommendation to describe a good lesson.

• A lesson needs to be specific enough that you can learn from it. Let's have none of the "Well, Duh!" lessons, please. I read a Lesson last week that said "To do X properly will require time, resources and effort". Well, Duh! And there was me, thinking it could be done in no time, with no resources or effort!
• It needs to be actionable - people need to be able to take action. So none of the woolly waffles such as "A better system for Y needs to be in place". How Better? What sort of Better? What elements need to be Better? Who needs to put it in place?
• Finally it needs to be a recommendation, rather than an observation. I went through some documents recently which were purported to be lessons learned documents from an absolutely crucial project, and half of the "lessons" were observations. They had not got past step 2 above. They were statements such as "The team encountered great difficulty in Z, blah blah". Well, why did they encounter difficulty? What was the root cause behind that diffIculty? And what would their recommendation be for other teams, to avoid that difficulty? There has been no analysis, so there can be no specific actionable recommendation.

My conclusion is that a Lesson Identified needs to be "A recommendation, based on analysed experience, from which others can learn in order to improve their performance". We are still not at a "Lesson Learned" as there needs to be one more step - step 5.

5. Take action. As I explained here, a lesson needs to be accompanied by an action if it is to be considered Learned. A document, a procedure, a policy, a structure, a budget, or an order, needs to be changed. Then this change needs to be communicated, so working practices can be changed as a result. If nothing changes, nothing has been learned.

So I would like to propose this definition. A Lesson Learned, is a change in personal or operational behaviour as a result of experience. Ideally this will be a permanent, institutionalised change, but we know that lessons can be unlearned as well as learned, so I will leave the work "institutionalised" out of the definition for the moment.

Photo from Flickr Creative Commons - Lessons Learned. Sure
Originally uploaded by Mike Licht, NotionsCapital.com

Can KM survive without performance management?

---

I don't think it can.

There's a very close link between knowledge and performance, and a very close link between knowledge management and performance management, as I point out in this video. In fact, the link is so close that I don't think knowledge management can thrive where performance management is absent. Let's see if I can justify this statement.

Knowledge Management, for me, is a systematic approach to organisational learning. But learning about what? Learning to perform, is the answer. Learning to perform means the identification of better ways to do things, and then sharing and replicating those better ways, and embedding them into the processes and structures of the organisation. We can measure the result of this learning in learning curves.

But what if there is no performance management - no measurement, no metrics? What if there are no measures of performance? How will you know if any one approach is better than another, and worth replicating? How will you see the learning curves, without metrics? How can you plan to improve, with no targets? What will incentivise people to learn from each other, if performance is not a driver?

Think of the old Deming Loop, of Plan, Do, Measure, Learn. How will Learning find a home, if there is no planning or no measuring? This issue becomes important when you start to look at Knowledge Management in the public sector, where performance management is a far fuzzier affair than in the private sector, and where key performance indicators can be complex things.

In the private sector, a best practice is easily identified as being the practice that delivers the quickest, cheapest or higest performing result. But in the public sector, how do you define a best practice? For a government department, what solution is "best"? It's not necessarily the cheapest, nor the quickest solution. Is it maybe the solution that has greatest public acceptance? Or that the press doesn't make fun of? Or that the minister prefers? And what's Best today, may not be Best tomorrow.

Where performance management is difficult or challenging, Knowledge Management will not be easy either.

Making lessons stick - the need for actions

---

student teacher
Originally uploaded by peiqianlong

In our newsletter of winter 2008, we talked about lessons learned, and the need to close the lessons learned loop. More of our thinking on the topic can be found on this YouTube video. The key point in the article and the video is that a lesson is not an end in itself; a lesson is an identification of a process improvement and it needs to change something. Something needs to change, as a result of the lesson. Lessons that sit in the lessons learned database, or even worse, in the back of a project report, are worthless unless something changes as a result.

This observation has another follow-on, which is that a lesson needs to be associated with an action if it’s going to have any effect. I think this is a really important conclusion, and I have seen it working very well in two settings; oil drilling, and the military. I will use Oil Drilling as an example of how this works.

A drilling crew drill a well. On a regular basis they discuss their progress against the plan, and what they have achieved, and they identify things have gone well and things should have not gone well. They look at root causes, and they identify the learnings associated with those root causes. And then they go one step further –they identify an action to embed the lesson.

Say they were experimenting with the drilling mud, and found an additive which helped increase stability and stopped the hole collapsing while drilling an unstable part of the section. The lesson is obvious – “additive X should be used while drilling section Y”. The action is also obvious – "update the relevant part of the drilling guidelines" (as well as "order several sacks of additive X").

The drillers use a lessons database which allows actions to be assigned, and the actions are then tracked, and closed out when the action has been completed. So what sort of actions are associated with lessons? In the example above, the action is to update a process or procedure. If there is no process or procedure, maybe the action is to write one. Or maybe the action is to update reference material, or update training material, or make a change to resourcing or to organisational structure or to equipment.

In the military, the action is often to update the doctrine (doctrine is the military word for standard operating procedure), and somebody said to me recently “a lesson is not learnt until doctrine is changed”. This is true where the action is a doctrine update, but the more general statement would be to say “a lesson is not learned until action is taken to institutionalise the learning” where institutionalisation means embedding the new learning in doctrine, procedure, structure, training or resourcing. Then if you can track the action, you can introduce a degree of governance to the learning process.

Picture from Flickr creative commons, originally uploaded by peiqianlong

History of KM

---

A great post by Nancy Dixon on the history of KM