I have been recently been working through a database of over 1,300 Lessons Learned obtained through Freedom of Information requests from eight governmental bodies in the UK.
Although all public sector, the projects included range from agile software development, administrative projects, to oil and gas, and nuclear.
My reason for doing this was to try and perform some sort of analysis of the issues facing project management today and deduce what people felt should be done about these issues.
Unfortunately, any meaningful structured analysis was impossible because the lessons learned were so inconsistently and poorly written. So perhaps the first lesson to be learned is that we need to be much better at documenting lessons learned.
Here’s a couple of short examples of the most common problem:
- “Involve business stakeholders from the start in all design meetings”
- “Proper analysis before scoping project solution”
From a lessons learned point of view, what do these mean? They are statements that could be drawn from the most basic of project management courses. Are they saying “We did these things and they worked really well” or “We didn’t do them and suffered the consequences”?
If it is the former, then we could fill our lessons log with all the common sense approaches that are contained in guidance like the Praxis Framework. If it is the latter, why weren’t they done and what were the consequences?
Just to reinforce this problem, here’s a longer example from a different organisation:
- “The Business Case should be as robust as possible, formally signed off by the SRO [sponsor], and describe the key performance indicators as well as the risks and impact of delivery.”
Well, there’s a surprise. And here’s a classic:
- “Clearly identify priority and reason for project (It changes depending on who you ask)”
Who’d have thought?
There are a few examples that demonstrate some useful information:
- “The expectations of external stakeholders regarding desirable delivery timescales, e.g. for draft guidance, differ from current programme planning assumptions and the communications plan should ensure clarity of expectation among external stakeholders.”
That’s a clear issue, and the proposed solution?
- “An appropriate project management tool is particularly valuable for managing tight timeframes and resource constraints. This will additionally enable evaluation of planning options, undertaking 'what if' scenarios and assisting in explaining the consequences of selecting a specific planning option.”
Such issue/solution pairs are in a small minority in this sample of 1,300 lessons. So, what can we learn from this? Firstly, as I said earlier, we need to be better at writing our lessons learned. Secondly, it is noticeable that so many lessons address the basics of project management. Reading the hot topics on LinkedIn you may think that the big issues are things like complexity, innovation or agility but, according to this sample, they are not. Project managers are struggling to apply the simple techniques that are taught on the most basic of project management courses never mind progressing to the latest thought-leader video delivered from the front seat of a car.
In the second part of this blog, next week, I’ll look at some practical approaches to solving these problems.
Adrian Dooley, Lead Author of the Praxis Framework
