What pilot checklists can teach us about KM

This blog often refers to aviation and their use of checklists as a great example of KM operating ata cultural level in an industrial sector. Here are some more thoughts. 

B17 checklist linked from here

• Boeing first turned to checklists in order to recover from a commercial near-disaster.

This document called "How the pilot's checklist came about" tells us how, in 1934, the Boeing 299 was the frontrunner in an order by the US Army for up to 200 aircraft, and was in the final stages of evaluation in a fly-off against its 2 rivals. It needed to perform well - this order could save Boeing as a company.

Unfortunately the 299 stalled on take-off, crashed and exploded, killing 2 of the 4 crew. The article tells us

"The investigation found "Pilot Error" as the main cause of the accident. Hill, (the pilot, flying the plane for the first time) unfamiliar with the aircraft, had neglected to release the elevator lock prior to take off. Once airborne, Tower (Boeing chief test pilot, also in the cockpit) evidently realized what was happening and tried to reach the lock handle but by that time it was too late".

The plane was dubbed "too much for one man to fly" and Boeing lost the order. However they managed to persuade the Army to order 13 planes for further testing, and at the same time the Boeing pilots put their heads together to work out how they could avoid future disasters. They realised that the Model 299 was not too much airplane for one person to fly, it was simply too complex for any one pilot’s memory in the heat of the moment.

"In the end, four checklists were developed - takeoff, flight, before landing, and after landing.  These checklists for both the pilot and the co-pilot made sure that nothing was forgotten. With these new checklists, careful planning and rigorous training, the twelve aircraft managed to fly 1.8 million miles without a serious accident. The U.S. Army accepted the Model 299, and eventually ordered 12,731 of the aircraft. This was then numbered the B-17. The B-17 went on to become the most widely used aircraft in WWII". 

The use of checklists therefore helped rescue Boeing.

• There is more than one way to use a checklist

We can read more about pilot checklists in this great blog post from SafetyCulture entitled "Lessons We Can Learn From Aviation Checklists". For example there are two ways to read a checklist - Do-Confirm, or Read-Do

"Do-confirm is generally used when team members are experienced and have gone through the necessary steps within the checklist and simply run through it to ensure they’ve been done. With a Read-do checklist, team members perform the tasks as they’re reading through the checklist, similar to a recipe"

Also they suggest that checklists should be linked to identified pause points, should be between 5 and 9 items, on no more than one page, and written in simple language. They also suggest that the process of testing a checklist in practice generates buy-in among the users.

"Testing the checklist ensures you’ve identified all the right pause points, kept it short enough, and that it is easy to understand. The aim of implementing checklists is not simply to have people read through it and check off items. The aim is to incite a cultural change by enhancing teamwork, increasing communication and changing the definitions of authority within a team. The aviation industry has seen clear safety improvements by implementing checklists into their everyday processes, but they also experienced a cultural shift that changed the way teams work together. Checklists have redistributed the responsibility of safety amongst team members by successfully leveraging the team’s collective knowledge".

Finally the post makes the point that changing the culture takes time, and that aviation safety only really began to improve from the 1980s onwards - 40 years after the first checklist was introduced.

• The concept of checklists does not always translate to other industries

As this blog post, entitled Checklists don’t work* (*sometimes, particularly if you get implementation wrong), points out, translating the concept of checklists from one industry to another is not simple. It describes how early successes with checklists in the medical sector have not been widely adopted, and suggests that the failure was all in the implementation, as follows:

• Staff resisted, or failed to complete the checklist
• The checklist was dismissed as "illogical or inappropriate".  
• It was just another ‘initiative’ dropped on front line staff by Managers and Administrators. It felt ‘Imposed’.
• It didn’t fit the local context. 

To these reasons you could add the factor of the immediacy and visibility of results in the medical sector (as discussed in my post "why don't good ideas spread better"), and also perhaps the fact that in the event of disaster, a doctor does not "go down with the plane" like a pilot does, so the level of personal involvement is not the same as it would be for a B37 pilot, for example.

This Nature article suggests that one part of the solution for improving adoption is to allow hospitals to "localise" their checklists, and another is to observe and coach their introduction.

Experts recommend that hospitals modify standard checklists to help the tool fit into the local workflow and to produce a feeling of investment and ownership. Pronovost (anaesthesiologist, critical-care physician and checklist pioneer) encouraged the ICUs that participated in the Keystone project to make his checklist their own. “They were 95% the same, but that 5% made it work for them,” he says. “Every one of these hospitals thought that theirs was the best.”  

(Also) Providing the hospitals with regular feedback on their infection rates created social pressure for improvement, they say, and regular in-person workshops allowed staff from different hospitals to share their experiences and created the sense of a shared mission.

Summary
Checklists can work very well, and saved Boeing from commercial disaster. However their application needs care and attention, and needs to be implemented well and sensitively. They are not guaranteed to work - at least not immediately!

If you are working with tasks which are "too much for one person to remember in the heat of the moment" then the use of checklists may be perfect for you.

When you need knowledge "just in case" rather than "just in time".

There is a lot to be said for "Just in time" Knowledge Management. However sometimes you need to capture knowledge "just in case"

Image from wikipedia

Often it can be a good principle to drive knowledge management by "knowledge pull".
When people need knowledge, they seek for it and find it. Knowledge is drive by need, and delivered "just in time". Just in time knowledge and knowledge pull is a very efficient approach to KM.

But sometimes, it's just too urgent to "learn before" and to rely on "just in time knowledge".

Imagine a disaster - a fire, or a rail crash, or an accident. Here, time is at a premium. There is no time to pull knowledge, and no time for "just in time". Unless the knowledge is at your fingertips immediately, it will be too late. In cases like this, the knowledge needs to be prepared in advance - just in case it is neeed.

Think about an aircraft that gets into trouble, for example. There is no time for the pilot to get in touch with other pilots and ask them for advice, or to call headquarters and ask what to do. The knowledge has to be prepared in advance, just in case its needed. And for the majority of airline incidents, that knowledge has already been prepared as checklists.

Read this transcript from a cockpit voice recorder (from Atul Gawande's book "the checklist manifesto") and see how the pilots, faced by an emergency situation, reach for their checklist.

BANG (explosive decompression of cargo doors, windows blow out of business class, 9 passengers lost)CAPTAIN “what the f*** was that”FIRST OFFICER “I don’t know”FO “put your mask on, Dave”C “Yeah”FO “Honolulu Center – did you want us to turn left?”RADIO “Continental One Heavy Affirmative”FO “Turning now”C “I can’t get any oxygen”FO “What do you want me to do now?”(Unidentified voice) “F***”FO “You OK?”C “Yeah. You want me to read the checklist?”FO “Yeah, I got it out. When you’re ready”C “Ready”

In a situation like this - when a plane explodes, a train crashes, an oil rig blows out, a factory catches fire - you had better have prepared the knowledge in advance, because there won't be time to "learn before".

2 ways of collecting knowledge - black boxes and checklists

Lets look at two elements of the learning system in aircraft - the black box recorder, and the pre-flight checklist - as analogues for elements of Knowledge management. 

Image from wikimedia commons

Both the black box recorder and the pre-flight checklist are knowledge tools in the aviation industry and both represent aspects of knowledge capture.  The black box recorder is a raw data-capture tool, that captures data within flight. The pre-flight checklist is a distillation of data from millions of successful flights and thousands of accidents, designed to give pilots the knowledge of successful flight procedures. Both have their part to play.

The black box recorder records flight data, such as airspeed, altitude, heading, conversations in the cockpit, so that if anything goes wrong in flight there is a better chance of working out what went wrong, and why, and therefore how this can be avoided in future.

The pre-flight checklist on  the other hand gives the pilot a structured way to ensure nothing goes wrong, by running through a series of checks before the plane takes off.

The pre-flight checklist is linked to, and is an outcome of, results from black box recorders. However there is a complex process between the two of data review, root cause analysis, solution-finding and validation, derivation of new process, and distillation into a checklist. Very few black box recordings are ever reviewed - only those from extraordinary events, because it is the extraordinary events that create the new knowledge.

Capturing knowledge in the office

It can be tempting to approach project knowledge capture through black-box-recorder-like techniques. Live meeting capture, for example. Or live capture of project decisions. Or ensuring all project records are filed and passed on.  I heard a Microsoft representative the otehr day say that "our aim is to capture knowledge through capturing all work products as work progresses, because nobody ever takes the time for post-project review".  Microsoft (or at least this representaive) sees KM as a black box recorder.

These approaches create a lot of data, but create little knowledge, and would be massively labour-intensive to interrogate. The simplify to the point of non-existance the process of knowledge recording, but massively increase the work of the learner trying to gain knowledge. Expecting future projects to learn from this material is a bit like expecting pilots to learn directly from black box recorders.

Better to invest in the project project learning review, and ensure people DO take the time to review, to do the root cause analysis, solution-finding and validation, and the derivation of new process, and distillation into guidance for future projects.

The next project will benefit far more from a pre-project checklist that it will from a black box crammed full of project records.

Knowledge management for chefs, or for recipe-followers?

People often use the analogy of chefs and recipe users within Knowledge Management, frequently arguing that chefs are liberated by knowledge, and recipe-followers are straight-jacketed by "best practice". True to form, I challenge this view. 

Being a chef, in KM terms, is often seen as "good" - creative, relying on tacit knowledge, at teh cutting edge of their craft.

Being a recipe-follower, or a user of best practice, is seen as "bad", and you will find many KM sites that use the term "best practice" as a boo-word.

However in the world of business there are places in Knowledge Management for "chefs", and places for "recipe followers", and the KM practitioner needs to know which approach to use when.

Firstly, for mature knowledge, especially with a high turnover of new staff, you primarily need people to follow recipes. You don't need to be a chef to make a white sauce, or to boil an egg. However even for this basic stuff, the complete beginner may need a beginners guide to follow (see Delia Smith's recipe "How to boil an egg").  The newest people joining your company will need a recipe book for mature knowledge, just to get them started on the basic things.

Where knowledge is mature, following a recipe can be a far more effective strategy than calling in a chef.

For some companies, the primary KM problem is educating the new people, because either of massive growth or of massive churn. The combination of rapid onboarding, rapid networking, and very good explicit guidance, needs to be part of the KM strategy  (for example in the Chinese car industry, where the average age of the engineers is 23, or in telecom businesses where the annual churn rate may approach 40%). So to bring these new people up to speed with mature knowledge, they need a recipe book to follow, as well as access to chefs when things go "off-recipe".

Secondly, creativity may be crucial, but so is productisation. A chef may have a brilliant idea, but the most successful industries are not always those with the best ideas, but the ones that bring those ideas rapidly to market. Once the chef has the new recipe, the recipe followers can rapidly spread it through the market and capture the market share.

Also there can be good business in following a recipe - McDonalds, Taco Bell, Pizza hut, to name but a few, make a global business out of it. For purely financial reasons, a share in McDonalds is probably a better bet than a share in Gordon Ramsay inc (though these might be outweighed by other reasons). A commercial business needs creative poeple to come up with the new ideas and new products, and then needs an army of people following them, to get these ideas to market.

Thirdly, for the most critical knowledge, even a chef follows a recipe. Think of an experienced airline pilot taking off from heathrow. He or she goes through the pre-flight checklist step by step, "following the recipe". If I were on a plane, and the pilot came on the intercom and said "Ladies and gentlemen, I am a highly knowledgeable pilot, I have decided not to bother with the preflight checklists today" then I would expect there to be an instant mad rush for the exits.

Or a surgeon, with the pre-operational checklists described in Atul Gwande's book, which I covered in this blog post on checklists. As I say in the post, most jobs nowadays are incredibly complex. The human brain can only remember so much at one time, and suffers easily from overload. Most mistakes are made, not because we don’t know what to do, but because we forget (or skip) a crucial step, especially in emergency situations. We need to be reminded of what we know, and what we need to remember. Checklists (recipes) force us to stop and review, remind us of what needs to be done, take us through the critical steps, ensure we remember the right things, ensure we ask the right questions, and ensure we have the right conversations. And updates in checklists as a result of new knowledge, can remind us to do new things.

Fourthly, too many chefs spoil the broth. Every kitchen needs a chef, then they need some sous-chefs, then they need a whole stack of people to follow recipes and follow orders. SImilarly every organisation will contain a whole spectrum of knowledge workers, and on each stage of their knowledge journey, they need their knowledge delviered or developed in a differrent way. We all start off as recipe followers, some of us end up as chefs, but we are all knowledge workers and Knowledge Management needs to address all our needs.

How checklists can remove the threat to the expert

Experts sometimes feel threatened by Knowledge Management, yet the example below shows that this may not need to be the case.

I posted some years ago about checklists in KM, and how these have been used in hospitals to make remarkable improvements in patient safety statistics related to surgery.

Hospitals are very hierarchical places, especially in the operating theatre. There is the surgeon - the epitome of embodied knowledge, the expert in their field who can take life and death into their hands. Then there is the anaesthetist - another knowledgeable expert, but not of the status of the surgeon. And then there are the theatre nurses who mostly are generalists rather then experts.

Introducing knowledge management into this situation might be tricky. What surgeon is going to want to be told what to do? They are experts, they have the knowledge, and challenging their specialist surgical knowledge is like a personal challenge.

However we know that medical checklists have been use as a simple KM tool to cut patient deaths by more than 40% and complications by more than a third.

If you follow the link above, or watch the video below, however, you find that the checklist is not about the specialist knowledge at all.  It's interesting to see how much of the checklist deals with communication within the theatre team.

10 of the 14 checkboxes in the blue and green checklists  are about communicating and reviewing as a team, rather than the expert knowledge of the individual.  It seems that this is taken for granted, and that the areas for improvement are not related to how the specialists work individually, but about how the knowledge and actions of the whole team is brought together.

Sometimes the simplest KM tools are the best - a simple checklist, driving communicating about the important items, just to make sure that nothing is missed and no corners are cut, is enough

Watch the checklist in action below

Great NASA story on checklists

The NASA CKO office publishes a series of "learning from experience" stories on their blog called "my best mistake".  This is a great way to spread the concept that mistakes make great learning opportunities.

Photo from wikipedia

I really like this story from David Oberhettinger

It's not so much a "mistake" story as a "value of learning" story. David tells how we was in a small plane preparing for landing when..............

Suddenly, dense black smoke begins to fill the cockpit. I flip the checklist over and follow the five steps listed on the back under In-Flight Electrical Fire:

• (1) Master Switch to Off
• (2) Other Switches (Except Ignition) to Off
• (3) Close Vents/Cabin Air
• (4) Extinguish Fire (in this case, I isolated a faulty transponder)
• (5) Ventilate Cabin

These steps took maybe 90 seconds. Then we descended to an uneventful landing. The crisis hardly caused a significant increase in heart rate, because I just followed the checklist.

I have written before about how checklists are a fantastic way to provide knowledge to the decision maker at the point of need, and there can be no more graphic indication of the "point of need" that a smoke-filled cockpit of a small aeroplane.


However David then goes on to talk about how that checklist ended up in his hand.

• The formal checklist as a concept derives from a lesson that was learned on October 30, 1935, during a test flight of the B17 bomber prototype. The pilots attempted to take off with the tail wheel locked; this prevented the wheel from swiveling and resulted in a crash and the death of both pilots. From then on, Boeing provided a printed checklist with each production version B17. (Previously, pilots were expected to make their own checklists.) 
• Today, all airplane manufacturers provide a pilot’s handbook containing checklists specific to the model of plane

Therefore, when you buy the plane, you buy the knowledge of what to do in any form of emergency.  This is an excellent example of a "knowledge supply chain", which had become standard practice in the aviation sector because of the life-saving value of the knowledge.

As David concludes

Why do I love checklists? Because a checklist helped avert what could have been some serious unpleasantness. And because rather than letting my imagination run amok to my detriment (otherwise known as “panicking”), effective use of checklists allow me to direct my imagination to more productive purposes.

Black boxes and checklists

---

Lets look at two elements of the learning system in aircraft - the black box recorder, and the pre-flight checklist - as analogies for elements of Knowledge management.

The black box recorder is a raw data-capture tool, that captures data within flight.

The pre-flight checklist is a distillation of data from millions of successful flights and thousands of accidents, designed to give pilots the knowledge of successful flight procedures.

The pre-flight checklist is linked to, and is an outcome of, results from black box recorders. However there is a complex process between the two; of data review, root cause analysis, solution-finding and validation, derivation of new process, and distillation into a checklist. Very few black box recordings are ever reviewed - only those from extraordinary events, because it is the extraordinary eents that create the new knowledge.

It can be tempting to approach project knowledge capture through black-box-recorder-like techniques. Live meeting capture, for example. Or live capture of project decisions. Or ensuring all project records are filed and passed on. These approaches create a lot of data, but create little knowledge, and would be massively labour-intensive to interrogate. Expecting future projects to learn from this material is a bit like expecting pilots to learn directly from black box recorders.

So if you are applying these techniques, invest also in the processes of data review, root cause analysis, solution-finding and validation, derivation of new process, and distillation into guidance for future projects, whether this is a checklist or a wiki or a guidance document.

Chefs and recipe followers

---

People often use the analogy of chefs and recipe users within Knowledge Management, frequently arguing that chefs are liberated by knowledge, and recipe-followers are straight-jacketed by "best practice". Being a chef, in KM terms, is seen as "good". Being a recipe-follower, or a user of best practice, is seen as "bad" (and you will find many KM sites that use the term "best practice" as a boo-word).

True to form, I challenge this prevailing view.
There are places in KM for "chefs", and places for "recipe followers", and the KM practitioner need to know which approach to use when.

Firstly, for mature knowledge, especially with a high turnover of new staff, you primarily need people to follow recipes. You don't need to be a chef to make a white sauce, or to boil an egg. But even for basic stuff, the complete beginner may need a beginners guide to follow (see Delia Smith's recipe "How to boil an egg").  The newest people joining your company will need a recipe book for mature knowledge, just to get them started on the basic things. Following a recipe is a far more effective strategy than calling in a chef. And for some companies, the primary KM problem is educating the new people, because either of massive growth or of massive churn. The combination of rapid onboarding, rapid networking, and very good explicit guidance, needs to be part of the KM strategy  (for example in the Chinese car industry, where the average age of the engineers is 23, or in telecom businesses where the annual churn rate may approach 40%). So to bring these new people up to speed with mature knowledge, they need a recipe (as well as access to chefs when things go "off-recipe").

Secondly, creativity may be crucial, but so is productisation. A chef may have a brilliant idea, but the most successful industries are not always those with the best ideas, but the ones that bring those ideas rapidly to market. once the chef has the new recipe, the recipe followers can rapidly spread it through the marte and capture the market share. And there can be good business in following a recipe - McDonalds, Taco Bell, Pizza hut, to name but a few, make a global business out of it. For purely financial reasons, a share in McDonalds is probably a better bet than a share in Gordon Ramsay inc (though these might be outweighed by other reasons). A commercial business needs creative poeple to come up with the new ideas and new products, and then needs an army of people following them, to get these ideas to market.
Thirdly, for the most critical knowledge, even a chef follows a recipe. Think of an experienced airline pilot taking off from heathrow. He or she goes through the pre-flight checklist step by step, "following the recipe". If I were on a plane, and the pilot came on the intercom and said "Ladies and gentlemen, I am a highly knowledgeable pilot, I have decided not to bother with the preflight checklists today" then I would expect there to be an instant mad rush for the exits. Or a surgeon, with the pre-operational checklists described in Atul Gwande's book, which I covered in this blog post on checklists. As I say in the post, most jobs nowadays are incredibly complex. The human brain can only remember so much at one time, and suffers easily from overload. Most mistakes are made, not because we don’t know what to do, but because we forget (or skip) a crucial step, especially in emergency situations. We need to be reminded of what we know, and what we need to remember. Checklists (recipes) force us to stop and review, remind us of what needs to be done, take us through the critical steps, ensure we remember the right things, ensure we ask the right questions, and ensure we have the right conversations. And updates in checklists as a result of new knowledge, can remind us to do new things.

Fourthly, too many chefs spoil the broth. Every kitchen needs a chef, then they need some sous-chefs, then they need a whole stack of people to follow recipes and follow orders. SImilarly every organisation will contain a whole spectrum of knowledge workers, and on each stage of their knowledge journey, they need their knowledge delviered or developed in a differrent way. We all start off as recipe followers, some of us end up as chefs, but we are all knowledge workers and KM needs to address all our needs.

More on checklists and communication

---

I posted a while ago about checklists in KM, and how these have been used in hospitals to make remarkable improvements in patient safety statistics.

And  again more recently I blogged about how better communication saves lives in the intensive care unit.

Since then, I have found an example of the medical checklists which are used in surgery. It's interesting to see how much of the checklist deals with communication. 10 of the 14 checkboxes in the blue and green checklists  are about communicating and reviewing as a team. Sometimes the simplest KM tools are the best - a simple checkist, driving communicating about the important items, just to make sure that nothing is missed and no corners are cut, is enough to cut deaths by more than 40% and complications by more than a third.

Watch the checklist in action below

KM and the overloaded expert

---

Heavy Load
Originally uploaded by feserc

Tom and I are working on another book in our "Knowledge Management For......." series, this one on Knowledge management for Sales and Marketing (see here for a list of the others). There is a very interesting chapter in there by Graeme Smith, on KM along the supply chain in the Ordnance survey. I won't tell you the whole story (he tells it very well in the book), but there is one point that really struck me.

Before the Ordnance Survey applied KM to their supply chain, they did an audit of supply chain activity, and measured the level of conformance with process. In other words, how much time were people spending doing their core role and core process, and how much doing other things, including rework.

They found a level of non-conformance in some areas of 80%. These people, most of whom were very experienced, were spending 80% of their time not doing their job.

Graeme explains

Closer inspection of the data and workplace analysis of activities measured, revealed the nature and extent of the role these individuals were playing within the social network.
The most revealing aspect of their role was the fact that the rest of the organisation was using them as knowledge experts. They were being exploited for their knowledge; the position they held in the value chain; their propensity to help others solve customer problems; and, to a certain extent, by their own management who left them alone simply because they "got things done" and helped the team achieve their key performance indicators.

As a result of staff movements and retirements, these individuals were having to deal with increased demand and conversely were becoming a scarce resource and a growing risk to the business. Their own lack of capacity to create and innovate change in the process, due to volume pressures was reducing their ability to transfer knowledge to others. Of immediate concern to management was the high degree of risk that this built into the process. Individuals leaving their role would see a collapse of the social network previously dependent upon their knowledge.

That is a vision of Knowledge management being done because it is needed to be done, but being done with absolutely no support or strategy or structure or process, and as a consequence resulting in a very risky and unsustainable situation.

The Ordnance Survey took a number of actions to address this, including reworking processes, codifying expert knowledge into a "knowledge and learning pack", and a major program of retraining. But what can YOU do in your organisation, if you find people playing the expert role at the expense of their day job?

1. You can make the expert role into their day job! Its obviously what's needed to be done, and they are obviously the right people to do it. See blog post 
2. You can start to codify as much as you can; into processes, wikis, checklists etc
3. You can build the communities which can support the expert

But don't leave it with the poor overloaded individual, with only 20% of capacity left for their official job. That way, you are heading for a fall.

Checklists in KM

---

Flight deck of the Cessna Citation
Originally uploaded by cliff1066™

I don't know if you have read the Checklist Manifesto? You ought to. It's extremely interesting for the KM professional. I read it recently, and something clicked for me as I went through it. It answered a question I have been struggling with for a long time - which is, how do we get knowledge back out into the organisation?

Identifying new knowledge is relatively easy. Updating practice, as a result of new knowledge, is not too hard either. Getting people to change their behaviour as a result is extremely difficult.

But listen to this story.

17th Jan, 2008, Times Online “Passengers aboard the BA38 from Beijing were reflecting on their lucky escape, after all 136 were safely evacuated when the stricken aircraft tore into the tarmac. Only three suffered minor injuries. A formal investigation is under way to find out what led one of the safest aircraft in the world to crash land at Heathrow airport this afternoon”.

13 May 2008, London Evening Standard “The British Airways plane that crash landed at Heathrow may have suffered from "fuel freeze" caused by cold weather, according to investigators. First Officer John Coward was forced to glide the Boeing 777 to safety after both engines failed at 600ft on flight BA38 earlier this year. The Air Accident Investigations Branch (AAIB) interim report into the incident on 17 January has indicated a drop in temperature to -76C (-105F) while flying over Russia may have caused the fuel to thicken, depriving the engines of the additional thrust needed to land”.

As a result of this investigation, new knowledge was created - How to stop ice forming in the fuel on polar flights, and how to recover flight control if icing causes engine failure (counter-intuitively – you cut the throttle instead of increasing it. This allows the heat of the engine to melt the ice and restore the fuel flow).

New knowledge.

And how long do you think it took for every 777 pilot in the world to update their flight practices with this new knowledge?

According to Atul Gawande, author of the Checklist Manifesto, it took 30 days.

Only 30 days for every 777 pilot in every airline in every country in the world.

How long does it take your company to incorporate new knowledge? 30 weeks? 30 months? Atul reckons that a new surgical procedure, in contrast, takes 17 years to be globalised. The difference is that pilots codify everything they know into checklists. They share them widely, and use them rigourously.

Most jobs nowadays are incredibly complex. The human brain can only remember so much at one time, and suffers easily from overload. Most mistakes are made, not because we don’t know what to do, but because we forget (or skip) a crucial step, especially in emergency situations. We need to be reminded of what we know, and what we need to remember. Checklists force us to stop and review, remind us of what needs to be done, take us through the critical steps, ensure we remember the right things, ensure we ask the right questions, and ensure we have the right conversations. And updates in checklists as a result of new knowledge, can remind us to do new things.

Atul has some fascinating stories to tell of introducing checklists into hospital surgery theatres, the pushback that he received and the difficulties that he met, but also the remarkable improvements in patient safety statistics that were made as a result.

However here's an anecdote to close out our story.

November 26, 2008, Delta Airlines from Shanghai to Atlanta.

39,000 ft above Montana the flight crew experienced “uncontrolled rollback of the right engine” due to ice in the fuel line. The pilot and co-pilot followed the revised checklist, the engine restarted, and none of the 247 passengers knew that anything unusual had happened.

That's effective learning in action.

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.