Recently I was asked with a colleague to perform a root cause analysis of a large transformation programme. The expectation of the customer was not to perform an assessment of the programme against a best-practice model but really to find the root causes of why the programme was not performing as expected. The customer expected a cause and effect analysis.

We decided to analyse the programme from different angles: look at the programme management practices, project management practices, change management, 3rd party management, organization, learning and skills. We delivered a fine result (if I may say so myself) that gave the customer the insight that was needed.

Still, the exercise got me thinking. The typical tool for a root cause is a ishikawa diagram. Causes in the diagram are often categorized. In manufacturing, for example, the 6M categories are often used: Machine, Method, Material, Man Power/Mind Power, Measurement, Milieu/Mother Nature; or the 7P’s: Product, Price, Place, Promotion, People/personnel, Process, Physical Evidence.

In doing the root cause analysis of the programme, we had a hard time because we didn’t have a set of categories to work from. Since then I developed a little framework that can help to perform the root cause analysis of a programme or project. It is heavily inspired on Lean Product Development.

In its current stadium it is based on 4L’s: Lead times, Loopbacks, Learning and Leadership.

Lead times refer to the long start-up times that many programmes suffer from. Long start-up times are a root cause for project overrun. Much of the overrun of a project is incurred at the beginning. Causes in this area include: overly detailed analysis, lack of availability of experts, long decision cycles.

Loopbacks refer to points later in the project where there is a failure because of an unchecked assumption in the start of the project. Typical loopbacks include integration problems, building the wrong solution, de-scoping late in the project. Loopbacks are also a root cause of project failure.

Learning refers to the obstacles that the project encounters due to a lack of opportunity for learning and taking lessons learned into account in the project. It includes lack of cross project learning (solving the same problems in multiple projects), hand-overs, not taking into account the lessons learned of previous projects.

Leadership refers to … well, leadership. It includes a lack of balance in the decision making (e.g. scope, scope, scope in the beginning of the project, time, time, time near the end of the project when the deadline is coming close), not managing issues to closure, disconnect between authority and knowledge to make decisions.

As you notice I have left some room for a couple of extra categories. Things that have popped up as extra categories: respect (respect for diversity) and load (evenness of workload).

Since I started using the above 4l template it has proven to be very robust and useful. By publishing the framework I hope to gather your feedback. So, if you use it, drop a little comment and tell us about your experience.

People and Skills is definitely a category which is missing. How often have we seen that people are assigned to take on a challenging job without a proper understanding and match of the profile requirements nor with any corrective or supportive actions in place to help the person to quickly close the skills gap.

Somehow the different categories of root causes are linked to the idea of creating flow (or lack of flow) in the programme. Although this is not made explicit, I like to keep that idea behind it.
Now for people and skills … can this be linked to “flow”? Maybe in the Mihály Csíkszentmihályi way (http://en.wikipedia.org/wiki/Flow_(psychology))?