Mistakes matter: post-project reviews
Posted by ElizabethWhether you call it post-project review, lessons learned, post-implementation evaluation or any other term, looking at what went wrong on a project and working out how to do things differently next time is a key way to improve project success.
Most project managers accept the need to do lessons learned activity. Some even do it. But the sessions are normally at the end of a project when the team is itching to get on to new things. You won’t all be working together again for the foreseeable future so it isn’t really relevant to understand why Sonia made that decision or what Frank would do next time to avoid that error.
These are the main problems project managers encounter with running this type of end-of-project review meeting:
- People feel unable to express their true interpretations of the project
- People are unwilling to contribute if their manager is there as they don’t want to appear negative
- People mix up the person and the act and feedback gets very picky and personal
- People don’t care about what happened: they are focused on the future
- Everyone says the project went like a dream and there is nothing constructive raised about areas to improve
- The area that cannot make it to the meeting is targeted and all the failings are blamed on them.
All these issues are to do with human interaction, which is a major skill for all project managers. A skilled facilitator will be able to head off these issues during (or even before) the meeting. For more on managing the people stuff and the soft skills of project management, have a look at Anthony Mersino’s blog, EQ4PM.
Let’s say that you can handle the people side of things and are interested in the output. At best, this type of ‘what went well, what we could improve’ or ‘pluses and deltas’ meeting only helps the people in the room. The lessons rarely get cascaded on to other projects so while each individual might benefit, the way that organisation runs projects will not whole-heartedly improve.
One way to counteract this is to schedule lessons learned sessions more regularly through the project. Make it part of each gate review, or part of the closure before you move to a new phase. Or schedule sessions at significant moments in the year like the end of your financial year or just before things slow down for summer. Making reviews more regular enhances the likelihood that the lessons will be learned and implemented. A policy of continuous process improvement will also get your team used to the idea that changing the way things are done is part of the project process.
Part of your role as a project manager should also be to improve the quality of the projects that your company does: it’s good professional practice to feedback to the other project managers any key points that you have learned that you think they could benefit from. There are various ways to do this: your regular project managers team meeting, via the PMO or informally through an email to everyone. Some organisations have a lessons learned database and this could also be a mechanism to share stories if one is available to you. There are also other online tools like The Mistake Bank, but be careful not to post anything confidential to your company on an external website, even if you think it will help other project managers.
Next week I’ll be looking at how to make changes stick once they have been identified as part of the lessons learned process.
Related posts:
12 Comments to “Mistakes matter: post-project reviews”
Post comment
Srinivas Iyer says:
Great Tips buddy.. I work for a Project Management firm and we follow quite a few things you have written there. I agree that project management is a continual improvement process and new insights just keep coming all the time and there’s always something better that turn up next time. I am even thinking of recommending a mistake management process in our PM solution ‘Deskaway.com’.
Nick Milton says:
It’s equally important to learn from when things go right! You can learn from solutions as well as mistakes.
Successes matter too, where learning is involved.
Elizabeth says:
@Nick: Absolutely! It’s really important to learn from successes so that good practice can be repeated again.
Making lessons learned stick | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:
[...] Last week I looked at some of the issues with running lessons learned or post-implementation reviews and recommended that these sessions are not left to the end of the project. [...]
Links for May 17 2009 | Eric D. Brown - Technology, Strategy, People & Projects says:
[...] Mistakes matter: post-project reviews by Elizabeth Harrin on Project Management Tips [...]
Looking back: Post Project Reviews « Releasing Software says:
[...] Mistakes matter: post-project reviews [...]
John Caddell says:
Hi, Elizabeth,
Thank you for your mention of the Mistake Bank and sorry I didn’t notice it till now!
I’d like to comment on the observation that successes matter too, and we should keep record of good practices for future use.
I agree with that sentiment, but I believe that use of best practice in project management is limited. Most projects I’ve been involved with (software development, systems implementation) are complex in nature–that is, they have so many moving parts, human, technological and otherwise, that each is unique. In these environments, there’s a school of thought that avoiding mistakes may be more useful than trying to emulate best practice.
This has roots, according to proponents, in our evolution. Our ancestors learned by trial and error, and shared stories to convey those learnings: “One time a guy walked close by the sabertoothed tiger and got eaten; best to keep your distance.”
Another trap with “best practice” is that it makes us feel good to remember the positive things that happened, and as a result we can avert our eyes from what went wrong. We then make the same mistakes over and over again (have you ever seen that happen?).
Because mistake learning is so useful, and because it’s become so unnatural to us (who want and expect 100% success, especially when we have a project plan that says so!), posts like yours are very important to help change people’s thinking.
regards, John
Nick Milton says:
I tend to work with engineering and oil drilling projects rather than software, so maybe the context is not the same, but many people say “we cannot learn because every project is different” and this does not stand up to scrutiny. Every project involves applying the same principles (good scoping, broad optioneering, rigorous risk management, contracting strategy, procurement, relationship management etc etc) to a different context, and we can perfect the principles. After all – if every project were different, then you could not learn from mistakes either, as every mistake would be different. However we commonly see the same mistakes repeated – insufficient planning, poor scoping, poor definition of requirements, scope creep. What we need is successful ways to deal with these.
Lets look at your sabretooth analogy. Eventually, someone said “if you wave a burning branch at the sabretooth, they back off”. Surely that’s where the great leap forward came?
Learning from trial and error teaches you to avoid error. Learning from trial and success teaches you to succeed.
John Caddell says:
Nick, thanks for weighing in. You make an important point that not all types of projects are the same. Many significant projects, such as those you mention, share significant good practices and using those good practices is crucial (even life-saving).
At the same time, you mention that even in these projects there are areas where mistakes are made again and again. I’d contend that these are the “complex” bits of the project–the ones where humans insert themselves the most and where there human interactions are most unpredictable. Requirements gathering is one you point out. These human errors are not ones that best practice can deal with very well.
One method of improving and learning in the complex context is to gather stories, look for patterns, and make changes based on what the patterns reveal. These can be mistake stories or success stories (or just “this happened and then this happened” stories). Systematically gathering the stories at the end of each project, making sense of them, then applying those lessons to the next project, over and over again, can help work through even those stubborn repeated mistakes.
I’m talking to an organization about doing precisely this with their project management function as part of an overall improvement program. If anyone is interested in learning more about the approach, you can email me at john@caddellinsightgroup.com.
Elizabeth says:
This is a really interesting discussion. From my perspective though it’s not about learning from successes or mistakes (aren’t they just two sides of the same coin?) but making sure that these lessons are passed on. If you do something well, or if you make or avoid a mistake, you learn from that, but no one else will unless you tell them. The method for passing on these messages is often lacking in project-based organisations. Besides, lessons are always more powerful (and thus more learned) if they happen to you. Someone didn’t listen to the sabretooth warning or they would never have approached with that burning branch…
John Caddell says:
Elizabeth, great points. One way of passing on messages is creating a “story bank” where stories of past projects are maintained and made available and discussed. This is one of the ideas behind the Mistake Bank. A friend of mine, Cynthia Kurtz, is developing an open source project called Rakontu to allow groups to create and maintain their own story banks.
I’d love to see every PM group have a story bank that is constantly referenced, updated and discussed to inculcate these lessons learned.
If you want to learn any more about Cynthia’s project, you should check out http://www.rakontu.org/
regards, John
Customers Are Talking » Blog Archive » The Mistake Bank’s Groundswell Awards Nomination says:
[...] Delta Knowledge Les Idées qui Parlent (French) Juybar (Arabic) Scott Berkun Lasagna & Chips Project Management Tips Knowledgeer-at-Large Engineers Without Fears ?????????? ????????? Bob Sutton [...]