Knowledge Management is the discipline that drives continuous improvement. Here is a diagram that makes this clear

We are all familiar with the link between Knowledge and continuous improvement in our personal lives, as demonstrated by the familiar saying “Practice Makes Perfect”. The more we do something, the better we become. The more experience we have, the higher our performance.

This can also be true for Organisations, provided we apply KM. Organisations can also find that Practice Makes Perfect, and that the more experience they have the higher their performance.

The diagram here shows how – feel free to use with acknowledgement.

The two crucial elements are as follows.

1) There needs to be a learning loop in operation. Knowledge must be applied to activity and to problems, and must be reviewed and gained from activity, problems and experience. The challenges for an organisation are two-fold – firstly finding a way to gain knowledge from experience (through effective lessons capture for example), and secondly being able to find the knowledge from the past (practices like Peer Assist help here). This is one elements of Knowledge Management already. 

2) The second element is to embed new knowledge into processes, procedures and structures. This is represented by the blue wedge in the diagram marked KM. Without this embedding step, the new knowledge is lost over time as human memory fades, or as lessons become buried within lessons databases, and performance slips back down the hill. The embedding KM wedge makes sure that performance gains are maintained (through the use of Lessons Management Software for example).

This combination of the KM components of learning loop and embedding means that

• the more experience an organisation has, the more it learns
• the more it learns, the more it improves its knowledge base
• the more it improves its knowledge base, the more it improves its processes, procedures and structures
•  the more it improves its processes, procedures and structures, the more it improves performance.

In today’s rapidly changing world, the speed at which your organisation learns can be a competitive advantage.

Spitfies and Bf109 Dogfight, by Adam Purves on Flickr

The world is changing, and the rate of change is speeding up.

In the past, when progress was slower and the rate of change was lower, an organisation could compete on its products, its patents, its reputation and on its people.

However the rate of change is increasing, and companies need to adapt. Markets are changing, customers are changing, expectations are changing, regulations are changing, the world is changing, and it is changing faster and faster. If companies are to adapt, they need to unlearn old habits and learn new ones. And in a competitive world, the fastest learner wins.

The analogy is with the aerial dogfights in the first world war.  There, the maneuverability of the aircraft was key. If you could maneuver faster than the opposition, you could get inside their turning circle, and shoot them down.

Today, the learning agility – the intellectual maneuverability – of a competitive organisation is key.

If you can get inside the opposition’s learning circle, you can shoot them down.

So how fast is your learning circle? How quickly does the organisation learn from experience?

• How long does it take for a new lesson from experience to become embedded into the way you work?

• How long does it take a question in a Community of Practice to be a) asked and b) answered?

• How long does it take a piece of new knowledge to show up in the company knowledge base, and how long does it take for this to be re-used and applied?

Do you even know? Do you have the metrics to measure your speed of learning, as an organisation?

Contact Knoco if you need help with tuning up your learning circle!

“This time it’s different” can be the four most costly words in project knowledge management, if they are used as a reason not to learn from the past.

Albert Einstein’s definition of insanity was “doing the same thing over and over again and expecting different results”.

And yet, any analysis of a collection of corporate lessons will show the same mistakes being made time after time. So organisations obviously DO “do the same thing over and over again and expect different results”.

Are organisations insane?  Or is there another factor at work?

The factor may well be what the Farnam Street blog calls the “This time it’s different” fallacy. I quote from the blog –

“This time is different” could be the 4 most costly words ever spoken. 

It’s not the words that are costly so much as the conclusions they encourage us to draw. We incorrectly think that differences are more valuable than similarities. After all, anyone can see what’s the same but it takes true insight to see what’s different, right? We’re all so busy trying to find differences that we forget to pay attention to what is the same.

Different is exciting and new, same is old hat. People focus on the differences and neglect the similarities. In projects, this becomes the “my project is different” fallacy that I described here. People look at their projects, see the unique situations, find the differences, overlook the similarities to all similar projects on the past, and assume that “this time it will be different”.

It never is.

The same old mistakes will creep up on you and bite you in the bottom, as they always do.

Instead of assuming “this project is different”, perhaps we should start with the assumption that “this project is just like any project. It involves building and understanding client requirements, choosing and forming the team, selecting and managing sub contractors, balancing the innovation against the risk, communicating within the team and with the client, keeping the client requirements always in mind, managing quality, managing cost, managing time, managing expectations, managing risk, and so on”.

Then look for the lessons that will help you with all those tasks, and will help you avoid all the old pitfalls. As the Farnam Street blog says,

If you catch yourself reasoning based on “this time is different” remember that you are probably speculating. While you may be right, odds are, this time is not different. You just haven’t looked for the similarities.

A great antidote to the “This time it’s different” fallacy is that good old, tried and tested mainstay of Knowledge Management, the Peer Assist. Once a project team gets into a room with a bunch of people with experience, the conversation automatically focuses on the similarities. “Yes, we’ve seen that, we’ve been there, here’s what we learned” and it becomes increasingly difficult to maintain that “This time it will be different”.

Here’s a really great video on a small organisation operationalising a lessons learned process

The organisation is Boulder Associates, an Architect and Design firm with a couple of hundred staff working out of a handful of US locations. The video was recorded at the KA-connect conference in San Francisco in 2018; an annual knowledge-focused conference for the AEC community organised by Knowledge Architecture.

The video is of a 27 minute presentation given by Todd Henderson and James Lenhart of Boulder Associates, and thanks Todd for the namechecks!

They make the point that collecting lesson is not the purpose of lesson learning, and they drive lesson learning through just in time delivery, using checklists as the final destination for the learning. Their combination of spreadsheet, tracking dashboard and checklists is a very simple, very appropriate system for an organisation of this scale.

It is part of the human condition to deny our mistakes, but that makes it hard for us, and for our organisations, to learn.

make no mistake, a photo by Meshl on Flickr.

I can recommend a really interesting book called “Mistakes were made – but not by me – (why we justify foolish beliefs, bad decisions and hurtful acts)”.

The book is about cognitive dissonance – how people square their self-image of being a good, competent and smart person, with the realisation that they can make mistakes – sometimes pretty big mistakes.

The way most people deal with this problem is to maintain the self-image and explain away the mistake.

“It wasn’t really a mistake” – “Of course I didn’t see the stop sign, it was in such a stupid place” – “The sun was in my eyes” – “Nobody told me it was wrong” – “He pushed me” – “I don’t see why I should say sorry, he started it” – “I’m not wrong, aliens really DO exist; the government is covering it all up” and so on.

They didn’t REALLY make a mistake; they were smart people all along. It wasn’t their fault.

This cognitive dissonance works particularly strongly in cultures that are intolerant of mistakes, and to be honest, that’s most cultures. As the playwright Lillian Hellman says about US culture, for example

“We are a people who do not want to keep much of the past in our heads. It is considered unhealthy in America to remember mistakes, neurotic to think about them, psychotic to dwell on them”.

Knowledge Management, however, requires that organisations, and the people within them, learn from experience, and 50% of experience comes from Mistakes. KM, if it is balanced, must allow learning equally from failures and from successes. Somehow this very powerful driving force of cognitive dissonance, present in every culture and every human, must be allowed for, sidestepped and redressed.

How do we do this?

Firstly, there much be a very conscious top-down drive for a culture that allows learning from mistakes. Call it a no-blame culture, call it an organisational learning culture, call it openness – it needs to be a clear and conscious expectation. This sets up a counter-dissonance. “I am a smart person. But I made a mistake. But the company expects me, if I am smart, to admit mistakes. Hmmmm!”

We all know the story told about Tom Watson Sr, the first president of IBM.

A young worker had made a mistake that lost IBM $1 million in business. She was called in to the President’s office and as she walked in said, “Well, I guess you have called me here to fire me.” “Fire you?” Mr. Watson replied, “I just spent $1 million on your education!”

That is a very powerful story that sets up a counter-dissonance.

Or look at the NASA approach, of getting senior leaders to publish stories entitled “my best mistake”.  I suggested this to an organisation recently, and the head of KM actually said “you will NEVER get leaders to publish their mistakes”. And yet that’s just what they did at NASA.

Or look at the Japanese attitude of Hansei. Although alien to many in the west, Hansei is an important part of the Japanese culture. Han means “change” and Sei means “to review”, so the whole thing means “introspection” or “reflection for the purposes of change”.  This translates into a behaviour , instilled from childhood, of looking for mistakes, admitting responsibility, and implementing change.(When Japanese children do something wrong, for example, they are told: “Hansei shinasai – Do hansei”!). Hansie also contains the thought that “to say there were no mistakes, it itself a mistake”

Secondly, we use objective facilitation.

Take lessons-identification meetings, for example. The temptation, when scheduling a meeting for a project team to identify lessons from experience, is for the project leader to lead the meeting. However the outcome, most of the time, is that the project team made No Mistakes. Sure, mistakes were made, but not by the project team!

You see this, for example, when the lessons coming from the team are like this ….

We ordered a set of number 6 widgets, and when they arrived, they were very poor quality. We had to send them all back, which delayed construction by a week.  The lesson is not to use that supplier again”.

So the fault was with the supplier.

However a good objective facilitator would dig deeper. They would ask – what were your quality control procedures? What was your ordering philosophy? Did you wait for the widgets to arrive before doing quality control? If so, why did you leave it until the last minute, so that re-ordering caused delay? Did you just assume that everything would be top quality?” The lesson would be more about quality control procedures and mental assumptions, that it would be about suppliers and vendors.

Any good system of lessons identification and lesson-learning has to use objective external facilitation, if you are to overcome the tendency to say “mistakes were made, but not by my team.” That’s why an increasing number of companies are calling us in, for example, to provide that skilled external evaluation as part of their lesson learning system.

This is even more the case with high level review and learning. As the authors of the book say,

“Few organisations welcome outside supervision and correction. If those in power prefer to maintain their blind spots at all costs, then impartial review must improve their vision ……. If we as human beings are inevitably afflicted with tunnel vision, at least our errors are more likely to be reduced or corrected if the tunnel is made of glass”.

This goes for teams and individuals as well as organisations – impartial assistance is vital.

So, set the high level expectation for openness, and use external facilitation to probe the blind spots.

We all make mistakes – mistakes have been made, often by us, and those mistakes are an opportunity to learn and improve, despite our best efforts to pretend that they never happened.

As a project learns, it goes through 4 stages (see Donald Rumsfeld)

I blogged yesterday about the need for knowledge transfer between a project and an organisation.

This post goes a little further, and talks about the development of knowledge within a project.

The diagram here shows how KM can take a project through a progression of learning in a project, and is particularly applicable to product development projects or R&D projects.

1. In step 1, the project becomes clear about what it already knows (about the challenges, about the technology, about the market). These are the Known Knowns.

2. In step 2, the project should identify its knowledge gaps, through a process such as Knowledge Gap Analysis or KM planning. Through this process, the team becomes clear what they don’t know, but can learn from others.   As far as the project team is concerned, these are the Unknown Knowns; things that others know, that the project team doesn’t. Here the team needs to learn from the wider organisation as described in yesterday’s post, or learn from other organisations. By mapping out the known knowns, the project team can then limit their scope to the truly unknown (because if they start researching known territory. they are wasting effort and reinventing the wheel). (See for example Wilbur Wright’s attempt to map out the known knowns when researching Powered Flight). This step also helps overcome the overconfidence bias.

3. In step 3, the project steps into the unknown. They define what they need to learn about but cannot just learn from others (the Known Unknowns), and put in place processes to gain that knowledge – R&D, Market Research, Rapid Prototyping, Business Driven Action Learning.  Through these processes, they fill in the Known Unknowns  as they become known.

4. In step 4 the project butts up against the Unknown Unknowns – the nasty surprises. They can only address these by a secure process of “Learning while Doing” – through After Action Reviews or some other process of project learning. They won’t discover all the Unknown Unknowns, but can make some headway into this territory.

5. Then of course comes step 5, where all of this knowledge is fed back to the organisation, as described yesterday.

How urgent is learning in your organisation?

Image from wikimedia commons

When I give my Knowledge Management Training courses, I start proceedings by presenting three stories from organisations who are doing knowledge management, showcasing some of the benefits KM can bring.

I then ask the class to discuss the stories, and to identify the success factors that lie behind each one. Often these are a mix of successful interventions, and successful cultural elements.

One of the success factors a recent class identified was a “sense of urgency“. In each case, the protagonists in the story treated learning as Urgent – one of the first things to be done before leaping into action – and as a result, delivered great results.

This was a really good insight.

All too often, learning (and Knowledge Management in general) is seen as important, but not treated as urgent. In these stories, the urgency was there, and learning followed.

So how had the organisations in the stories created that sense of urgency?

• In the first story, the organisation gave a high-profile task to an individual who had never done that sort of thing before, with clear instructions not to “screw up”. A risky move, were it not for the Knowledge Management system which gave the individual all the knowledge they needed to succeed.
• In the second story, the organisation challenged a team to improve on the past benchmark performance by nearly 20%. An impossible challenge, were it not for the access the team was given to all the lessons and knowledge from past performance.
• In the third story, the organisation gave the same audacious goal to twelve different teams simultaneously. A crazy thing to do, were it not for the way they set up knowledge-sharing between the teams, so they reached the goal far faster collectively, then they did individually. 

An analysis of your past lessons can be used to create a Risk Radar for future projects.

Michael Mauboussin, in his book “Think Twice”, talks about the planning fallacy, and compares the inside and outside view.

He points out that people planning a task or a project tend to take the inside view – they think through how they will do the project, they think about the risks and challenges they will face, and how they will overcome them, they add up the times for each step, and use that as their baseline. Almost always they are over-optimistic, unless they also use the outside view, and calibrate their baseline against what usually happens.

Mauboussin says

If you want to know how something is going to turn out for you, look how it turned out for others in the same situation”

To find out what happened to people in similar situations, we can use Lessons Analysis. If you have an effective lesson learning system you may have records from hundreds or thousands of past projects, and you have a huge database of “how things turned out”. Through lessons analysis you can recognise common themes across a number of lessons, and see the challenges and risks that projects are likely to meet, and identify those which are most common and most impactful. You can then use these to create a risk radar for future projects.

In the 90s, I was in charge of a lesson-learning system in Norway. At one point we had lessons from over 300 projects in the system, and we grouped them into a series of “things that commonly go wrong in our projects”.

In Norway, we treated our list as our “Risk radar” – the more of these problem areas that a project faced, the greater the risk to effective project delivery. The top 7 problem areas were as follows (remember these were small office-based projects)

1. The project team is new, or contains a significant number of new members
2. There is no clear full-time customer for the project 
3. Satisfactory completion of the project relies on an external supplier. 
4. The project is a low priority ‘back-burner’ project. 
5. The project scope is poorly defined. 
6. The project relies on an unusual degree of IT support. 
7. The project involves consultation with large numbers of staff.

Any project where more than one of these was true had “Danger on it’s Radar”.

Such a project therefore needed to pay considerably more attention than usual to project management, and was advised to scan back through the relevant lessons and guidance, and speak to the people involved, in order to find out how the danger can be averted.

A few years later, the organisation applied the same concept to big engineering projects, and came up with what they called the “Train Wreck Indicator” – a similar indicator based on common reasons for failure, determined through lessons analysis. Any project that scored a Red Light on the train wreck indicator was given additional help and oversight in order to help it steer a path through the problem areas, and avoid becoming a train wreck.

Tools such as this help projects gain the Outside View to aid them in their planning.

If you have an effective lessons learned system, and are building up a library of project lessons, then consider a similar analysis, to build your own “Risk Radar“.

 Contact us if you want to know more about our lessons analysis service.

People who have learned from experience must understand their responsibility to teach others.

Photo by US Army Africa, on Flickr

I often say at the start of Lessons learned meetings, that when identifying and recording lessons we should think of them not as something we have learned, but as something we can teach others.

This is a subtle shift in emphasis form looking inwards, to looking outwards, and from looking backward, to looking forwards. It also identifies the responsibility of the knowledgeable person; a responsibility to others rather than to themselves.

For much of the lessons workshop, the participants are looking back at what happened. “We had a difficult time with the client”, they might decide, and then follow this Observation with a whole set of reminiscences about how difficult the client was, and what trouble it caused.

With good facilitation, they can also reach Insights about why the problems happened.

However the facilitator then has to turn the conversation outwards, and ask – “based on what you have learned from your reflection on the client difficulties, what can we teach the organisation about how to better deal with clients”. The participants need to stop analysing history, and start looking at generic learning they can pass on to others.

That is a critical value-added step, and it is that step, and the subtle mindset shift from passive learners to active teachers, that allows the participants to turn an observation and the subsequence insights, into a Lesson.

Knowledge Management requires knowledge seeking and knowledge sharing. But why so much focus in internal processes on sharing and so little on seeking?

Learning Happens by shareski, on Flickr

One of the standard models for Knowledge Management in project environments is the idea of “Learning Before, During and After“.

Ideally these three activities should be embedded in project process, so that a project

1. Starts by reviewing and accessing all the knowledge it needs,
2. Learns as it goes, improving its processes during the course of the project, and
3. Identifies, analyses, documents and shares the new knowledge it has gained, for the sake of future projects.