What makes a “Good” lesson learned?

How to write a good lesson learned

Following on from a couple of talks I have given recently on why organisations don’t learn as much as they could from running projects, I was asked how to write a “good” Lesson Learned.

This was captured well in one of the responses to my survey

“Many ‘lessons learned’ are merely observations, with no suggestion on how to do things differently. Two or three actionable recommendations are more useful than 20 observations without any suggestions.”

To write a “good” Lesson Learned:

  • The PM should craft a story describing what happened. This could be written, delivered as a presentation, in a face to face conversation, or recorded as a video. The thing to remember is don’t polish it too much and murder the message by suffocating it in layers of “corporatese”; make it Personal, Powerful and Passionate to keep it engaging. Your story should be in STARR format, covering:
    1. Situation: This is what we were faced with (constraints, risk, issue, etc.)
    2. Target: This is the outcome we wanted to achieve
    3. Action: This is what we did
    4. Result: These were the consequences of our actions (nothing new so far I know, but here it comes…)
    5. Recommendation: (the “moral” of the story) So in order to achieve better outcomes in the future, this is how we recommend that people (including us) should behave differently, or how we should change process (rules, systems, etc.) to improve future outcomes (i.e. things to do / not do; IF this situation applies THEN do this, etc.). This is the “so what?” that changes the Lesson from being interesting story to an actionable piece of advice based on real life experience.
    6. …and lastly the PM should include details of how they can be contacted to have a conversation in case they’ve left the organisation by the time the lesson is being watched / read.
  • At the “next level up”, the PMO should consider whether there is more learning that could be extracted  from the lesson, and whether the learning could be transferred to similar projects / scenarios. If so, they could write a more generalised version of the lesson.

What about storage?

I was then asked this follow-up question:

Is this the same lesson you'd store centrally?

I would say that both the original and the “next level up” versions of the Lesson could and should be stored centrally, but the word “store” brings up images of a musty room containing miles of shelves of dusty folders that never get touched again, a bit like this…

Does your Lessons Learned repository function like this?
Does your Lessons Learned repository function like this?

The key here is that the central repository shouldn’t be an information graveyard, where Lessons go to Die.

Instead the repository should be made searchable and social (e.g. using SharePoint?) so that PMs can easily find the Lessons they need; and the PMO should be on hand to help them find relevant information if they need it (for more on this look at this excellent article by Louise Worsley).

And filing shouldn’t be the only thing that happens to Lessons, as that by itself doesn’t ensure they are acted on.

More than just filing

Lesson(s) could and should be used as material for Lunch & Learn or “scar sharing” sessions, or Vlogs, or used in the “Call 3” approach devised by John McIntyre (take a look at this article for more explanation and an example Lessons Learned Vlog).

All of this helps an organisation and the people within it to learn from their collective  experience of running projects and to (hopefully!) deliver better project outcomes in the future.

So that’s what I think. Do you agree? Do you have something to add?

Let me know in the comments!

Image “Wimborne Minster: later books in the chained library” © Copyright Chris Downer and licensed for reuse under this Creative Commons Licence

Lessons Learned: Specific or Universal?

lessons-learnt

At a recent PMO FlashMob event, I got chatting with a few FlashMobbers about what can be done with the Lessons identified in project closure reports. There were split opinions in the group:

  • Some thought that Lessons are usually specific to the Project concerned, and are only useful in later stages of the same project, or in running future projects that are very similar to the one from which the Lessons were learned;
  • Others (including me) thought that it is possible to extract more generic learning from at least some Lessons that can be implemented across many projects (even those that are different from the project that identified the Lesson), perhaps by adding or making a small change to a checklist, template, approach, BAU process or corporate PM methodology, or by including the Lesson in PM training or coaching.

I have written before about Lessons Learned and my ideas on how to use them, but I thought it might be fun to try an experiment, with which I would be grateful for your help.

I have written a web survey containing a number of Lessons learned from projects (some very loosely based on my own experience, and some completely made up) – please take a look at them, and for each one let me know:

  • Whether you think it is possible is to draw any learning from the Lesson that can be applied to projects beyond the same type as the original project, and if so
  • What learning you would take from that Lesson and how you would apply it.

On completing the survey (which should only take you about 5-10 minutes) you will see a summary of all the coded responses so far (the survey doesn’t allow respondents to see the free text responses). I will also give you the password to a follow-up article outlining my own thoughts on the examples, which I will update periodically with the best quality outputs from the survey.

So why not make yourself a cup of tea, take the survey and find out how closely your approach to applying Learning from Lessons compares to that of others in the PMO Community?

Processes are an organisation’s memory

Further to my post on Lessons Learned from project delivery, I’m going to take a calculated risk by standing up for the pragmatic application of process. Yes, that’s right, process.

Processes are an organisations memory

Now, people seem to enjoy a bit of process-bashing, and I get that: nobody wants to have their working lives organised for them to the point where they become a soul-less, heartless, brainless robot, but I am proposing the idea that processes are an organisation’s memory.

Let me illustrate this with a well-known story – the Fable of the Five Monkeys. If you don’t know this story, Eddie Obeng tells it beautifully in this very short (2½ minutes!) video.

Here is the story in a nutshell:

  • Five monkeys were kept in a cage with some bananas at the top of a ladder. Whenever one of the monkeys climbed the ladder to get a banana, all the monkeys were hosed down with cold water. Soon, the monkeys began to beat each other up to stop any other monkeys from climbing the ladder and getting them all hosed.
  • Eventually, the threat of cold water was removed, but the monkeys didn’t realise that and still stopped each other from getting bananas anyway.
  • Then, one monkey was replaced with a new monkey. This monkey didn’t know about the cold water, so when he tried to get a banana, the other monkeys beat him up to stop him.
  • One by one all the monkeys in the group were replaced, and all of them would stop each other from trying to get the bananas, even though none of the original monkeys were there, none of them had been sprayed with water and in any case the cold water had been turned off.
  • Effectively a culture had been created within which you get beaten up if you try to get a banana, but none of the monkeys understood why.

The meaning of this story is that to begin with, an organisation adopts a particular course of action – let’s call it The Process (e.g. ignoring the tempting bananas) for Sensible and Compelling Reasons – the result of lessons learned from a project perhaps (if you go for the bananas, you get hosed).

The organisation encourages everyone to use The Process (and beats them up if they don’t). However after a while, people change and no-one remembers what the Sensible Reasons for implementing The Process were, and all you have left is a secondary, cultural reason – because “we have always done it that way” (if we don’t use The Process, we get beaten up).

This situation has the following possible outcomes, each with their pros and cons:

  • The organisation carries on using The Process because “we have always done it that way”.
    • Pro – It may still be perfectly sensible to use The Process because the original Reasons for implementing it still apply (the person with the hose is still there, or the bananas were always poisonous). However,
    • Con – It may no longer be sensible to use The Process because the Reasons for creating it have disappeared (the hose person has gone). Using The Process may be at best inefficient, or at worst,dangerous (ignoring the handy supply of bananas may lead to starvation).
  • Someone new to the organisation cannot understand why The Process is being used, and implements The New Process, which they think is far more sensible.
    • Pro – It may be perfectly sensible to implement The New Process if the Reason for The Original Process is no longer applicable (the hose person has gone), or The New Process by pure luck addresses the original Reason. However…
    • Con – If the Reason still applies and The New Process doesn’t address it, then the organisation is in for trouble (we’re all going to get hosed!)

So, it seems to me that there is nothing wrong with having a process embedded into organisational culture so it becomes “the way we do things round here”, provided that the people that use the process know why that process exists, and the process is reviewed periodically to ensure that it is still appropriate.

Under this approach, the monkeys in the story would know that they must not touch the bananas or they will all get hosed. They would periodically review the approach to ascertain whether the Reason for The Process is still applicable (the hose person is still there), and to change the approach if the circumstances have changed.

By now, you are probably wondering how this applies to Project Management.

Whilst it may or may not be appropriate for an organisation to codify the management of an entire project as a process (there are many popular books and courses on the market that have done that already), I think there is a case for an organisation to document and manage any special ways they have developedof doing certain project stages (Start-up, Initiation, Execution, Closure, etc.) and often-repeated aspects of project management (e.g. Risk Management, Procurement, etc.) as processes, with a documented purpose, objective, and review schedule.

That way, someone (the PMO?) is responsible for looking after, say, the risk management process, and is periodically reviewing it with a view to improving it in the light of Lessons Learned by the organisation.

An approach I have used in a Portfolio Office role to embed lessons learned with some degree of success is to pre-populate the organisational Risk Register template with issues that have cropped up in previous projects, scored initially with a medium to high probability – this prompts the Project Manager to actively assess that risk in relation to their own project, and reduce the risk likelihood or impact if it is felt that it is either not relevant, or that the risk has been mitigated.

This approach makes it easy for the Project Manager to draw on previous organisational lessons (making it very clear why they might want to do things in the recommended way), and also puts the control and responsibility in the hands of the Project Manager, who can use their own (and the team’s) experience to judge whether a particular pre-loaded risk is relevant for the project in hand.

How does your project organisation ensure that people know why they do things, and that the organisational project management approach (or process, or methodology) stays up to date and relevant? Let me know in the comments.

How to make sure that Lessons Learned stay that way

I often wonder just how much project management organisations really learn from project successes and mistakes. I think we could all definitely learn better than we currently do.

How to make sure lessons learned stay that way

I will start by saying that we should not wait until the end of the project to learn lessons (both good and bad) – these will be happening all the way throughout the project and should be logged as they happen. Completion of a Stage (including the final one at the end of the project) present a convenient time to review lessons and take action (including communicating the lessons to the wider project community), but waiting until the end of the project to even identify the lessons represents a missed opportunity for continuous improvement. Having said that, the end of the project is where projects usually consider lessons learned (if they do this at all), in the form of a post-implementation review.

In my portfolio management office (PfMO) experience I have seen post-implementation reviews come up with the same lessons again and again (e.g. build contingency into plans; take more time and care to gather requirements; don’t Go Live without full sign off / back-out plans / user training, etc.), but I have seen even more examples where post-implementation reviews weren’t carried out at all because: the project was too small / too simple; the project finished too long ago / hasn’t finished yet; I don’t have the time; the project team is now working on something else / has all left the company; nothing happens with Lessons Learned anyway; I don’t think it’s worth the effort (delete as applicable!).

I think the PMO can help with Lessons Learned, and that the problems lie not only with identifying the lessons, but also with what to do with the lessons that have been identified to embed the learning into the organisation’s experience and memory. Here are some ways that the PMO can help, to make sure the Lessons are not only learned but also acted on:

  1. The PMO can add the lessons to the corporate PM methodology.
    Done well, robust PM processes and methodologies form part of an organisation’s corporate memory, and are built making intelligent use of the lessons the organisation has learned from previous projects. They are aimed at preventing the repetition of past mistakes without unnecessarily impeding delivery. But the more you add to the methodology, the more rigid and prescriptive it becomes, and the more likely it is to either be cheerfully ignored or blindly implemented in full (and you can bet it will be ignored on the big risky projects and implemented in full on the little simple ones!). The PMO should also avoid becoming the methodology police.
  2. The PMO could collect the lessons identified in a Big Database
    …but to be useful this relies on someone (PMs? the PMO?) reviewing new projects against all the lessons in the database, and identifying relevant points to note.
  3. The PMO could add the lessons to a checklist
    …but that relies on people (PMs)using the checklist and giving some serious consideration to what the items on the checklist represent (rather than just paying lip service and ticking the box). And there will always be the temptation for PMs to come up with a good reason why a checklist item doesn’t apply to the current project…
  4. The PMO can run Lessons Learned sessions
    where the PM of a completed project presents their Lessons to the rest of the Project Management community (but this relies on an open and honest communications culture, and/or bribing the attendees with cakes), or…
  5. The PMO could pre-load the Risk Register template
    with the risk of repeating mistakes made on previous projects – the mitigation for which would be to review the Lessons Learned Big Database for things to consider (and the PMO could add value by offering this as a service).

I think the last two approaches are the best, because one encourages the development of a learning community (this is the subject of a separate post) and the other places responsibility for reviewing past lessons (or not) with Project Managers, but supports them with a PMO service.

So that’s my approach to making project lessons “stickier”, learned through experience. What do you think? How do you ensure lessons from past projects are not just identified and logged, but learned and applied to new projects? Let me know in the comments.

If you would like to have the benefits of an approach like this but prefer not to have to worry about this sort of techy stuff, why not talk to us about taking care of it all for you on your next big project or programme?