I’ve always thought that one of the best ways of getting a message across is to use reverse psychology, i.e. by accentuating the negatives you can highlight patterns of irrational behaviour. This make us realise that as rational human beings we would never do these things and we then start to think more deeply about the opposite of what we’re being told – which we’re more likely to remember.
If you follow any of the advice in the list below, you will hinder lesson learning.
If you follow all of the advice, you need never learn a lesson again!
1. Learn only from mistakes. Why learn from success? You know you’ll never repeat it! And if you learn only from mistakes, you will associate “Lesson learning” with failure, with error, and with awkward conversations with management, which will be enough to tarnish the concept forever.
2. Don’t schedule lesson capture as part of the work cycle, just react to events in an ad hoc manner. That way you can miss many of the key lessons from projects that delivered as expected. After all, nobody minds if progress reporting or budget management is ad hoc, so why would they mind about lesson learning?
3. If you schedule the lessons capture late enough in a project, the project team will have disbanded and you won’t have to do it at all.
4. If you do have to schedule lesson capture, then don’t use an established process for this, and don’t give people any guidance on how to do it. It’s much more fun if they have to make it up for themselves.
5. For significant projects involving a large number of people, allow no more than half an hour, once a year, for lessons capture. Any more than this would just mean getting into detail.
6. If the five questions of the after action review are OK for learning from a short task, then surely they are OK for learning from a complex multi-million dollar ten-year project as well. Why complicate your learning?
7. If you are holding a lessons-capture meeting for a project, and there is a similar project is starting up soon, then you need to ensure that nobody from the similar project is invited to the meeting. They would get too excited, and so spoil the atmosphere of calm disinterested detachment.
8. Ideally, allow people to identify lessons themselves, rather than discussing them through dialogue or at a meeting. That way you will be sure to stay at the superficial level, and never capture the “deep lessons”.
9. This will definitely be the case if you give them no guidance or template; just a blank sheet of paper to fill in.
10. Don’t involve the whole team in lessons capture. In fact, why involve any of the team? The project manager or team leader can identify the lessons, and that way you can be sure to get a one sided view of things.
11. Avoid the use of a facilitator for lessons capture meetings. They would only end up challenging the team, and asking awkward questions, which would make it very difficult to avoid getting at the truth
12. At the lessons capture meeting, allow random conversation. It’s much more fun to let conversation wander rather than homing in on specific learning points.
13. If you have to interject with questions, ask closed questions in order to get minimal answers.
14. Whatever you do, don’t ask any questions about what should be done in the future. Stick with talking about the past, it’s much safer.
15. Combine your lesson capture processes with personal performance assessment, and assignment of praise and blame. This will really cause people to clam up.
16. Don’t base your lessons capture on solid performance data. Why analyse facts, when it’s much more fun to collect opinions?
17. Don’t relate your learning review to the original objectives and deliverables of the project. It’s much more fun to reinvent history.
18. Root cause analysis is just too difficult and too awkward. Stick with the superficial high level things, and you will get your meeting over with much more quickly.
19. Don’t assign any roles and responsibilities for lessons identification and capture. It’s much better if everybody thinks it somebody else’s job.
20. If you’re collecting lessons from an individual, don’t brief them in advance. Surprise them, it’s much more fun.
21. Also don’t do any preparation yourself, to familiarise yourself with the interviewee; you’ll find out about them during the interview so why bother to brief yourself beforehand.
22. Don’t record the interview. I’m sure you can write fast enough to document everything.
23. And if you have to record, don’t have a backup recorder, because those things never fail and batteries never go flat.
24. One sheet of A4 paper should be big enough to write notes a 2 hour interview.
25. Let the interviewee ramble as much as he/she likes; you can catch up on some sleep.
26. Don’t follow up on the interview by requesting additional material; they may have mentioned some crucial documents but nobody else will want to read them.
27. Evaluations and assessments should never be systematic or objective, but constructed from ad hoc opinion. I mean, who’s going to take any notice of them anyway?
28. Once you’ve collected the evaluation data, feel free to make value judgments, but avoid learning points at all costs. If the team learns enough from your evaluation to be successful, they may never need evaluations in future and you will be out of a job.
29. Don’t separate out unique single lessons; combine all your lessons from one project into a single document. That will make it really hard for people to find them in future.
30. Document your lessons at the back of individual project reports. That way people can’t find them without reading the reports from every single project.
31. And if you can hide them on the library shelf, even better.
32. Make your lessons as generic as possible. Aim For motherhood statements. Everybody loves these – they sound so wise, but teach you so little.
33. Use fuzzy phrases like “do it better” or “do it earlier” rather than actually giving specific advice. The reader of the lesson will be thoroughly confused.
34. Don’t give lessons any consistent structure, it makes them too easy to follow.
35. Lessons should be supplied devoid of context, making it an exciting intellectual exercise for the reader to see whether it’s applicable to him or her.
36. Unless, of course, it is a very simple lesson that can be explained in a diagram a photograph, or a few lines of text. In this case, you may want to write a 50-page article.
37. In fact the best way to record lessons is as bullet point phrases. Aim for three words or less. A lesson such as “Improved contracting process” is so terse and economical, it’s almost like a haiku or a Zen koan. Something to meditate on.
38. Alternatively, instead of lessons, why not just write a little history of what happened with no moral, no conclusion, and no learning points? Leave it up to the reader to try to guess what they should do as a result
39. Even better, just tell a pointless story with no message. People will enjoy listening, and go away none the wiser.
40. When writing your lessons, it’s best not to have a particular reader in mind. It may be an engineering lesson, but perhaps an Archbishop or a ballet dancer may want to read it one day, so avoid using engineering language, and avoid explaining it in ways that an engineer can follow.
41. In fact, it’s best to make your lessons as difficult to follow as possible. If people spent all their time learning from your lessons, you would deprive them of the excitement of having to make the mistakes all over again.
42. Don’t write down the originator of the lesson, the date of the event, or the value of the lesson. That would just make it far too easy for people to know which lessons were important and recent, and who to go to for more information.
43. If a picture tells 1000 words, then why not just write 1000 words rather than attaching a picture to your lesson?
44. Never under any circumstances set up a system of quality assurance for identified lessons; this would put the “garbage in garbage out” principle at grave risk.
45. Never assign actions to lessons, it spoils the chance for the organisation to learn the lessons all over again. And again. And again. Actions just lead to change, change leads to improvement, and improvements threaten our comfortable mediocrity.
46. If there are any actions, they should only ever be of one sort; “circulate this lesson for information”. Certainly don’t require anybody to change anything.
47. You can avoid having to change things if you don’t make anybody accountable for the actions.
48. You can postpone change indefinitely if the actions have no closure date.
49. Any actions should be assigned by the most junior person present, especially if they are difficult or contentious actions. This will make them much easier to ignore, and much harder for people to treat them seriously.
50. You can avoid much of the risk of learning if your organization has no process owners for the major processes. If nobody owns any of the processes, then nobody can change them, and they will stay as inefficient as they have always been.
51. If there are process owners, then keep their job description as vague as possible and make sure it includes nothing about updating or improving the processes, as this would give them far too much work to do.
52. Process owners should have no expertise in the topic, should not be members of any community of practice, and should have no technical authority.
53. As a process matures, it’s important to keep the same process owner. It makes sense for completely mature processes to be owned by research and development, seeing as they probably invented them in the first place.
54. If you can disengage the process owner from the lessons learning cycle, then with any luck they will never be notified of the lessons in the first place. Certainly avoid any workflow which might push lessons (and work) their way.
55. See if you can avoid a validation step for lessons. I am sure every suggested change is equally valid, and if you spend enough time on trivia, the important lessons may be lost.
56. Avoid Management of Change procedures as well. Live dangerously – change your processes on a whim, and hang the consequence.
57. All process documents should be given equal weight. See if people can work out for themselves whether they are a mandatory company standard, or somebody’s bright idea.
58. Much fun can be had in choosing how to document a process or best practice. Simple principles like giving the reader all of the detail all at once, with no logical structure, with no context or high level summary, in dense text, with no pictures, audio or video, can create masterpieces of incomprehensibility.
59. Then store your process guides and best practices somewhere that the user will not find them. Give them misleading names, and hide them in an obscure branch of the folder structure on a remote file server. After all, everybody likes a game of hide and seek, especially when they are urgently searching for useful lessons.
60. Don’t date your documents – let people try and guess which is the most recent version.
61. Don’t tell anybody when processes have been updated, this would spoil the surprise.
62. If you have a blog at work, this is a great way of telling people about your holiday, and sharing the latest jokes. It would be far too boring to use it for sharing lessons and process updates.
63. The same is true for newsletters. They should only be used for staff announcements, and pictures from the Christmas party.
64. The training department have got their own budgets and their own staff – let them work out what has changed and what hasn’t. It’s not your job to make sure that training reflects the most recent lessons.
65. It’s best to avoid any review of lessons at the start of a piece of work. Just jump straight in and make it up as you go along. You will need the time later on, for coping with all the repeat mistakes that you will inevitably make.
66. A company lessons database is a complete waste of money. Why spend 10 minutes searching a database at your desk, when you could spend a leisurely 2 hours in the library (and still not find the lessons that you know are there somewhere).
67. If you are forced to invest in a database, then certainly don’t spend any time developing a taxonomy. Just file the lessons any way you want. Filing them by the last letter of the project managers surname is quite an interesting approach.
68. The lessons input form for the database should be just one single text box, to allow the maximum of free form creativity, and to eliminate any opportunities for tiresome sorting and searching.
69. In fact, why not eliminate the functionalities for sorting and searching?
70. And don’t introduce any push functionality, as it would embarrass the process owner to be notified of new lessons.
71. A knowledge library is a very bad idea, making it far too easy for people to find things. In my day we had to search through piles of reports to find everything, why should kids nowadays have it any easier? So no portals please.
72. And no search either, thank you very much.
73. As for wikis, I can see no reason why anybody should be allowed to comment on documents, processes or best practices. You lot out there should be applying the processes, not commenting on them, so just get on with your work.
74. Having completely sabotaged the formal lesson learning system, we really don’t want people to run any risk of identifying lessons informally. Therefore all attempts at setting of communities of practice should be avoided.
75. Any communities to do exist should not be provided with any way of finding each other, of asking questions, of storing knowledge, or of meeting or discussing anything. Give them the bare minimum of tools.
76. The community leader role should be given to the most autocratic technical expert. He or she can be relied upon to rule the community with an iron fist.
77. Choose communities to cover topics which nobody identifies with. Choose topics which people do rarely, and don’t like doing. An Income Tax Return community of practice, for example, will be inactive for most of the year and then spend a
couple of weeks complaining and grumbling together.
78. It’s best if your communities are very small. Big communities are too useful and contain too much knowledge. 20 people should be your upper limit.
79. If you can disempower your community, so much the better. There is no risk in them sharing lessons with each other, if they are not empowered to use the lessons they find.
80. Try and avoid giving your project staff the opportunity to learn from others at the start of their project. Processes such as peer assist give a project an unfair advantage, and should be discouraged.
81. If, by some mistake, a peer assist is scheduled, then make sure its objectives are unclear, that its focus is on criticism and critique, that it is attended only by managers who are senior enough to be scary, and that you have no facilitator.
82. Similarly avoid giving your project staff the opportunity to pass lessons on to subsequent projects. Processes such as baton passing and knowledge handover are also unfair, giving the subsequent projects a much greater chance of succeeding. Why should they be given an advantage? Why shouldn’t they start from a position of ignorance just like the rest of us had to? Failure is good for you.
83. You can clamp down on ad hoc learning by careful design of your surroundings. Give people individual offices, it gives them a great excuse not to interact.
84. Remove any communal areas. People can drink coffee at their desks, with door securely shut.
85. Remove any yellow pages, telephone directories, or any other temptation for people to call others and ask for their lessons.
86. Clampdown on any online conversation or social software. People are not paid to talk to each other, they are paid to sit there and work, so make sure they have no distractions.
87. There is a lot you can do to discourage lesson learning with the help of senior management. They can start by making their expectations for lesson learning very unclear. If nobody is clear what they should be doing, then most of the time they will do nothing.
88. You can set the expectation for lesson-learning too high, or too low. For example, ask a busy project to spend half an hour every day discussing and identifying lessons. Alternatively, require your most major projects to identify lessons only at the end of the project, no matter how many years they take.
89. Even if a senior management have set expectations, they can undermine these by not taking them seriously. Make sure they allow projects to continue without having done required learning, or allow projects to close without having identified their lessons.
90. Ask them to set priorities that over-rule lesson learning. People will soon realise a Retrospect is not valued, if it is consistently postponed to make room for another slide presentation to the chairman’s sister.
91. If senior managers are required to take part in any lesson identification meeting or process, ask them to decline.
92. There should be no clear chains of accountability for learning, neither within the business delivery organisation, nor within the supporting functions. This would just make it too easy for people to know what to do.
93. Never describe your learning system in simple terms. Don’t call it “learning lessons”, call it “quasi-experiential pedagogy”. Call it “knowledge gardening”. Call it “Enterprise 3.5”. Confuse people! They love a good buzzword!
94. If there is a central support team for lesson learning, disband it immediately. If nobody supports learning, they will gradually fade away over time.
95. As well as disbanding the support team, cancel any training for lesson identification and learning. We can’t have people who are actually skilled in the technologies and processes, just in case they manage to sneak a lesson through the system.
96. In fact, don’t have any training or awareness or roll-out for your learning approach. People will finder it harder to get value if they don’t understand the complete learning cycle.
97. Don’t monitor or measure learning activities. If it’s not measured, it can’t be managed, and if people know they are not monitored, they will take short cuts, or avoid learning entirely.
98. Even if you do monitor and measure, then for heaven’s sake don’t link this to any performance management incentives, or to any rewards for recognition. If people know they can avoid lesson-learning activity with no penalty, they spend their time doing other things they are actually rewarded for.
99. Learning metrics need to be kept secret. If senior management saw them, the people who aren’t complying with the learning expectations might get embarrassed.
100. If you want to reward people, then reward them for putting lessons into the lessons database. Pay them for each lesson. That way they will know that lesson learning is not part of normal paid work, but has to be incentivised separately. Also you will swamp the database with poor quality lessons, and when the reward is eventually removed, lessons identification will stop completely.
5. Email is universal, and social networks are not. Nearly everybody on the web (while there are no doubt some exceptions) has an email address. Many places of employment give employees email addresses when they begin working there. Meanwhile, a great deal of them are banning workers from even accessing social networks.