Friday, 17 December 2010

Knowledge, and root cause

Root Cause
I spent Monday and Tuesday this week facilitating a knowledge capture session for a major project - a project that met many hurdles and stumbling blocks, a project that was a first-of-a-kind, that finally proved too ambitious to succeed (for now), and had to be put on ice until the business climate was right.

 It was a fascinating meeting, and we spent hours trying to unravel the root causes behind what happened. Many things went wrong on the project, there were many symptoms of challenge or delay or failure, but there turned out to be only 4 or 5 root causes behind all the symptoms. These root causes were complex and interrelated, but we managed to tease them out in the end.

Reflecting about the experience afterwards, I came to a couple of key conclusions.

  • Firstly, if you don't understand the root cause, you don't have the necessary knowledge to proceed.
  • Secondly, when you present the knowledge, it should be structured by root cause and not by symptom.
Let me explain.

Firstly, the root cause analysis is vital to understand what happened, and without that understanding, you don't know what to do in future to avoid the symptoms recurring. It's like medicine - there are many things that can cause a rash, and if you understand the cause, you can treat it. If you misunderstand the cause - if the rash is caused by an allergy and you are treating it as if it were measles - then you won't clear the rash, because you lack knowledge. Similarly, if you don't understand the causes behind your project delay - if you think it was caused by a lack of rigour in progress-chasing, but in fact it was caused by poor stakeholder alignment - then you wont know how to fix it. You may improve your progress chasing, but the stakeholders remain misaligned. If you don't have knowledge of the root cause, you don't have knowledge of how to improve the situation.  You are just guessing.

When you pass on that knowledge, you are aiming to give subsequent projects knowledge of how to improve their own situation by avoiding the same challenges, delays and failures. You need to give them the ability to take action to improve their own chances of success. You could present the knowledge by symptom ("this is how you avoid project delay") or by root cause ("this is how you improve stakeholder alignment"). My preference is to present it by root cause, really because here you are speaking most directly to the individual who takes the action. Project delay could be caused by many factors and influenced by many people - the people who chase progress, the people who seek to align the stakeholders - and its best to speak to those people directly, so they know what they can do to improve the project chances of success. Knowledge needs to lead to action, and action must address the cause and not the symptom.

So as I have been packing the lessons from this weeks event, I have tried wherever possible to start from the root causes, identify how those can be addressed, and turn those learning points into actionable recommendations for individuals in future projects.

If I can do this well, if I can do this effectively, then I have a chance of making a real difference to future projects, and helping them to avoid being put on ice themselves, and helping them to succeed where others have failed.


  1. Organisation spendings on KM has increased substantially over the years - (as you said in one of your earlier blogs - the remenurations to the experienced lot, indeed its a huge money) - mainly because most of us know that knowledge is a key resource upon which an organisation’s competitiveness depends. Most of the organisations are implementing various KM initiatives to identify, process, share, and exploit their knowledge assets. Many of the KM projects end up - creating a unaccessible/ under-used central repository or a technical library; An inactive communities of practice (Microsites on Intranet); knowledge sharing of best practices, and so on and do claim to have benifitted.

    But studies have proved that more than 80% of the KM Projects makes no significant impact on the organisation - may or may not be correct. People in the field very well know that we are yet to device a universally acceptable KM measuring mechanism.

    If the real causes of a problem are not identified, as you said, they are not knowing what they are upto and the problem will continue to exist. For this reason, identifying the root causes of KM project failure has to be considered as critical to understanding why a project really failed.

    The root causes can be many, viz. Knowledge hoarding; Outdated knowledge; Lack of support from higher-ups; Lack of access; lack of fool-proof KM measuring mechanism; Information security policies of the organisation; HR policies, etc..

  2. You are right Suresh - we need to understand the root causes of KM failure, from the 80% that fail - and we need to understand what was different about the 20% that succeeded. I have a pretty good idea what was different and have addressed that in several blog posts, for example

    However I think this merits a blog post in its own right, and I will work on this over the weekend.

    You can see some examples of failures if you click on the label "failure story" to the right.

  3. Totally agree about root cause analysis Nick. In the past I have found that whilst symptoms may affect individuals, addressing the root cause may not be in their gift or direct control. An example I recall was the late release of experts from one project, delaying another. You have said on many occasions that a lesson is not really learned until it has been reapplied. Will your packaging therefore have to somehow convince those that can address the root cause, but whom may not actually have been impacted by the symptom?

  4. Definitely, Gary. For each lesson there is an action, and often than action needs to be escalated within the organisation. Luckily this organisation has a means for escalating lessons, and a central group whose remit (or part of whose remit) is to review such lessons and ensure the actions are carried out.

  5. What method did you use to get at the root causes? I think the 'five whys' approach has a lot to recommend it (although it does require people to put aside any irritation at repeat questioning):

  6. Luckily this was a pretty reflective and analytical team, so no specific process was n eeded. the 5 why's is a good one, and certainly we used the "why" word a lot, though not to the point of irritation


Blog Archive