One of the tenets of software process improvement (or, really, any process improvement) is conducting a thorough, honest “post-mortem” on a completed project. The concept is simple: you take a recently completed project (or well-defined milestone), and look at the good, the bad, and the ugly, and turn your observations into actionable steps you will take on the next project.

Actually executing a post-mortem can be a challenge to companies of any size. In my experience, there are a number of roadblocks to actually completing a post-mortem. This article discusses them, and is targeted towards the typical middle management software professional heading up a project. However, stakeholders of all levels will hopefully appreciate the points herein.

“We don’t have time to sacrifice billable/profitable hours to do a post-mortem.”

This is a difficult point to argue, especially when it comes as a directive from the executive. Even if you successfully browbeat the boss into letting your team do a post-mortem, you are then faced with the even more daunting task of later convincing him/her that the outcome is going to be a net benefit to the company’s bottom line, when you may not actually have the authority or the buy-in to implement all of the recommendations from the post-mortem.

All hope is not lost. For the purposes of a successful post-mortem, you really need buy-in from all parties, and I suggest you start from the bottom. I have consistently found that motivated developers (and even some unmotivated ones) are very, very eager to share their experiences and opinions, so get them on-board, along with vendors, customers, and anyone else with a stake in the project who is available for a few questions. Essentially, I am suggesting you go ahead and do the post mortem anyway—informally is just fine. Getting fired is unlikely. At the very least, you and your team will learn some valuable lessons, and it’s possible the chief may soften up, too.

“The project went well. We don’t need to do a post-mortem”.

This is a common pitfall. Whether the project really went well—or you think it went well—is debatable. Unless your company directly profits from the warm, fuzzy feelings of your project management team, you really need to analyze and measure your success criteria.

Let’s be generous, for a moment, and assume that the project was successful. The more successful the project, the more you have to gain by doing a post-mortem. Imagine the army of doctors that would line up to do an autopsy of a real-life Superman. The idea here is, find out what worked, why it worked, and then reproduce it.

“The project was on time, on spec, and on budget. We don’t need to improve.”

This seems to be a Holy Grail of sorts for some companies. It isn’t. Even though a project may indeed be on time, on spec, and on budget, who defined the timeline, specification, and budget? The problem is, some mature software and business teams get very good at working together and setting goals they know they can meet. To the extent attainable goals are a good thing, the danger lies in becoming complacent with sub-optimal developments.

The company that can develop a certain widget in 6 months for $500K is in for a shock (not to mention the possibility of significant lost revenue) when their competitor develops a better widget in 4 months. Wouldn’t it be nice to be ahead of the curve?

“The project was a flop for obvious reasons. Let’s not waste more time by over-analyzing it!”

To some, doing a post-mortem on a failed project can feel something like eating a box of thumbtacks; more so, if the outcome seems inevitable. Suppose you chose a vendor to develop a seemingly innocent bit of middleware for your project, and they significantly overran their deadline, creating a cascade effect on your entire timeline. It is easy to blame the vendor for your failure, and vow never to use them again. It is harder, and so much more valuable, to step up a level, swallow your corporate pride, and ask the more difficult questions, like:

• Was outsourcing this component really the best strategic move?
• Did we make any serious attempt to mitigate this risk in our project plan?
• Did we fail to recognize a dependency upon this vendor’s deliverable that caused the critical path slip?
• Were there any early warning signs that we failed to act on?
• Could a different approach to managing this subcontractor have helped us identify the problem earlier, or keep the project on track?

Of course these are just a few of the questions you might want to ask in a case like this. Always remember to keep a mixture of “standard” post-mortem questions, and to really ask the hard questions that are specific to the project’s circumstances, as well. Resist the urge to take a “clean room” approach and let just one person come up with all of the questions. Encourage all stakeholders to participate; good answers are more likely to follow good questions.

“We don’t want to say anything negative, because it will make us look bad/get fired/lose our bonus/etc.”

For whatever reason, some companies manage to create an unfortunate culture where employee performance appraisals trump honesty, and developers become loathe to admitting mistakes—or even suggesting improvements. To be fair, I doubt that companies’ top execs intend for this to happen. However, some of these same companies are also pretty bad at recognizing and fixing a gun-shy culture. Doing a post-mortem in this sort of environment may not net the most useful results, and shifting a defensive culture in short order may be next to impossible, in your position.

The best advice I can give you in this case, is to create a small bubble of trust within your project. Go one-on-one if necessary. If you think your stakeholders won’t be honest with you, that’s another problem entirely. Clearly this is not the best time to flex authority and demand honest answers. I have seen entire teams literally go stiff when someone takes this tack, with some mixture of fear, hostility, and apathy, in proportion to the relative burn-out of the team. Instead, I suggest finding someone on the team (probably below you) that is well-connected to most people, and have them take a soft approach. Put them in charge of gathering the inputs (preferably around the lunch table, not the boardroom table), and back them up with tools, information and mentoring, not muscle. Putting the best people on a task is of course one of your best strengths, right? Don’t forget to look at the project’s culture as part of the post-mortem, as it almost certainly had an effect on the project itself.

“We have done post-mortems before. Nothing ever changes.”

You are more likely to hear this sort of comment from the trenches. The perception (probably based in reality) is that the company’s efforts to analyze projects have historically not brought any real change. Developers don’t see the value, and believe the post-mortems are little more than a chance to vent, or pat themselves on the back, or otherwise waste time they could be devoting to the next project you are keeping them from.

There is no easy response to this assertion. If your people feel nothing has changed, they are probably right. Surely, not every recommendation will be implemented, but, by choosing a set of suggestions from a key project, and then reviewing the effects of those suggestions, in a visible and inclusive way, is the key to demonstrating a company’s resolve to benefit from the collective genius of its employees (not to mention vendors and clients). This need not be an onerous undertaking. Having a quick meeting—or at least some sort of announcement—a month or so after the post-mortem to review the implementation status of the suggestions will go a long way, providing some actual progress has been made. Having measurable criteria for improvement is also important, but the time quantum there is typically longer. Keep the door open for additional suggestions at any time, and, if one of the recommendations isn’t working, get rid of it. Obviously, before making a serious investment into any recommendation (including job creation), the company should absolutely undertake due diligence—just don’t over-analyze.

- – -

These are just some of the more common sticking points I have encountered. I am sure that the seasoned readers of this article will have had varying experiences when attempting to run software project post-mortems. Please do share your comments here!