Project Post Mortems

Introduction

In order to learn from the past, we need to review projects upon completion. This includes both projects that succeeded and projects that failed. We want to not only learn how to make projects that don't fail, we want to reinforce what works.

Background

There are many ways to review projects. I have found this to be incredibly effective. You can change some of the rules, but I encourage you to enforce the pre-meeting prep work, otherwise it is not nearly as insightful.

Process

The Process of our PMDs (Post-Mortem Dumps) is based on recording the Good, the Bad, and the Ugly.

The Good, are things we want to encourage in future projects.

The Bad are things we want to avoid. They are not life-threatening, but can be severe things. When listing a Bad item, it is important that ONLY the item, or the situation, and NO NAMES are used. This is not about people, it is about process, events, etc.

The Ugly are things that will either destroy the company, the clients, or the developers. There should be few Ugly items, and preferably NO ugly items. When in doubt, it is Bad. Ugly includes things like the circuit fried in test, and actually harmed someone. A developers' wife was taken to the hospital and the manager refused to let the developer leave until his work was done. Or a developer failed to indicate that his health was in question, and working 18hrs was literally killing him. There was a giant security hole that put our company data at risk during testing! These are Ugly, anything less is Bad!

So, you schedule the meeting and assign the work. You request (and require) that everyone in the meeting fills out their Good, Bad and Ugly list. You give them the explanation above, tuned to your company.

The audience should be the developers, and managers, and business contacts who were involved in the project. In general, the more the merrier. Anyone who came in contact with the project or was impacted by the project is valid.

The #1 take away is that this is part of Continuous Improvement. Nothing that happens or is said in this meeting will be held against anyone. The closest thing would be asking someone who is simply being disruptive to leave, but this has never happened in any of these that I have done.

To start the meeting, you verify upon entry into the room, that people have at LEAST one thing written down in one of the 3 areas. Otherwise, I don't let them in. I made an exception once, for a manager, but I was forced since he was also my boss (trust me, I tried to not let him in).

Then, you summarized how the project went. Ask others how they feel it went. Make sure you are all talking about the same project. This is an opportunity to learn and grow.

Now, you setup the Easel (I now use software and a projector). And you start with the Good. You remind them that the Good items CAN have names with them. And you collect them in a round robin fashion. Each person can either add a new item or second an existing item.

When the list is exhausted (nobody has anything to add or second), then you try to summarize. In the case of the Good list, you find the 1-3 things you want to make sure you do in future projects.

Move on to the Bad List.

You remind everyone that NO Names (positions are fine, but be careful), and try to capture them generically. I will give an example.

Tom Lied... [cut off, remind no names].
Customer Lied about the requirements, said we never needed an edit feature. [can we do better?]
Specifications said ABSOLUTELY that Edits would not be required, but then they were...

The point is that you want to capture what is useful. Tom will not be on every project, nor is that truly fair, and it is not what this is about.

"Customer Lied" is probably not the way to record things. If it is about a real lie, and it is pertinent, maybe. But getting into the real issue, and getting the emotion cleansed from it is important.

Finally, you exhaust this, then summarize to get the 1-3 things you DON'T want to do or simply want to avoid on future projects.

Now, you go to the Ugly. We have many projects without Ugly items. And you should too! Ugly items are AUTOMATICALLY on the "This will NEVER happen again!". I actually had the one where a pregnant spouse required a lead developer to be home taking care of their 4 other kids. The issue was a lack of communication. In hind sight, the company would have paid for a temporary care giver to avoid the pain this caused us. Heck, I would have paid for 1/2 of it out of my own pocket had I known.

Now, the interesting stuff comes in. You grab the top items, and you discuss them. You discuss what causes them. In our case, the one Ugly item was because the team was new, and the developer in such a critical position but so new, he was afraid to admit to the home situation dragging on him. He tried to work later, but was exhausted and made more mistakes. Simply put, lack of an effective way to communicate personal issues, which I fixed with a "close my door and lay it on me" management style.

When success becomes paramount, it helps to become flexible! We enhanced our communications process. We reminded everyone that people come first. We made sure to start new projects by remembering what we would try to do, and what we would avoid doing. That helped change the culture and improved future projects.

Points of Interest

Making sure everyone shows up prepared is key to this working. They should have collected their Good, Bad and Ugly lists all on their own. But we collect them in Round Robin passes, and we allow people to second other peoples points. Sometimes, someone has the better way of explaining it.

Finally, having done these for many years and many projects, here are some of what we learned at the highest levels.

1. CEO sits in on one of these. His "Good" was how hard everyone worked trying to reach the deadline. He saw this as an amazing thing with the team rising to the occasion.
2. Employees mentioned the artificial deadline as a Bad thing. That they made a lot of bad decisions to reach the deadline, and we will have to refit things.
3. Employees reported the Free Pizza dinner on late nights were awesome, they needed a break and were re-energized.
4. Employees complained (Bad) that it seemed the manager was ordering the Pizza for 8pm delivery trying to force people to work ever later (another company, and it turned out to be true).
5. Client meetings were hampered by upper management. Upper management was preventing getting accurate specifications because they did not think it should be that way, or they were indirectly silencing the Domain Experts.
6. Deadline Hockey. When something is due on Monday, is that Monday at 8AM, Noon or 9PM? It is not fair if you expect something on Monday, but you don't effectively get it until Tuesday and now you don't have the time to work with it as expected. Anything due on a date is due in the morning, prior to work.
7. Business side missed their deadlines but tried to keep developments deadlines. This was a huge discovery. The Business side of the company had been weeks behind in literally all of their decisions. They did not buy into the impact they were having on the schedule. This went back into our project management, and eventually became a requirement that they had to make their deadlines or extend ALL of ours.

In the A case above., at the end of the meeting, the CEO asked if he could cross off his Good item! Privately, he thanked me for doing the Post-Mortem, and encouraged me to do more of them. He realized that the worse thing you can do to a dedicated group is to put too much pressure on them for any period of time. BTW, his top IT guy was new in this project, and stayed around 16 years. He has not had IT turnover in 7 years, outside of this person, who actually retired from work at a young age.

Do not underestimate the power of what reviewing your projects can teach you, and your entire company. When you review what actually happened, how people felt, or were made to feel, and how things could have gone better, you will learn better ways to approach future projects.

Feel free to leave comments on your experience.

History

• 11-Jan-2016: Initial writeup