- 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.
Format
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.
For more information on lessons, knowledge
management (KM) and organisational
learning, please visit the Knoco website.
No comments:
Post a Comment