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.

Knowledge Management in mega-projects

KM in mega-projects is much the same as KM in any project, but at a larger scale and a greater degree of rigour

image from wikipedia

Knowledge Management as applied to projects is a pretty well-understood field (see for example my book on Knowledge Management for Teams and Projects). It consists of a rigorous structure of Learning Before, During and After, and drawing on the knowledge of others in the organisation in order to anticipate, avoid, and (if necessary) solve problems.

So what's the difference between KM in projects, and KM in mega-projects?  The answer is, Nothing much! Other than the scale, the principles and practices are identical.

The advice below is for the megaproject leadership team.

Setting up the KM framework. The KM system for a mega projects needs to be more robust, and better resourced, than for a normal project. You will need:

• a KM policy for the megaproject
• a good and robust KM plan, including a definition of all the unknowns, and how to make them known
• a dedicated knowledge manager (potentially full time)
• a lesson management system for the  megaproject
• a wiki, and blogs, for building knowledge as the project continues
• a set of KM processes, as described below.

Learning Before. Because the costs, risks and unknowns are far greater in mega-projects, "Learning Before" is especially important. This includes learning from the project management structures of successful mega-projects (according to the book "Mega-projects and Risk", a lot depends on how the incentives are assigned and how the risks are allocated, for example), and learning from the typical reasons for cost and schedule over-run of megaprojects. One of the biggest causes of overrun is project wishful thinking - ignoring the unknown unknowns. These are things like

• discovering the soil conditions are far worse than expected
• finding unknown archaeological sites (Such as the unexpected discovery of 150-year-old revolutionary-era sites and Native American artefacts on the Boston "Big Dig")
• changes in government, leading to the need to renegotiate
• changes in commodity price

You can't know in advance what these are likely to be, but you can add in contingency, you can make a probabilistic risk, cost and duration estimate with some of these unknown unknowns included, and you can gather enough to knowledge to understand the major categories of risk, and have contingencies to deal with them. Knowledge management and risk management are closely allied in projects. Any megaproject should dedicate as much time as possible to Learning Before - forewarned is fore-armed.

Learning During. Mega projects are incredibly complex, and if mega-projects are to be able to learn, they need a comprehensive and integrated system for "learning During". Learning events such as After Action Reviews need to be a requirement for all contractors, there need to be Lessons Learned Integrators in all teams and in all contractors, each contractor needs a lessons log, with cross-team lessons escalated to a lessons management system, there needs to be a learning team at project leadership level, and part of their role needs to be to pick up the weak signals and the first inklings that problems need to be fixed. This is a military learning model, and many mega-projects are military in scale. Learning During is not something a mega project can afford to ignore - rapid learning can save you millions - and the megaproject should develop and implement its own internal knowledge management framework, complete with governance.

Learning After. The megaproject needs to hold Retrospects after every major milestone, and the learning needs to be not just about engineering, but about the way the whole project is integrated, the reason for any delays and overruns, and also the softer aspects such as culture, behaviours and communication. It may be politically difficult for megaprojects to produce open, honest and public lessons after the completion of the project, given the implications of liquidated damages, and given the typical ties between megaprojects and politics. That should not stop them from trying, however, especially if the intent is to provide guidance for future megaprojects. Certainly every company involved needs to collect and document their own internal lessons for future use. The megaproject leadership team should even consider the appointment of learning historians, so that the Learning History of the project can be constructed.

Drawing on the knowledge of others. There may be online global communities of practice for megaprojects that you can draw on such as the PMI and the CII, and you can potentially convene an advisory group of past mega-project managers who can act as a sounding board and who can provide advice and experience during the course of the project.

Knowledge management, if correctly applied, can be a major factor in the success of projects, driving down costs, duration and risk.

Where megaprojects are concerned, with their complexities, unknowns, and political pressures, Knowledge Management becomes absolutely essential.

Knowledge Transfer is the wrong concept - Knowledge co-creation is nearer the truth

In another post from the archives (with some updates) let's look at the common phrase "knowledge transfer" and discuss whether this is the wrong concept.

Knowledge transfer, when illustrated graphically, often looks like the picture below - knowledge leaving one head and entering another. 

THIS MODEL IS WRONG
image from wikimedia commons

This model is wrong in at least 3 ways.

Firstly when knowledge is shared, it doesn't leave the first head - it stays there. You do not lose anything when transmitting knowledge to someone else. You do not pass knowledge to someone in the same way that you pass money

Secondly, in many or most acts of "knowledge transfer" the giver also learns and gains.  A Peer Assist is a prime example - the people who come to share their knowledge often some away with more knowledge than they started.

Thirdly knowledge changes as it is exchanged. The receiver adds their knowledge to the knowledge of the donor, and makes something new and better. In fact, the concept of donor and receiver is probably wrong as well. Both parties give, both receive, and collectively create something new.

Knowledge is more often co-created than it is transferred in a one-way direction.

Think of the following examples;

• A Peer Assist, where peers from all over the organisation pool their knowledge to create new solutions and insights for a project team. This is not a case of one group of peers lecturing to another group; it is a setting for dialogue, where the peers collectively discuss how to apply knowledge from the past to challenges of the present and future.

• A meeting within a Community of Practice where SMEs come together to create best practice, pooling their knowledge to create something new. This again is not a meeting where people sit passively and listen; it is a setting for dialogue where practices are discussed with the intention of co-creating something better.

• A Knowledge Retention meeting between a senior and a junior - theoretically for the junior to learn, but where skilful questioning means the senior develops new insights into the practice. Both parties learn.

• An After Action Review where the team comes to a collective understanding of the lessons from an activity. This is not a meeting where the team leader briefs the team on what he or she learned; it is an all-hands discussion so the collective learning of the team can be identified, discussed and developed.

• People collaborating on a knowledge asset. This is not, or should not be, someone publishing a document for another to read. It should be more like collaboration on a wiki, containing knowledge supplied from many people and from many documents, and combined into something none of the people knew individually. Or collaboration on a checklist or a procedure, making sure the checklist is regularly updated as new knowledge becomes available, so that it becomes the record of knowledge from many many sources and the means to avoid all the mistakes of the past.

In each case this is not the transfer of something from one head to another, but co-creation of knowledge, or co-learning.

This co-creation is the C in the Nonaka and Takeuchi model - the idea of Combination of knowledge, so often missing in KM programs.

Perhaps Peter Senge said it best, in the following quote

"Sharing knowledge is not about giving people something,or getting something from them. That is only valid for information sharing. Sharing knowledge occurs when people are genuinely interested in helping one another develop new capacities for action; it is about creating learning processes."

The co-creation process therefore looks more like the picture below than the picture above.

Driving innovation by setting out-of-the-box targets

If you want people to think outside the box, give them a problem that's outside the box.

Image by nicubunu on Public Domain Clipart

There is a game I often play with a class, when we are on an innovation retreat such as a Business Driven Action Learning exercise.

We put people in a large circle, and give them a Koosh ball. The rules of the game are simple -

• All hold out your hands
• The person with the ball throws it to someone holding out their hands
• They remember who that someone is
• Once you have thrown the ball, put your hands down
• Continue until everyone has their hands down.

You, as facilitator, time how long this takes. Imagine it took 80 seconds.You say "Now do it again, passing the ball in the same order, but do it in 40 seconds".

You keep the exercise going, in several rounds, but you time each round, then cut this time in half to form the target for the next round. 20 seconds - 10 seconds - 5 seconds - 2 seconds.

What happens, is instructional.

• Firstly, people take the same approach as before, but try to work faster.
• Then, they tighten up the circle, reducing waste time
• Then they reorganise - reforming the circle so they are standing in the correct order
• Then when challenged even further, they start to think outside the box. They start to come up with radically creative solutions. Maybe we don't need to be in a circle? Maybe we lay our hands on the ground, and roll the ball over them? Maybe we form a tube with our hands (in the correct order), and drop the ball down the tube?

While the target can be achieved by working in the known way (working inside the box), creativity is limited to incremental innovations such as reorganisation or "working faster". 

When the target is outside the box - outside the realm of the known solution - people need to be radically creative. When they roughly know what to do, they use known solutions. When they don't know what to do to meet the target, they become radically innovative.

Impossible targets drive innovation. "Put a man on the moon and return him safely, before the end of the decade".  "Fly 500 people nonstop across the USA and be able to land at La Guardia". "A h-fi system you can put in your pocket". These were the impossible targets that resulted in the space program, the modern airliner, and the Sony Walkman.

If you want people to be innovative, set outrageous goals. If you want them to think outside the box, set them out-of-the-box targets.

The legal knowledge manager role (video)

The video below, from JD Careers Out There includes a legal knowledge manager talking about his role and career.

"Trust is important in KM" but what sort of trust?

We hear a lot about trust in Knowledge Management, but what sort of trust do we mean?

Image from wikimedia commons

It can't mean personal trust in the other people involved, at least not in a large organisation where it is impossible to know everyone, and indeed impossible to know OF everyone involved in KM. I think instead we are talking about trust in a System.

Maybe it is trust that the KM system is safe, reliable, predictable, and useful.

• Safe. People need to know that spending time on KM will not be disapproved of by management, that a community of practice or a knowledge sharing meeting is "a safe place to be", that they can ask naive questions without being mocked, that disagreement can be explored in a positive way without argument or flame wars, that Knowledge offered online or during a KM process such as a Retrospect will not be ridiculed, and that they will not be made to look bad by offering it, especially when learning from mistakes, or from failed projects (see more here)

• Reliable. People need to know that they will get a rapid, quality response to their questions in a community of practice, that use of a search engine will bring useful results without too much effort, and that lessons and knowledge they share will be routed to the right person, and that action will be taken as a result. See here for a story of loss of trust in an unreliable community. 

• Predictable. Communities of practice, in particular, suffer from "out of sight, out of mind" and the community that does not communicate is a community in decline. The leader needs to build and maintain predictable activity. People need to know that peer assists and lesson capture meetings are predictable and regular occurrences within a project. They need to know that knowledge assets will be updated in a regular and predictable way.

• Useful.  KM must build a brand and a reputation as being "a trustworthy means to deliver value"; both to the organisation and to the membership. People must be able to trust that attending a Knowledge management process such as a Retrospect or a community of practice event is a valuable use of time, and that they will come away with new and useful  knowledge.

As a summary, I offer you this quote from John Burrows and Kathy Buckman Gibson of Buckman labs (the source of which I have lost) -

"You have to be able to trust the knowledge and information that you receive to be the best that can be sent to you, and those that send it to you have to be able to trust that you will use the knowledge and information in an appropriate manner". 

ISO KM standard - link to webinar recording

Please find copied below a communication from BSI about the webinar earlier this week where we introduced ISO Management Systems standard 30401 - Knowledge Management, with a request to pass it on to other interested parties.

You can find below links to the slides that were presented, and to a recording of the webinar

Unlocking the value of knowledge - Introduction to BS ISO 30401

Email not displaying correctly? View it in your browser.

Dear Nicholas, Thank you for your interest in our Unlocking the value of knowledge - Introduction to BSI ISO 30401 Webinar. You can download the presented material below.    Download slides     Play recording  Please feel free to pass these along to colleagues who may be interested. We hope that you find it interesting and helpful in understanding the new standard. We look forward to welcoming you to other insightful discussions in the future.   Keep an eye: BS ISO 30401 will be published soon and you can follow the project status here.

For all general enquiries call +44 345 086 9001 or visit the BSI Group website Our mailing address is: BSI Standards 389 Chiswick High Road London, W4 4AL United Kingdom The British Standards Institution (BSI, a company incorporated by Royal Charter), performs the National Standards Body activity (NSB) in the UK. BSI, together with other BSI Group Companies, also offers a broad portfolio of business solutions other than the NSB activity that help businesses worldwide to improve results through Standards-based best practice (such as certification, self-assessment tools, software, product testing, information products and training).