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 through administrative 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.
Working through the database of lessons learned from eight organisations taught me two things:
- As a profession we are pretty bad at recording lessons learned in a consistent and usable manner.
- A predominant theme in what is recorded is that people do not consistently apply basic, well-understood project management principles.
We seem to have a situation where people go on courses, learn basic good practice, gain qualifications… and then go back to doing the same old things and making the same old mistakes. As the proverb says, “You can take a horse to water…”.
So, what can we do about it? I think there are two practical actions.
The first very simple one is to adopt a lessons log template. Give people a structure to follow when recording lessons learned. One that encourages them to properly describe the lesson; how it impacts the project or programme and what action should be taken on future projects.
To this end we have created a simple template that can be downloaded here.
Addressing the second is almost as simple. Use checklists to make sure people apply the basic, common-sense project management that they have learned on a course or on the job. I can see the heckles rise from here as soon as I use the ‘C’ word. “Checklists!!!” I hear the cry, “Bureaucracy, Box Ticking, Mindless management”. My simple retort to that is “Well if it’s good enough for pilots and surgeons, it’s good enough for project managers”.
I would strongly recommend the book “The Checklist Manifesto” by Atul Gawande to anyone. It tells the story of how the World Health Organisation used checklists to reduce surgical mortality by 47%. This six-minute video of Atul Gawande’s TED talk on you tube sums it up perfectly https://bit.ly/2qQGexV. I believe this approach could make a big difference in project success rates.
In the Praxis Framework, we provide checklists for many functions such as business case, risk management, benefits management and so on. They’re not complicated, just a list of things you should do in each area. You can go through and ‘agree’ with the things you’ve done and make note of the ones you have yet to do.
This should prevent the kind of lessons learned that I described in part one of this article where people end up recording that they didn’t do the common sense things that should have been second nature. After you’ve used the checklists a few times, these simple acts should become second nature and perhaps you find yourself using the checklists less frequently. It’s called embedding good practice.
But it can be more sophisticated than that. You can get team members, sponsors and stakeholders to go through the same checklist on your project to get a combined view of how things are going (you may think you have adequately communicated with stakeholders but do they feel the same way?).
Because Praxis is fully integrated, the act of working through checklists to improve your personal application of project management also gives you a Capability Maturity score against the CMMI-based Praxis Capability Maturity Model.
Organisations can define projects, programmes and portfolios within the tool and combine completed checklists to maintain a real time dashboard of how Capability Maturity is developing. It’s an approach that combines practical work to embed good practice with visible real time reporting of organisational improvement against a respected standard.
And all of this is completely free. It’s just another example of how the Praxis Framework aims to not only provide easily accessible good practice but also provide the tools to make it effective and embed the principles in your organisation.
There is also a link to another popular theme on social media – ‘The Mindset’.
An increasing number of posts talk about ‘creating’, ‘developing’ or ‘coaching for’ the right mindset. This originated mainly as a mantra from the Agile community “Agile is a Mindset, not a method”.
There are various definitions of mindset but the one I am interested in is “a collection of behaviours”. In this instance, the behaviours that are based on well-established project management good practice which, if applied consistently, can make a real difference to project success.
I am constantly reminded of a quotation from John Katzenbach, the author along with Douglas Smith, of the 1993 book ‘The Wisdom of Teams’ in which they describe the Katzenbach and Smith team development model. He said:
“Start with changing behaviours, not mindsets. It is much easier to ‘act your way into new thinking’ than to ‘think your way into new actions’. Recurring and consistent performance results from behaviour change will lead to lasting changes in the way people feel, think and believe in the long run.”
To me that describes perfectly what Praxis is seeking to achieve with its on-line best practice and associated checklists. Gain the knowledge, apply it systematically until it becomes a habit (or a mindset if you prefer) and finally – make a difference.