Project Postmortem

The project I work on is close to the finish line... And there are flowers and champagne and long vacation waiting for us? Well, not quite... :) It is the right time to stop for awhile and sum up what has been going on. Things just doesn't stay memory for long, so better write down the important stuff right now. And if anybody except myself can draw some valuable conclusions, while reading, it will be more than worth it...

So, it has been nearly five months since in February I joined my current project. It was my first for the company I work for after my first and only job change. When I joined the team, the requirements gathering, analysis and the overall design of the project were already done. So after two weeks of researching, discussing and deciding upon various important technological aspects of the project, I jumped straight to implementation. Of course, it turned out (I would be a fool if I expect otherwise) that the preliminary design was not perfect and detailed enough just do the coding thing and not lift up my head up from the keyboard. Throughout these four months there was plenty of room to go through short cycles of analysis, design, implementation of various aspects of the project. I actually ended up involved in quite a lot of the parts of the system, contributing ideas and code. And I had to say that I liked most of it. It was challenging enough and there was a plenty of room for improvements and fresh approaches in many areas. I aisle tried some new good practices and build upon some not mature ones.

Hmm, I guess, this would turn out a lengthy post if I dive in great details of everything that was going on. So I will keep it for another post. But let's go back to the title of the "Project Postmortem". Well, I am definitely not the only one that should be writing about it. It is a collective effort, and if only I do so, it becomes single-sided and not that valuable.

But what is exactly a "Project Postmortem" and how to conduct it. I first read about this practice in a Steve Pavlina's article Conducting a Project Postmortem. He also provided a Postmortem Questionnaire and a real project postmortem: Dweep Postmortem

So, convinced of the benefits of such a practice, in the end of the year 2003 I did a 10 page postmortem for a 6-weeks project. Since I am not a novel writer, I will most likely not stick to that ratio of [project length]:[postmortem pages count]. The truth is that in that 6 week project I was pissed off by so many things that I had difficulties keeping the postmortem even that short. I cannot say that in my current project everything went absolutely smooth and great, but it was a bliss, compared to a few of the project I had been in. So the postmortem will be shorter.

Even though in the postmortem of the 6 week project I listed plenty of bad decisions and examples of miscommunication, I succeeded in coming up with a bunch of positive conclusions and to enumerate some good things that we actually did right. I also did my best not to offend anyone and not to put the blame on specific team members. The purpose of the project postmortem is not to point with a finger and criticize or to demonstrate "I told you so" attitude. Its purpose is to evaluate the good and bad things and to make sure everyone learned his lessons, so that the next project will be more successful and enjoyable. The only thing I can hardly tolerate is not learning from past mistakes and blindly repeat them, without even trying new ways to handle them. There were a few decisions in this project that could be classified as mistakes (I have my share, too). So I have to search in memory to bring them out. Some say "No pain, no gain", but I think it would be more of an entertaining task...