The 4 steps of learning within a project

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.
  1. 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.
  1. 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.
  1. 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.
  1. Then of course comes step 5, where all of this knowledge is fed back to the organisation, as described yesterday.
And then, of course, at the end of the project, they can share what they have learned with the rest of the organisation.  All of these steps should be covered by the project Knowledge Management Plan

Through this series of steps, the project can build on the known and learn about the unknown in a planned and efficient way.

View Original Source ( Here.

The importance of "learning urgency"

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. 
There is a saying, by the Greek philosopher Epictetus, that “you cannot teach someone something they think they already know”. This means that if you give people problems they know how to solve, they will not look for additional knowledge, and they will not think outside the box. 
Learning, for them, will not be urgent. They will use the knowledge they have, do what they have always done, and deliver the performance they have always delivered. Safe, but no improvement.
An organisation can really drive Knowledge Management by giving people challenges they don’t know how to meet, or putting them in positions where they don’t know what to do. This is not as risky as it sounds, once KM is in place. 
Once KM is in place and is trusted, KM and management work together in delivering breakthough performance. Management gives people challenges they don’t know how to meet, KM provides the knowledge they need to meet them. 
Learning becomes both Urgent, and Easy. Everybody wins.

View Original Source ( Here.

The Risk Radar – what could possibly go wrong?

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.

View Original Source ( Here.

A lesson is not just something you learned, but something you can teach

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

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

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

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

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

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

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

View Original Source ( Here.

Why so much knowledge sharing, so little knowledge seeking?

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

Learning Happens
Learning Happens by shareski, on Flickr

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

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

  1. Starts by reviewing and accessing all the knowledge it needs,
  2. Learns as it goes, improving its processes during the course of the project, and
  3. Identifies, analyses, documents and shares the new knowledge it has gained, for the sake of future projects. 
For the project itself, the most powerful of the three is “Learning Before”. If a project can maximise it’s knowledge up front, especially if the team can discover the things it doesn’t know that it doesn’t know, then success is much more likely. “Learning Before” activities such as Knowledge gap Analysis, KM planning or Peer Assist can overcome some of the more serious cognitive biases for KM, and are the nearest thing to KM Silver Bullets that we have. Learning before activities drive receptivity, increase absorptive capacity, and help teams “want to learn”.  
And yet, when you look at internal company project frameworks, or even at  generic frameworks such as Prince 2 or ISO, there is almost always a requirement for capturing and sharing lessons after the project, and no such requirement for Learning Before. According to our global survey, 68% of companies require their projects to do some sort of Learning After, but only 15% require them to do Learning Before.  Prince 2 has a required, and well documented, step at the end, for creating lessons (although this could be much improved!), but has no step at the project start-up, requiring a search for, and review of, existing knowledge.  
This astounds me.

Why even bother to collect lessons at the end of a project, if nobody reviews them at the start of the next project!

I think the answer is that it is psychologically easier to share than it is to learn.  A project team can feel proud and recognised (even a little smug at times) for sharing lessons, while asking for lessons can feel like an admission of incompetence (“can anyone help me with this?”). 
Learning After is Teaching – Learning Before is Learning, which is Much Harder. Knowledge reuse is more difficult than knowledge sharing, yet that is all the more reason we should make it a focused and deliberate step. 
You get around some of these barriers by introducing non-judgemental techniques such as Peer Assist and Knowledge Management plans, which take the exposure out of asking for help, or seeking for knowledge. And you also address it by developing a culture of Asking, rather than a culture of Sharing.

Please, let’s introduce the full cycle of Learning Before, During and After, and let’s not skip the Before step!

View Original Source ( Here.

Learn from triumph and disaster

There should be no difference to learning from success and failure.

Kipling wrote, in “If” –  “if you can meet with triumph and disaster, and treat those two impostors just the same..”. 

As knowledge managers we try to collect lessons from projects which have been triumphs and projects which have been disasters, but these are seldom treated the same way by the project teams.

If you read through a lessons learned database from a British, US or Australian organisation, you get the feeling that projects never go right. The database will be full of lessons from failure, with almost no success-based lessons.

If you read through a lessons learned database from a Middle Eastern or Far Eastern organisation, you get the feeling that projects never go wrong. The database will be full of lessons from success, with almost no failure-based lessons.

OK, the statements above are generalisations and your particular company may differ, but there is a reality behind them representing two different biases; in the first case, the bias against “showing off to your peers”; in the second case, the bias against “appearing to have failed in front of your manager”. These two biases affect the way in which teams approach the collection of lessons.

In reality, of course, we need to learn from both success and failure, particularly when these are unexpected. We need to seize on, and repeat, the breakthroughs, and map out and eliminate the pitfalls. As someone from NASA told me a couple of years ago – there are no successes and failures, there are just events. NASA learns from events.  In other words, NASA treats those two impostors – triumph and disaster – just the same when it comes to learning.

Also as far as the user of the lessons is concerned, they don’t actually care whether the lesson came from success or failure, so long as
a) it is well written,
b) they trust the provenance, and
c) it helps them deliver their own project better, cheaper, faster.

In both the case of failure and success, the lesson will be written in the same way; a set of recommendations and advice, supported by context (in the form of a story) which helps them internalise the lesson.

So when you meet with triumph and disaster, success and failure, treat them just the same in terms of learning. 

View Original Source ( Here.

Is it possible for an organisation to learn?

Can organisations learn, or can only people learn? Some thoughts on the subject.

from creative commons images

We often hear about “organisational learning” but is learning something that organisations actually can do? Or is learning the province of people and animals? (Let’s put machine learning aside for the moment – that is another discussion).

There is a school of though that learning is a human attribute- that only humans are able to learn. After all, learning  requires a memory in which new knowledge can be stored. Humans  have a memory, but do organisations?

You could argue that organisations have two memories – one if the collective memory of the individuals in the organisation, often reinforced through stories and “shared experience”

The second memory is held in “the way we work” – the processes, procedures, doctrines, structures, norms, behaviours, organigrams, and the stories that are told. As one project person said to me – “our standard process is made up of all the lessons we have learned over the years”.

The first memory comes and goes with the people, and the effect of this can be observed in the cycles of unlearning you see in some organisations, where the same mistakes are repeated on a 5 to 10 year cycle as the older staff retire. The second memory is potentially longer-term, and survives the changeover of staff, but is also slower to build up and slower to respond to events.

However I would argue that this deeper slower memory is where real organisational learning can take place. An organisation, through activating learning activities and learning cycles, can steadily but surely change the way it operates, in response to events and to new experiences.

So, yes, organisations can learn. Organisations can modify their behaviour as a result of experience, and that, surely, is a form of learning. Maybe its more mechanistic than intuitive learning, maybe they don’t learn as fast or as well as a human does, maybe they learn more like the way a dog learns.

However I believe that organisations can learn if they develop a structure for learning. The bigger question is why don’t they learn better, and more often?

View Original Source ( Here.

What makes a good learner?

If you want a learning organisation, you need an organisation of learners. But what makes a good learner?

Here’s an article called “Seven Characteristics of Good Learners” by Maryellen Weimer, which addresses just that question.

According to Maryellen:

  • Good learners are curious – They wonder about all sorts of things, often about things way beyond their areas of expertise. They love the discovery part of learning. 
  • Good learners pursue understanding diligently – A few things may come easily to learners but most knowledge arrives after effort, and good learners are willing to put in the time to seek and to find. Good learners are persistent. They don’t give up easily. 
  • Good learners recognise that a lot of learning isn’t fun – That doesn’t change how much they love learning. Learning is hard work sometimes, but when understanding finally comes, when they get it, when all the pieces fit together, that is one special thrill. 
  • Failure frightens good learners, but they know it’s beneficial – It’s a part of learning that offers special opportunities that aren’t there when success comes quickly and without failure. In the presence of repeated failure and seeming futility, good learners carry on, confident that they’ll figure it out. 
  • Good learners make knowledge their own – This is about making the new knowledge fit with what the learner already knows, not making it mean whatever the learner wants. Good learners change their knowledge structures in order to accommodate what they are learning. 
  • Good learners never run out of questions – There’s always more to know. Good learners are never satisfied with how much they know about anything. They are pulled around by questions—the ones they still can’t answer, or can only answer part way, or the ones without very good answers. 
  • Good learners share what they’ve learned – Good learners are teachers committed to sharing with others what they’ve learned. They write about it, and talk about it. Good learners can explain what they know in ways that make sense to others. They aren’t trapped by specialised language. They can translate, paraphrase, and find examples that make what they know meaningful to other learners. They are connected to the knowledge passed on to them and committed to leaving what they’ve learned with others.

An organisation of such people would be a powerful learning organisation indeed.

View Original Source ( Here.

Keeping a decision log as an aid to learning

A decision log can be a useful tool in learning, and as part of a KM system

Dia 91: DecisionesMany projects and many non-project bodies maintain a decision log, to keep track of, and to publish, the major decisions which have been made. This allows you later to revisit the decisions, and understand the basis behind them, in the light of later knowledge. If you know why decisions were made, then you know whether and when to revisit them.

Some public bodies publish their decision logs, for example some of the UK police and crime commissioners have public decision logs.

But how helpful are these logs for learning purposes? A simple decision log will record which decisions were made, and by whom, but there is often no way to go back and understand why those decision were made.

The Washington DNR site has a good decision log template including a column for decision rationale and one for the alternatives considered, but even that one lacks the “assumptions” column, and often one of the major causes of learning is that our assumptions were incorrect.

In engineering, the Toyota A3 report acts as a decision log for product design, and is a simple and visual way to keep track of engineering decisions, recording

  • The problem
  • the details of the current situation
  • root cause analysis
  • the “target state” 
  • the alternative countermeasures to address root causes
  • the chosen implementation plan with accountable actions and costs
  •  a follow-up plan, including preparation of a follow-up report 

These reports are used to communicate decisions in review meetings to build a knowledge base about good practices in product development, and to develop a final Basis of Design document.

If a decision log is to be useful as a learning tool, then it needs to cover some of the same ground as the A3 report, and to record.

  • The problem that needed to be addressed (in therms of the difference between the current reality and the desired state)
  • An analysis of the problem
  • The alternative options that were rejected
  • The decision that was made
  • Why that decision was made, i.e. the deciding factors that resulted in choosing that particular option
  • The assumptions behind the decision.

So on a crucial project, consider the use of a decision log, but make sure you record the assumptions and rationale behind each of those decisions.

View Original Source ( Here.

How KM helped England learn from history and beat Colombia

Sometimes learning from personal failure is the way to win.

Gareth Southgate in despain after missing the penalty in 1996,
an event which indirectly led to Englands win last night.

Last night England beat Colombia in the Football World Cup quarter final. The game was decided on a penalty shoot-out – a process which England are historically notoriously bad at, during which players take it in turns to shoot for goal, competing one-on-one with the goal-keeper. After the match, the manager Gareth Southgate talked about the importance of the players “owning the process” of taking penalties as -part of the reason for success.

The story of developing that process, and player ownership in the process, has a lot of Knowledge Management in it, including learning from mistakes, analysis of the situation, and plenty of preparation and practice.

Southgate has his own personal and painful history with penalty taking, as a young player missing a crucial penalty for England against Germany in the semi-final of Euro 1996. His feelings were described in this article from the Daily Telegraph.

“I wanted (the penalty) to be firmly struck, but didn’t want to hit it too hard and risk putting it over the bar or wide. In trying to be precise, I hit a soft and badly placed penalty. Kopke saved comfortably. ‘What have I done?’ I put my arms over my head. The thought of the lads on the halfway line made me despair.”

After the 1996 match, the then Prime Minister of the UK, John Major, offered Southgate a consoling hug, but the failure that day made Southgate determined to learn to do better.

At the time, there was no “process” for penalty taking, but Southgate wanted to learn the lessons from the past, and 22 years later as England Manager he wanted there to be a process, and for the players to “own it.” An article in the Guardian quotes him as saying “The depth of knowledge and understanding wasn’t so great (in 1996) and we didn’t have as much information as we do now …. I have had a couple of decades thinking it through”

So Soutgate has taken the following learning approach for his team:

  • He started his team practising for penalties in March, well before the World CUp started
  • He commissioned a study into the failed penalty shoot-outs of previous tournaments where it was discovered that England players took less time over their kicks than any other nation. “They will take their time now”.
  • He has tried new ways of putting the players under pressure by organising competitions in which they jeer and shout at each other, just as the Colombian fans jeered and shouted last night.
  • He has a list of his squad’s penalty-takers in order from 1 to 23, constantly updated with training performance and injury.
  • Collectively, with the team, he has discussed how they would ideally approach a penalty shootout, “making sure there’s a calmness, that we own the process and it’s not decisions made on the spur of the moment. We have to make sure it’s calm, that the right people are on the pitch and it doesn’t become too many voices in the players’ heads”.
The result of this learning was clear to see last night – a cool calm and collected process which won England the match.

View Original Source ( Here.