- Event takes place – an experience, idea, incident or accident
- Packaging – write-up of lessons
- Review for accuracy – editing and improvement by person who identified the lesson
- Validation – quality check, ownership assigned and upload into a management system
- Review for accountability – periodic checks on progress
- Implement recommendations – to avoid/ensure recurrence of bad/good alike
- Review for effectiveness – observe changes to ensure they have had desired effect
- Closure – lesson status updated but retained in system for reference and to aid analysis
- Assurance – as part of risk management, periodic review to ensure closed status remains justified
Last time we looked at the second step – the processes used to capture lessons. Now we’ll look at how lessons are written up.
As already discussed, when capturing lessons from people in workshops and interviews, they will often be elicited using the following format:
- What was expected or meant to happen?
- What actually happened?
- How does what happened differ from what was expected?
- What were the root causes or contributory factors?
- What can we learn? This learning comes in two forms:
- What should we do next time round, when faced with this issue?
- What changes should the host organisation make to prevent or ensure recurrence?
- What impact did this issue have? How much money/time did it cost or save us?
However, regardless of whether this format was used during the capture phase, any material gained now needs to be written into this structure or an equivalent one. This will take time as well as trial and error.
Enough detail but no more
Lessons capture will often produce more material than you need and writing up lessons requires striking a balance between comprehension and brevity. Often, an issue will manifest itself in numerous ways but merely repetition of each adds little; instead, you should choose two or three examples that show sufficiently different ways in which the issue affected performance, for good or bad.
Clarity, clarity, clarity
As already mentioned in the last post, an over-riding principle of writing up lessons should be clarity for the end-user – namely, the people with the ability to change things, budgets, processes etc. For their benefit, explain any acronyms and avoid any project/team/activity-specific jargon.
Value-added, not verbatim
Slavishly reproducing what was said in the interview or workshop is pointless, not least because none of us is as clear, concise or comprehendible as we would like and our musings can all benefit from ruthless editing. Additionally, the logical flow of a lesson can be enhanced if our thoughts can be re-ordered by someone who sees what we were trying to say, if we’d had the time, training etc.
Boldness not bullshit
Whilst writing up lessons, you might spot a deduction that was all but stated but got missed; or you might think up a recommendation that was not raised in the room but might well solve everything. If in doubt, include it. Where judgement is required, be more forceful rather than less and produce a hard-hitting lesson that tells it how it is – it can always be amended in the next step, where we get the lessons reviewed for accuracy by those that identified them.