Top Project Manager Practice: Project Postmortem

You may think you’ve completed a software project, but you aren’t truly finished until you’ve conducted a project postmortem. Mike Gunderloy calls the postmortem an essential tool for the savvy developer:

The difference between average programmers and excellent developers is not a matter of knowing the latest language or buzzword-laden technique. Rather, it can boil down to something as simple as not making the same mistakes over and over again. Fortunately, there’s a powerful tool that any developer can use to help learn from the past: the project postmortem.

There’s no shortage of checklists out there offering guidance on conducting your project postmortem. My advice is a bit more sanguine: I don’t think it matters how you conduct the postmortem, as long as you do it.Most shops are far too busy rushing ahead to the next project to spend any time thinking about how they could improve and refine their software development process. And then they wonder why their new project suffers from all the same problems as their previous project.

Steve Pavlina offers a developer’s perspective on postmortems:

The goal of a postmortem is to draw meaningful conclusions to help you learn from your past successes and failures. Despite its grim-sounding name, a postmortem can be an extremely productive method of improving your development practices.

Game development is some of the most difficult software development on the planet. It’s a veritable pressure cooker, which also makes it a gold mine of project postmortem knowledge. I’m fascinated with the Gamasutra postmortems, but I didn’t realize that all the Gamasutra postmortems had been consolidated into a book: Postmortems from Game Developer: Insights from the Developers of Unreal Tournament, Black and White, Age of Empires, and Other Top-Selling Games (Paperback) . Ordered. Also, if you’re too lazy for all that pesky reading, Noel Llopis condensed all the commonalities from the Game Developer magazine postmortems.

Geoff Keighley’s Behind the Games series, while not quite postmortems, are in the same vein. The early entries in the series are amazing pieces of investigative reporting on some of the most notorious software development projects in the game industry. Here are a few of my favorites:

• Haunted Glory: The Rise and Fall of Trilobyte
• The Final Hours of Half-Life
• Knee Deep in a Dream: The Story of Daikatana
• The Final Hours of Black & White

Most of the marquee games highlighted here suffered massive schedule slips and development delays. It’s testament to the difficulty of writing A-list games. I can’t wait to read The Final Hours of Duke Nukem Forever, which was in development for over 15 years (so it must be a massive doc). Its vaporware status is legendary— here’s a list of notable world events that have occurred since DNF began development.

Don’t make the mistake of omitting the project postmortem from your project. If you don’t conduct project postmortems, then how can you possibly know what you’re doing right– and more importantly, how to avoid making the same exact mistakes on your next project?

About managing risks

A little time ago I was proposing to my manager a tool and a methodology change for our PMO. The tool and the methodology were based on risk mitigation and tracking. I am a firm believer that “Issues” don’t just come up. Issues that just come up were once risks that went unnoticed and eventually, like any living (yes I belive that risks are living beings) thing, evolved to Issues.

When I exposed the principle that the project manager had to invest time discovering risk, instead that divert time to write down risks that presented themselves (btw, the risks that become god-like-issues don’t present themselves) and that map all risks was a vital part of that, he mocked me saying something like: “So when I see that an airplane is about to crash in my building im supposed to run and create a new risk entitled plane crashing at the office?” I said no, you’re not. But the risk of loosing your primary work station should be increased to 99% and the risk of being without resources should also be increased. I also said that if you were a good project manager you would also contact HR and ask for new candidates.

Of course the example above is an extreme event. The fact is: It’s uncommon that a risk escalate so fast (like living things, once again). Risks tend to grow very slowly, being fuelled by negligence, incompetence and lack of proper organization/tracking. Most risks that become problems were actually mapped and “handled”. A perfect example is: an ex-manager of mine called the client warning that he’s servers were outdated. By doing so he actually believed that he handled the risk of not being able to deploy the product due outdated software. Fact is that the deploy date came and the deploy did not happen on date because the servers were outdated. He’s mistake was to belive that because someone was warned he would take any action. What he really should have done is called day after day and only close the risk when the client confirmed that the servers were updated, and if he did not updated by the day of the deploy escalate the risk to issue.

The tool that i proposed would handle situations like that perfectly. OK its was not a third part software but a customization on Sharepoint 2010. The tool principle is that you would not only register the risk/issue. You would have to register also what actions you as project manager took in order to solve this issue, and how effective these actions were. Yes there’s an overhead but besides a complete follow-up on the evolution of the risk/issue, a PMO manager could actually see how good each project manager is based on the effectiveness of his actions. It was a thing of art. If we evolved to a “better practise” and could assign a cost value to each task we would be able to measure how much each risk/issue costed and by implication how much each actions costed. And knowing how effective an action was, we could designate a cost-benefit value. It is utopia for most of the managers.

I must disclose that I am not a project manager. I am a developer. I develop solutions for leaving… and of course… a boy can dream…