Lessons are commonly identified when a project ends; they’re embedded and learnt less often.
No project team or business gets everything right during a project. Even successful projects have room for improvement and a responsibility to identify what made them successful for future reuse.
Lessons should be tracked from the outset, just as teams do with risks or issues. The Lessons Log should record observations internal and external to the project so the business can learn too. Throughout a project, the project team should discuss how project management, analysis, communications and change techniques, can be improved to save time, cost and maximise benefits and look to apply those changes iteratively. Observations for business improvements should also be flagged real-time.
r10 offers a new take on the subject of Lessons Management, a 3-step process: Lessons Identified, Embedded and Learnt.
1. Lessons Identified
Initiate introspection when the project kicks off. Project success or otherwise can often be traced to start-up, so don’t wait to critique decisions and actions; “start with the end in mind”.
Specifically, share observations at gates, checkpoints and sprint reviews. Agile methodology uses retrospectives as celebrations of success and opportunities to learn lessons, an exemplar to waterfall projects that typically leave lessons to the end. Like key risks and issues, key lessons could even be included in regular reporting to inform flexes in approach.
At project closure there is often a governance requirement for a lessons learnt document but, in the melee of relief and celebration post-go live, a risk the right people won’t read it. To combat this, ensure the document is not overlong, use an executive summary, use your lessons log and engage the team, stakeholders, sponsor and the business for input. Identifying lessons is not just about what went wrong, include ‘what went well’ positive lessons too.
2. Lessons Embedded
After a project has delivered the team will likely move on. So, who embeds Lessons Identified into tangible improvement?
This should be a central function coordinating PMO, trainers and business leaders. The project Lessons Identified document is the basis for action. If lots of projects within a portfolio are producing Lessons Identified documents, this central function can prioritise high-frequency issues for action. What if there is no central team? At the very least, own your own learning and cascade appropriately but better still, embed the lesson of a lack of central team and look to create one by bringing together key representatives and sharing actions at your own project review session.
Where might the changes be made? Induction and project training may be updated, business processes might change and project governance may alter artefact requirements or make gates more rigorous. An organisation may even change project delivery approach altogether, like moving from Waterfall to Agile. Each action should have a designated owner and be messaged and managed appropriately.
3. Lessons Learnt
This is less of a process than the preceding two stages, more a state to be achieved. It’s the reinforcement part of the change process. Here operations and PMO monitor the adoption of new process to ensure that people are aware, engaged and adopting the change. It’s also an opportunity for self-reflection – have you learnt all the lessons you can from this project and are you applying them in your next one?
This is a continuous cycle; there will be more change to come from the next project and how well an organization learns lessons is surely a lesson to be learnt in itself.
r10’s Project Managers and teams leverage the lessons from multiple projects and clients to ensure your projects are delivered successfully.
Author: Ben Howell