Here at Difrent we are encouraged to provide content on social media, as part of our personal growth goals and objectives.
This enables us as individuals to express our opinions on the work we do and how we learn and develop from our experiences.
So, as my first real adventure into written blogs, I thought where better to start than with a blog about the 8 steps I follow when conducting effective Lessons Learnt sessions.
Having delivered some really successful, and some less successful, services over the last few years I thought I would express my opinions on Lessons Learnt, taking into account the things I have considered from conducting many of these sessions.
Lessons Learnt sessions are something that any Delivery Manager worth their salt will tell you needs to happen.
They will also say it needs to happen regardless of whether the outcome was a success or a failure.
It might be good at this point to say I am not talking about Retrospectives here, although Retrospectives and Lessons Learnt are very similar in terms of the outcomes they need to achieve.
Retrospectives should be happening at the end of every sprint and be focused on the delivery of the product or service.
Lessons Learnt, however, normally happen at the end of a project and should take into account not just the product or service but the entire project's objectives.
When I have conducted Lessons Learnt sessions, I normally plan for them to be 4 hours long (minimum), anything less won’t give time to discuss all elements of the project lifecycle.
I always give the stakeholders involved an agenda of what to expect and what to prepare prior to attending the session. This normally includes the operations team that delivered the project, the Product owner, Finance and procurement representatives.
The objective of the session should be to assess the project as a whole, including the initial procurement process, and it should also look at actions taken throughout the entire project, including the effectiveness of artefacts created (eg RAID logs).
It should also look at additional items discovered during the project, that may or may not have been part of the initial scope.
The session shouldn’t just focus on the negative elements of the project. You need to try and get a balance of the things that went well and the things that didn’t go well.
When I conduct Lessons Learnt sessions, I try to address the following:
1. Assess the goals and objectives/deliverables
* Were the program objectives/deliverables appropriate for the project goals?
* Were the objectives/deliverables met?
2. Identification of activities that needed additional effort
* Were any objectives met/unmet?
* Were any strategies or activities successful/unsuccessful?
* Were some objectives met as a result of successful activities?
* Should these activities be continued, renewed, and strengthened?
* Can these activities be expanded to apply to other audiences or situations?
3. Compare costs and results of different activities
* What were the relative costs (including staff time) and results of different aspects of your project?
* Did some activities appear to work as well as others but cost less?
4. Assess the roles of organisations in the project and the way that these organisations worked together
* Did any conflicts of organisational agendas or operating styles occur?
* How did the timing of the program coordinate with the different organisations involved?
* Was the information cascaded at the required pace?
* Was the information relevant?
5. Assess the planning of the workload
* Was the Daily / Weekly / Monthly workload planned?
* Did the planning meet the milestone deliverables?
* Was the workload achievable?
* Did the plans include all elements of the project, e.g. Service Design, BA, Development & Test
6. Assess the project's ability to adjust and adapt
* Was there conflict when new tasks were assigned?
* Were the tasks assigned to the correct resource?
* Was the workload achievable?
7. Assess the Projects EPICs, Stories and Tasks
* Did the Epics include all of the requirements?
* Were the stories small enough to build into sprints?
* Were the acceptance criteria within the stories detailed enough to develop and test?
8. Assess the people within the team itself
* Did the team work well together?
* Were the right people in the right roles / with the correct skillset?
* Were the deliverables for each stakeholder clear?
For me, all of the above has enabled me and the teams I have worked with, to deliver continuous improvements.
These sessions have always been well received and enabled me to take action. This is the key to the Lessons Learnt sessions, the actions that come out at the end.
The business or individual can then take those actions and adjust how they deliver in the future.
They can continue to do the things that went well, they can stop doing or adjust the things that didn’t go well, and they can start doing the things that are suggested in the sessions, that would have been of value to the project if they had happened.
In conclusion, Lessons Learnt should bring value to the business as a whole, to the processes that the teams operate within and to the individuals and stakeholders involved.
I hope you find some value in this approach for your next project and if you have any thoughts or questions on this approach, please feel free to contact me.
Written by Darren Lynch - Delivery Manager @ Difrent