Why "Knowledge for action" is better than "knowledge for storage"

Knowledge has to lead to action in order to add value. 

call to action by Sean MacEntee on Flickr

As the blogger Bill Wilson says (in the context of root cause analysis) “Learning without action is mere mental trickery, while action without learning is simply useless physical exercise”.  If knowledge management is to deliver more than mere mental trickery and to live up to its promise of adding value, then it must lead to action.

A few years ago we worked with a client who was developing a lesson learning system from projects. The collection of lessons has been going well, but the client had the firm view that lessons should be stored in a library that future projects could review if they wanted. For them, the knowledge would be stored “for future reference”.

Of course, few people have time to read through the lessons, and there are now so many lessons that reading through them is becoming more and more daunting. 
We are now helping the client to move to a different philosophy, where lessons are forwarded to the owners of the organisational processes, so they can continue to update the processes, procedures and guidance in the light of the new learning. This is “knowledge for action”, and if we assume that people follow the updated guidance, it should result is less “useless physical exercise” and to more efficient ways of working.

This philosophy is that wherever possible, every piece of new knowledge should lead to an action. The action might be;

  • Fix a problem,
  • Investigate further (especially if the learning is not yet clear),
  • Document a new procedure, process or guidance document,
  • Update an existing documented procedure, process or guidance document,
  • Update a training course or other training or e-learning material,
  • Circulate the lesson for others to decide on an action.
Communities of practice, as well, should focus on creating and managing actionable knowledge. Actionable knowledge can be stored on the community wiki, and includes

  • Advice and guidance
  • Good practices
  • Improved practices
  • Solutions to problems
  • Answers to questions
  • New approaches
  • Recommendations
  • Tips and Tricks
Non-actionable knowledge is
  • Interesting articles
  • Links to interesting articles
  • Musings
  • Quotes and aphorisms
  • Descriptions of what you are doing (unless you analyse this to bring out actionable learning)
  • Descriptions of what you have done (unless you analyse this to bring out actionable learning)
  • Large document stores
Communities that circulate non-actionable knowledge, or “knowledge for interest” are classified as Communities of Interest rather than communities of practice, the clue being in the title. 

CoPs deliver more value when they focus on solving the problems of the members than when they circulate “interesting links and ideas”. CoPs that operate through a Pull process – where members with problems or issues ask questions and receive recommendations and support from other members – know they are adding value.  Each answered question represents a solved problem; knowledge which the person who asked the question can immediately put into action.

So when you are sharing knowledge in a CoP, ask yourself whether you are sharing “something that others will find interesting” or “something that will help people do their job better” – something actionable.

And when you are designing lesson learning systems, make sure each lesson leads to action, rather than being retained “for interest”.

We recommend “knowledge for action” rather than “knowledge for storage” as being a far more effective system.

View Original Source (nickmilton.com) Here.

How to calculate the transmission efficiency of lessons learned

The lesson learning system should be a supply chain for new knowledge. But how do you calculate its effectiveness?

We can look at lesson learning as a supply chain; identifying new pieces of knowledge and supplying them to other knowledge workers so they can improve their work. If it works well, knowledge is gathered, accumulated, synthesised into guidance, and used to inform future operations.
But how well does this supply chain work, and how can you calculate its efficiency?
This is something I tried to measure recently with a client, using a survey.
I divided the lesson supply chain into three steps, shown below
  1. Capture and documentation of lessons from project experience;
  2. Update of guidance documents based on new lessons;
  3. Review of guidance documentation in future projects.
Now this particular client  did not have a clear supply chain for lessons, so many people accessed lessons through search.
I therefore asked survey respondents to estimate in what percentage of cases the following happened, giving them the options to selecting 0%, 20%, 40%, 60%, 80% and 100%. The average estimate from the survey responders is shown below.

  • Any given project documents lessons (46%)
  • Any given lesson is used to update guidance documents (32%)
  • Any given project makes use of guidance documents (43%)
  • Any given project seeks for documented lessons (44%)
  • Any given search finds useful lessons (36%)
We can then use these figures to estimate the effectiveness of lesson transmission, as shown in the diagram above, and described below.
The effectiveness of transmitting lesson through guidance is 46% (capture) x 32% (update) x 43% (review) = 6%.

The effectiveness of transmitting lesson through search is 46% (capture) x 44% (search) x 36% (find) = 7%.

These are pretty low figures! Even if both routes were independent and there was an overall success rate of 13%, that still means that 87% of project knowledge was never transmitted other than via human memory.

Let’s compare that with an organisation that treats lessons seriously. The diagram and numbers below are not from a survey, but from published statistics in another organisation. This organisation does not require users to search for lessons, but has a well-resourced supply chain to embed lessons into procedures and guidance.

  • Any given project documents lessons (100% – lesson capture is mandatory part of every project, and supported by dedicated resources)
  • Any given lesson is used to update guidance documents (93% – this figure was tracked on a quarterly basis and the “closure rate” for lessons varied between 88% and 95%)
  • Any given project makes use of guidance documents (100% – all activity was directed by operational procedures which were reviewed and use to make the action plans)
The overall transmission efficiency is 93%

Please note that these figures only reflect the documentation of lessons and their transmission to future knowledge workers; they don’t include the loss of knowledge in the documentation process, or the issues of transmission of understanding from writtenprocedires into the human braid – they only look at the effectiveness of the supply chain of written lessons.

This effectiveness can be measured, through surveys or through lesson tracking, and we can see that is can vary between very ineffective (as low as 6%) or extremely effective (as high as 93%).  If you are applying lessons learned, then aim for high effectiveness!

View Original Source (nickmilton.com) Here.

Why you should never leave your lessons in the project report

Probably the worst place to store project lessons is to leave them in the End of Project Report.

Tombstone created using http://tombgen.appspot.com/

I know this is still the default approach for many project organisations, and 19% organisations who run KM programs still use this approach (according to our KM survey). However this approach was linked to the second-lowest satisfaction score for lesson learning, second only to “we don’t store our lessons anywhere”. So leaving lessons in project files is only slightly better than not storing them anywhere.

But why is this the case?

It makes sense for the project team to leave the lessons in the report, because lessons are a project output, and surely all project outputs are documented in the report? Once the report is written, the job of the project team is done.

However although the job of the lesson writer may be over, the job of the lesson-seeker is only just starting.

People searching for lessons (whether they are people in future project teams, or subject matter experts maintaining process documentation) will be searching for lessons to help with a specific issue, risk, process or task. They would like to find all the lessons associated with that issue, risk or task in the same place. They almost certainly will not know which projects learned lessons on which topic. They don’t want to have to go back through 20 or 30 project reports, looking through the lessons learned section of each one, just in case there is something of relevance.

Therefore they don’t bother.

The lessons remain unread; the project report becomes a tomb in the lessons graveyard. Learned once, and destined to be relearned in future.

Two of the basic principles for effective lesson learning are that you need to 1) capture lessons individually, and 2) store them centrally. As I pointed out in yesterday’s blog post, lessons are a knowledge output from a project, and should be stored with the rest of the knowledge, not the rest of the project files. In order to make it easy for the lessons to be found, you need to store the individual lessons under themes or topics in a lessons management system until they make their way into updated practice and procedure, guidance and training.

 If lessons are being learned from many projects, for example from Retrospects and After Action reviews, then these lessons need to be stored somewhere where they can be compared, reconciled, and actions assigned, notified, tracked and managed. They need to be captured in a consistent format, and stored in a central system.

 This is often done in some sort of Lessons Management System, set up either for a major business stream such as Sales or Engineering or for the entire organisation, to store and track lessons from many projects.

An effective lessons management system should be structured according to the needs of the “knowledge user”. People who come to access lessons from the database should be able to find what they are looking for very easily. If they don’t find relevant and useful knowledge within a few minutes, they will leave and never come back.

Think about the needs and interests of the knowledge user, think about how the knowledge will be re-used, and think about how you should structure the database to most easily give them access to what they need.  The knowledge seeker is  looking for lessons about procuring steel pipe for example, or for all the lessons to do with safety while working at height, or for all the lessons to do with partnering with a particular national authority; in other words, lessons to do with the particular issue that they face. The lessons therefore need to be grouped into a structure,  index or taxonomy, based on work activity or work process. Think about how supermarkets gather and present produce, and use ideas such as this to stock your knowledge supermarket.

In addition, the lessons management system should be able proactively to route lessons and associated actions to the relevant process owner, in order that the lessons can be embedded in improved process, and can be declared properly “learned” and the learning loop can be closed.

Leaving them in the project report graveyard destroys the learning loop at the first step.

View Original Source (nickmilton.com) Here.

Lesson learning at NASA – video

From the AFAC lesson management forum last week, this video below from David Oberhettinger, NASA’s Jet Propulsion Lab, talking about lesson learning in their human and robotic space exploration program

David makes some interesting points, such as

  • the need to dedicate individuals for lessons capture (although NASA allows engineers to submit lessons themselves, he says he has never seen this happen in 25 years)
  • lessons need verification and quality control – particularly verifying the facts of what happened
  • lessons recommendations need to be “infused” into procedures and training to ensure closed-loop learning. The key documents are the JPL design principles and the JPL flight project practices, which are built up over time from the combined and synthesised lessons
  • weekly meetings of the lessons learned committee, for the past 35 years

View Original Source (nickmilton.com) Here.

Every lesson is a story

Capture your lessons as stories, that way they will be remembered more easily.

Native American Storytelling. Photo By: Johnny Saldivar

One of the way humans learn is through stories. Stories can Inform, Educate, and/or Entertain (transmit information, knowledge, and entertainment) and some of the best stories do all three.

A post from the Farnham Street blog entitled “The structure of a Story” tells us that a great story has structure, and includes Context, Action and Result; where Context includes Where, Who, What do they Want, and What’s getting in the way. As the blog says

“It all hangs on the central Context, Action, Result (CAR) structure. It starts with the Subject, Treasure, and Obstacle, and concludes with the Right lesson and link back to why it’s being told”.

When we transfer Knowledge, story is one of the best formats. That is equally true of lesson-learning as it is of the other elements of KM. Yet all too often, lessons fail to meet the test of a good story.

As the Farnham Street blog says, aspirant storytellers usually start with the Action, because that is the exciting part, and omit the context, and as a result the reader of the story or lesson cannot easily identify with nor internalise the learnings.

When we teach lesson-learning to organisations, we say that Every Lesson is a Story, and we recommend that the lesson has at least 6 components

1) Context. Here we explain what was expected to happen, but didn’t. This is the “What did we want” step of the story. It is amazing how many project teams or facilitators skip this step. Because “what was expected to happen” is so obvious to them, they expect it to be obvious to the reader, but of course it seldom is. 

2) Outcome. Here we explain what actually happened – the Action step of the story. What went wrong? What actually happened? 

3) Root cause. Here we explain WHY it happened – what the Obstacles were, what was missing that should have been there, or (in a success story) what was done to achieve the result. 

4) Impact. Here we explain or try to quantify the result, either negative or positive. 

5) Lesson. Based on the root cause, what is the learning for future projects? This is the “Right Lesson” part of the story.

6) Action to Embed.What action do we take to embed that lesson into business process, so mistakes are never repeated, and successes always copied.

A lesson with a story-based structure such as this takes about a page to write down or a couple of minutes to tell, compared to typical bullet-point one-liner lessons – told in seconds, forgotten almost as quickly.

However if we treat every lesson as a story, then we realise that it must be presented as a Narrative, with Context, Action and Result, concluding with the Right Lesson.

This is the simple structure that conveys the message.

View Original Source (nickmilton.com) Here.

The four most costly words in KM – "this time it’s different"

“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”.

View Original Source (nickmilton.com) Here.

Operationalising Lessons Learned in a small organisation

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.

View Original Source (nickmilton.com) Here.

Why admitting mistakes is so hard, and what we can do to counter this

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 by Meshl
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.

View Original Source (nickmilton.com) Here.

Lesson learning in the US Army – example from Haiti

Army learning is not just about fighting battles – here’s an example from disaster response

In 2010, the US Army was called in to provide humanitarian aid, including food and shelter, after a category 7 earthquake in Haiti. This article by the US contracting commend, entitled Lessons learned and used during Haiti deployment described how lesson learning made this a more efficient and effective process.

The article describes how, at the height of the response, the US Army supplied more than 15 million meals  in a 10-day period to the Haitian population, as well as setting up distribution points for families to receive boxes and bags of rice, beans and cooking oil. All of this required a supply chain and contracting and purchasing activities, and by the end of the mission, the Expeditionary Contracting Command had created more than 380 contracting actions valued at almost $12 million. Of course this supply chain needed to be slick and well organised, and to have learned from the past.

“We took advantage of a lot of lessons learned from previous deployments. We didn’t do these types of things early on in Operation Iraqi Freedom or Operation Enduring Freedom. However, we learned those lessons and brought these capabilities to Haiti early on,” said Brig. Gen. Joe Bass, commander, Expeditionary Contracting Command. “We were very proactive from the beginning, deploying the right personnel mix needed to provide quality assurance, legal, policy and other areas where we could address issues on the front end rather than after they’ve been done.

Lessons included

  • the personnel which needed to be deployed with the first troops, 
  • the need to set up a support centre in the US, 
  • the need for review and decision making boards in Haiti, 
  • creation of “pre-positioned deployable equipment packages”, and 
  • the correct level of decision making authority for procurement orders of different value from $100 thousand to $1 million.

The Haiti organisation did not just learn lessons from the past, they created new lessons to help future operations.

“Learning from the past helped us deploy quicker and smarter,” Bass said. “Just as we gathered lessons learned from previous deployments, we have gathered some from the Haiti deployment that should help us the next time we have to deploy. Moving forward means reviewing what we’ve done and how we have done it in the past, then reviewing it again and constantly using those lesson to better ourselves with each new challenge”

This is a great example of an organisation using lesson learning to continuously improve operations. 

View Original Source (nickmilton.com) Here.

Lessons Learned, or lessons lost?

Are you learning lessons, or losing lessons?

Kizar [Public domain], from Wikimedia Commons

A Lesson is an Investment

It might take a project team of 10 people, one day to create, through facilitated discussion, ten high-quality lessons. So each of these takes one man-day to create; say £500 – plus some write-up time – lets say £1000 per lesson to choose a nice round number.

However that lesson is encapsulated knowledge which, if re-used, may save man-months of wasted time and effort in the future, or tens of thousands of pounds of wasted cost. The project team have invested their time to deliver future ten-fold or hundred-fold return on that investment. That lesson may therefore be an investment worth £10,000 to £100, 000 when realized through application.

So what do we normally do with our investments?

Do we hide them in a hole and never look at them again? Do we file that share certificate in a drawer and never look at it again? Or do we track our investments until the time and situation is right to realise them? When it comes to money, we do the latter. But what about lessons?

Unfortunately, a common approach to lessons is to record them in a report, or on a spreadsheet, then put them into project files, and hide them in the online filing system. I heard a report a couple of weeks ago about a team that created some hugely valuable lessons, and stored them in security-controlled project files to which no other project was allowed access!

That’s not Lessons Learned; that’s Lessons Lost.

That’s like the last scene in Indiana Jones, when the Ark of the Covenant is put in a crate, and hidden in a vast warehouse of identical crates.

What we should do with investments, is put them in a managed portfolio, and we track them, until we find the opportunity to realise their value.

What we should do with lessons, is put them in a Lessons Management System, and track them, until we find the opportunity to reuse them or to embed them into process and procedure, thus realising the investment of time and effort that was put into generating them in the first place.

That’s Lessons Learned; rather than Lessons Lost.

View Original Source (nickmilton.com) Here.