The Grim Yet Important Role Of Postmortems

So you finished that big project for a client and now you and your team are reveling in that feeling of completion. There were ups and downs and bugs and accidentally deleted code and such, but you made it to the end, and now it's time for that next big project. That's how many companies work nowadays anyway. And the next project will repeat in similar fashion more than likely. More code deleted, more bugs, more time spent fixing said bugs. And this unfortunately can continue on for some time. Project management however doesn't stop when the project ends. And one of the steps that should come after every single project, software or not, is a postmortem.

Postmortem - In project management, it's a process normally saved for after a project is completed in which elements of the project are analyzed to determine how successful or unsuccessful they were, in order help improve the process for future projects.

It's a step that may programmers I know dislike, probably because they'll be called out on their shortcomings and because blame will be thrown around, as is human nature. But that's an important thing too, and deserves its own blog post. Coming soon. You can't fix it, if you don't know that it's broken. So the faster you figure out where you're coming in short, the faster you can correct it. So here are a few key topics to discuss when going through a postmortem with your team.

What Went Wrong

So if we don't learn from our mistakes then we are doomed to repeat them. And this is very true for many software development projects and companies. I've worked for a good number throughout the years, and only 1 of those companies ever concerned themselves with postmortems. The rest did what most project managers would do, and that is continue moving forward without addressing any problems ever because more is better in their eyes.

This is the time to bring up any communication issues or any technical issues as well. Maybe you used the wrong technology for the project and maybe it took twice as long to complete. By not discussing this, you'll end up using that same technically on the next project, which in turn will again lead to longer development times. Things that I've personally have seen go wrong in projects are relying on 3rd party applications initially, and then paying the consequences later on when it becomes impossible to change it. Or dynamic role changes, where one person starts with one role in mind, such as designer, and ends up as a junior programmer at best trudging along trying to keep up.

What Went Right

And as important as pointing flaws out are, equally important is highlighting all of the positive things that went right with a project. Because these are the steps that will want to be repeated going forward. Maybe this time around, the project lead did a fantastic job or maybe a new technology was used that helped facilitate the entire thing. More important than anything you want everyone on the team to be happy with the work that they're doing, so anything that enforces that is something that's gone right.

And this of course includes the small victories. Personally, things going right for me include any portions of the project that were completed, and then never talked about again. It just worked from the beginning and stayed that way throughout the project. It's a good time to discuss why it worked, how it was built, and if that same process can be applied to other elements.

Did You Finish On Time

Almost no project is ever on time. Most projections are usually based on the idea of perfection, and that just simply never works. It's almost impossible to predict the amount of time that will be required for when things go wrong. If your database schema is designed wrong, then you'll have to start over. Sometimes clients change their minds on things halfway through projects and end up costing developers days and days of work. Different programmers have their own algorithms for figuring out this excess time, but any experienced developer can probably give a fairly good estimate based on the type of project, the technology being used and the number of people working on said project. I've personally found that the more people get involved in a project, the longer that project takes to complete.

Is The Client Content With The Work

And now that your team is done bickering and hopefully reconciled into a much stronger unit, it's time to consider the most important question. Was the client happy with the final result? Did the website meet all of the expectations, is it secure, is it easy for users to use? All these questions should be addressed, because without customers, you don't really have a company. Maybe the client sent repeated requests for status updates or maybe there was miscommunication and the final product works differently than they had expected. That's normally the biggest issue that I've personally seen, and for sure it's a problem and something that a company should definitely attempt to mitigate.

A Few More Important Questions To Ask

You can think of a postmortem as a type of risk management meeting. So anything that will reduce or increase risk in a project should be covered. Questions like:

1. Who didn't enjoy working on this project?
2. Who had too much work?
3. Who didn't have enough work?
4. Does this postmortem suck?

These questions are important because they're at the very root of how a project gets created. If someone has too much work, then you will have time issues. If the project wasn't fun to work on, then future projects won't be fun to work on either. Postmortems don't always work, and that's important to remember. You can have 3 members of a team create a giant list of things that went wrong, and then 1 member who thought everything was perfect. So it's not going to solve all of your problems, but it can definitely help you decrease that number.