I’d bet that everyone reading this article will have taken part in some kind of “lessons learned” meeting or brainstorm at some time in their career. These sessions are often part of a retrospective or post-project review, and are aimed at ensuring that organisations and project teams consider what went well – and also what went badly. The idea is simple: these lessons and pointers can be taken into account in future projects, iterations or phases. This should ensure that future activities run as smoothly as possible.
However, it doesn’t always seem to work this way. I was speaking with a contact of mine just the other day, who observed that in some organisations, the “Lessons Learned” process should really be called “Lessons Documented”. He implied (only half-jokingly) that in some companies, learning points get written down but then fester in a document that isn’t ever read again. The document might be loaded into a repository somewhere, but even if somebody wanted to read it, after six months everyone has probably forgotten where it is stored and what it contains. The whole process becomes about ticking boxes on a plan rather than driving genuine insight and change.
This observation really resonated with me, and I felt he’d hit the nail on the head. If we’re honest we’ve probably all seen this pattern occur. When running projects, there is the opportunity to capture valuable insight and data – everything from data about the amount of effort spent right through to insight about the issues that occurred and the problems that could have been avoided. The challenge is that by the time the project is finished, everyone is tired and ready to move onto the next big thing. Sadly, this might mean that rich insight is lost.
An example: Estimation
Take the thorny issue of estimation as an example. When beginning a project, how do you estimate the amount of effort that will be required? Often, teams use a form of expert judgement – the likely work is assessed, we speak with other colleagues and we reflect on our own experience. We might use a form of Delphi estimation, particularly if we’re using planning poker. Alternatively, we might decompose the work into smaller tasks and estimate every one individually.
These are just three possible ways of estimating, although I suspect they are amongst the most frequently used. Few of them take into account the past experiences of the organisation. Planning poker will, of course, take into account the past experience of the project team; and the estimates should get more accurate as time progresses. Yet, there may be wider experience and data outside of the immediate team that could be useful. Clearly, having access to data relating to how previous tasks were estimated, plus how long they really took (and the problems that occurred!) could prove extremely helpful. Of course, whilst historic data of this type will be useful, any previous estimates will need to be considered and adjusted for the particular scenario being progressed.
A key to enabling this type of insight is ensuring that the data is collected in the first place, as well as being collated and stored throughout the project, ideally with a minimum of effort to each team member. Over time, a rich store of historic and validated experience will be collected. There are many software tools out there that can help with this – but in many ways the key shift is to ensure that the data is collected somewhere (in any format) and that it is accessible in an appropriate format to those that need it, when they need it. If acted upon, this insight should help drive smoother projects.
Conclusion
In conclusion, organisations of all sizes are likely to yield benefits by capturing data about their projects as well as their business. Small and midsized companies can get ahead of the curve by adopting this ethos early. It’s important that this insight is available to those that need it, and organisations with analytic and business analysis capabilities will have a head-start. Embracing the lessons learned process (and avoiding the temptation to see it as a ‘tick box exercise’) is key.
How do you ensure that project related data and insight is considered in your organisation? Do you have a related story or comment? I’d love to hear from you. Please feel free to add a comment below.
If you’ve enjoyed this article don’t forget to subscribe.
This post was brought to you by IBM for Midsize Business and opinions are my own. To read more on this topic, visit IBM’s Midsize Insider. Dedicated to providing businesses with expertise, solutions and tools that are specific to small and midsized companies, the Midsize Business program provides businesses with the materials and knowledge they need to become engines of a smarter planet.
So right you are!! Documenting the ‘Lessons learned’ and aligning it with an organization’s knowledge base is important but equally important is to be able to apply the knowledge in ‘Real projects’.
A project manager holds the responsibility to make both of them happen by conducting proper review of a business case of any project and using the historical assets.