Project Management

Project postmortems: Learn your lessons when it's all over

Even the most problematic projects can be wonderful learning experiences--if you take the time to learn from your mistakes. Find out how to run postmortem project review meetings efficiently and effectively and turn former failures into valuable lessons.

By Geoff Choo

A couple of days ago, I had lunch with my project manager friend Tom, and we ended up talking about a famous quote by George Santayana in The Life of Reason: "Those who do not remember the past are condemned to repeat it." Learn from your mistakes, we agreed in unison.

"Seems like common sense, doesn't it?" Tom said. "I mean, if we had to reinvent the wheel every time we wanted to drive somewhere, we wouldn't go very far, would we?"

For the past three months, Tom had been leading a large consumer-portal project that didn't end well.

"I guess we committed a fatal sin of trying to achieve too much with emerging and untested technology," he said, "and we didn't sufficiently plan for the eventuality that our dot-com clients would run out of money, forcing the clients to eventually call off the project."

"What happened?" I asked.

"Well, to put it in a nutshell, we underestimated the time and effort it would have taken to work with the particular technology we used. We missed most of the delivery milestones, delivering the project about a month late. That delay was enough to make our clients miss the window for further funding.

“Without the vital infusion of cash, they ran out of money and closed the project down. But I'm also proud of the fact that when the project ended, we didn't just go away to wallow in our tears. We made the effort to have a postmortem meeting to learn from our experiences and to use that knowledge to build a foundation for future successes," Tom remembered with a smile.

A lot of things went wrong on Tom's project, but a lot of other things went well. When the project goes sour, it's natural to have bruised egos, self-doubt, and low levels of self-confidence. It's easy to want to put the bad experience behind you and move on. But it's important to insist on having postmortem meetings so your team members can discuss their experiences candidly and objectively, to review what went wrong and what went right, and to apply the lessons learned to future projects. If you do your postmortem meeting after every single project, you will have more knowledge of your projects—and gain more value out of it.

Here is a guide to getting the most out of postmortem meetings.

What review process do you use at the end of a project?
Do you have a specific method that all departments use or do you let project managers devise their own postmortems? When does senior management get involved? Share your postmortem tips with us.

Do it right after the project has ended
Most project managers recommend having postmortem meetings anywhere from three days to three weeks after the project. In my experience, the right time is just after the project is over. Especially with Internet projects, your teams usually won't have the benefit of taking a break before starting on a new project. This means that you have to get hold of them before they rush off to another project or leave on a well-earned vacation. On large and long projects, you might even consider conducting minipostmortems after each milestone, so you can put into practice what you've learned as soon as possible.

Don't look for scapegoats
Keep the meetings positive and constructive. You're looking to learn from your experiences, not to find someone to blame for project failures. Although you will have to objectively confront the low points of your project, remember that postmortems are meant to be a learning experience to help you do a better job in the future, not an opportunity to trash your colleagues (no matter how tempting it might be).

Compare what you wanted to achieve to what actually happened
Begin the review meetings by refreshing everyone on what you initially envisioned the project to be and how you thought things would turn out. It would be helpful to include your schedule, milestones, budget, and effort estimates. Then compare that with what actually happened on your project. Think of your project in playback mode. When and what were the major highlights?

"The functional requirements were a moving target," Tom continued. "Both the clients and our team had a clear vision of what we wanted to achieve. But we didn't have a clear idea of what we had to build, what functionalities we had to provide, and how we would do it. The clients could only decide what functionality they wanted after having seen our prototypes. And prototyping put an additional strain on the schedule because we were still playing with prototypes when we should have already started working on developing a production version of the application.

"We delivered our deliverables late, and the closer we got to the deadline, the more features we kept leaving out. We ended up with a product that worked but only provided about 40 percent of functionality. The VCs didn't like it, and the rest is history."
Save $50 when you become a gantthead premium member.

To read more from gantthead, join now!
Registration for basic membership is free.

Do you need project plans, deliverable templates, presentations, checklists, or expert advice? TechRepublic members who join gantthead can upgrade to a premium membership for only $300—that's $50 off of the premium subscription. Visit gantthead today to find everything you need for success on your next project.

Where did it go wrong?
What difficulties were encountered? What assumptions proved incorrect? Where were targets missed? Tom's team focused on things that turned out worse than expected, especially unexpected problems that crept up. Mistakes always seem clearer in hindsight.

They committed three fundamental mistakes:
  • Not demanding clearer specifications before beginning work
  • Giving work to developers before specifications were written in stone, hoping to wing it and build things as the project progressed
  • Selling a great concept without the skills and experience to build it

"I'll make sure we won't commit these errors on the next project," Tom said.

Where did it go right?
It’s also important to review the aspects of your project that went well.

"In my project, we had a very smooth communications plan," Tom said. "I knew that my role wasn't to make people work but to enable them to work. This meant asking my people all the right questions and giving them all the right answers and tools to allow them to finish their tasks.

“As a result, I spent a great deal of time communicating the hell out of my e-mail program, making sure that everyone understood what they had to do. But I believed that extra time was well spent, as I'm sure we would have wasted more time if I had kept quiet and hoped that people would gloss over problematic questions or try to wing it.

“We also discovered that ICQ turned out to be a great business collaboration tool—and not just a toy for lonely hearts—for those simple one-liner questions or to collaborate with our external freelancers."

Review your risk plans
Did you take big risks or did you play it safe? Did any unpredicted risks come into the picture? How did you resolve them? Evaluate your risk management experience and pay particular attention to how you would change your approach for the next project.

Tom's team didn't handle the risk so well in the project.

"We took a big chance on cutting-edge technology, and while the concept was good, we made too many assumptions and were overly optimistic about our chances of delivering a finished product on time."

Risk is a two-sided dilemma: You have to show optimism to your clients—that you can do the job better than anyone else—but you also have to be truthfully pessimistic to yourself and recognize that there are sometimes limits to what you can achieve.

Did you manage for change?
Did any unanticipated changes occur during the project? How did you respond to them? Did your project suffer from excessive feature creep?

"We had to draw a very fine line between giving our clients what they wanted and preventing feature creep," Tom said. "Our clients only knew what features they wanted after they had seen it. So existing features mutated often into totally new features because customer focus groups dictated so. It was hard to freeze the feature set, and correspondingly, to manage change requests effectively because we kept arguing over what constituted a change request and what did not."

Review performance of team members
Human resources might object to this, but I believe that mini performance reviews right after a project are the way to go, instead of the usual annual reviews. I recommend keeping these reviews on a private, one-on-one basis. When you have the opportunity to assess and improve performance on a minicyclical basis, you have a better chance of making change where it is most effective, right after the project is over, when successes and mistakes are still fresh in the mind. Reviews have to go both ways, however, so be sure to look critically at how you performed. As a project manager, did you give sufficient information and resources? Did the team members perform as requested?

Act on your conclusions
Don't let all the effort of getting people together and documenting experiences go to waste by archiving the document at the bottom of a dusty drawer (or 10 layers deep in a cryptically named folder on your hard drive) and then forgetting about it. Turn your newfound knowledge into an action plan to feed back into your project processes and methodologies.

Put the results of your postmortems up on your intranet where everybody can get access to them, or stick them up on the wall next to the coffee machine and in your team areas. You want maximum visibility here, and your aim is to drive the message deep into the minds of your team.

Postmortems are actually a very gratifying way to close a project, as you can discuss and document all the personal and professional growth you've experienced on the project. And best of all, you'll help yourself from being condemned to repeat the past.

Geoff is a digital content strategist based in Italy. With more than five years of experience in e-business consulting, project management, and Web development, Geoff helps clients navigate the maze of digital content development by defining, articulating, managing, and implementing content and editorial strategies. He has previously worked as a project manager and Web developer for IconMedialab and Collective Wisdom.

This article was originally published on gantthead on July 23, 2001.

More on gantthead
Related gantthead downloads: "Project Post-Mortem" "Project Post-Mortem Survey" "Project Completion Report" "Project End Report" "Project Evaluation Checklist for Managing IT Projects" "Post-Project Review" Related gantthead articles: "Destroy Your Project Early, Then Conduct a Pre-Mortem!," by Joe Wynne "The Art of Leadership," by Geoff Choo Items in bold are available only to gantthead premium members.


Editor's Picks

Free Newsletters, In your Inbox