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.
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.
Posts
