Here is a useful boston square on learning from success and failure

1. In  failsafe environment, study carefully the root causes for your own success and failures (and those of others) to continuously improve and finally succeed. 
2. When failure is not an option, study carefully the root causes for your own success and that of others, to avoid failing, and study even more carefully the root causes for failure of others, and the mitigations they used to address that failure, to minimise failing yourself and to recover quickly if you do.

For a final word on the matter, here’s a quick video from Jack Ma.

The impetus to revisit this topic came from a one-liner post on LinkedIn by Oleg Vishnepolsky reading “Sometimes I win, sometimes I learn.”

My reply was “Win or lose, you should always learn”.

Sometimes it seems as if learning is reserved for failures. If there is a safety near miss, or an incident in a hospital, or technical non-conformance, then learning swings into action. When all goes well, learning is an afterthought. And it is certainly true that individuals learn much better from their mistakes, as a result of the emotional charge and the emotional scars that failure brings.

However you can argue equally strongly that success is a better teacher, because a fail mode only tells you one option not to try; it does not tell you how to succeed. So as well as learning from a hospital incident, you should learn from, and emulate, those hospitals that never had an incident, or those suppliers whose technical products always conform. This is the principle behind positive deviance – the idea that there are always positive outliers; individuals, groups or companies that perform far better than their peers, and which should be the first place you look to for learning.

Which is the better approach – learning from success, or learning from failure?

This is of course another one of KM’s “false dichotomies”. Someone in NASA once said (and I can’t find the source of this quote I am afraid) that “in NASA we say there are no successes or failures, there are only Events. We learn from Events.” The whole concept of success and failure is irrelevant to learning. Most events, most projects, are a mix of both, and we need to learn from both.

Learning from failure helps you learn how not to fail, learning from success helps you learn how to succeed. You need to decide which is more important. 

At a corporate level, or as a society, we collectively make the biggest learning steps when we finally succeed. Think of Edison and his light filament; when did he do the most learning? When he tried each of the 99 options that didn’t work, or when he found the one that did? Now obviously he learned from both, but let’s look at the value of that knowledge to others.

If you were a light bulb maker, which of these two statements from Thomas Edison would be of most value to you?

1. You can’t make a light bulb filament out of cat hair 
2. You can make a light bulb filament out of tungsten 

The implication for Knowledge Management

The implication for Knowledge Management is this:

You need to learn from both success and failure, but you need to learn much more carefully and deliberately from success, because: 

• success can be less obvious – you may have to look for those positive deviance examples;
• learning from success can be more difficult (it is easier to isolate what went wrong than what went right); and
• ultimately, success is what you want others to replicate.

As an example, let’s look at the typical systems set up to learn from safety incidents. Most of these systems have detailed root cause analysis when there is a near miss or an incident, and the lessons from these are sent around the organisation so others can learn from this safety failure.

However it is far more important to learn from the (positively deviant) factory or plant that never has an accident, and never has a near miss. That is the factory everyone needs to emulate, which means they need to carefully understand WHY they are so safe, and then learn from this.

We know that it is human nature to learn best from mistakes, but we don’t want to be at the mercy of human nature. We don’t want people to have to screw up in order to learn. We don’t want failures and screw ups if we can possibly avoid it, because mistakes and screwups can cost money, they can cost lives (in certain cases), and they can cost careers if they are big enough.

Learning in a KM Framework

The ideal situation, in any mature KM or lesson-learning framework, is that you learn as a matter of course from every event, whether you deliver failure, success or a mixture of both (and it usually is a mixture).

Learning, as in lesson identification meetings such as After Action reviews and Retrospects, should be a routine exercise, regardless of success or failure. Address both, learn from both, and give particular attention to understanding the causes of success.

Fail fast and fail often is a good mantra, so long as it leads to success, and it is the success that is the greatest learning opportunity.

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.