Fog Creek Software
Discussion Board

Conducting Post Project Reviews

I'm trying to drag our development into the current century and one of the things I am doing is conducting a post project review. I've come up with an agenda (series of questions) which I will make available before the meeting, so that everyone has time to think about their responses.

I'm quite happy with my agenda, but I'm not daft enough to assume that it is perfect and covers every point. So, I was wondering what sort of questions everyone else puts into their reviews and how you go about conducting the review.

Pete J
Friday, August 1, 2003

Check this out, it's a guide to postmortems with a link to an example at the bottom, and it's very good:

Israel Orange
Friday, August 1, 2003

I like to start off with the following "big three" ...

"Did we deliver the product on time? If not, why not?"
"Did we deliver the product to budget? If not, why not?"
"Were we happy to ship the product? If not, why not?"

If the project went out on time, to budget and with good quality and morale, then the review should be a pretty short one. However, that's a rare thing.

Otherwise, analyse the "why nots". For example, the product wasn't on time because the quality wasn't felt to be good enough. How did that happen? Maybe there weren't enough technical skills on the team, problems with third party tools, inaccurate estimates, a lack of a proper bug tracking process. The specifics will vary from project to project but that's a good starting point.

I'd also be concerned about who I asked the questions to. The developers might be unhappy because they felt the project was rushed and suffered quality, but the sales team might be happy that they hit an important date to market and they can meet their sales targets. You need a good balance between them.

Better Than Being Unemployed...
Friday, August 1, 2003

Why only analyze what went wrong? Surely it is valuable information to know what went right? I mean, it might reveal that some choices that were made proved to be right. Then some inspecting of "if we had done that instead of this, would we then have failed" might actually be interesting.

I'm thinking that after a succesfull  project there would probably not be much denial or passing the blame around, so it could be very productive.

Maybe. Perhaps. Or maybe just go out and party ;-)

Antti Kurenniemi
Friday, August 1, 2003

The one thing I am missing at the moment is anything on budget. However, we never really had a budget, we just asked for the money when we needed it (weird partnership agreement) and stated a business case for it.

Maybe something along the lines of "were costs kept under control"

Pete J
Friday, August 1, 2003

I'd interpret "budget" as encompassing people as well as money, in a sort of abstract way. For example, if your project was completed in 6 months as specified, but you had to stick 8 developers on it instead of 3, then you've certainly delivered on time, but not to your "budget" of 3 developers. As a consequence, other projects have starved due to focus on this one.

A good point about focusing on what went right as well as what went wrong. It's just from my experience, people seem to be so much responsive to talking about bad things.

And I'm getting more cynical as I get older anyway ;-)

Better Than Being Unemployed...
Friday, August 1, 2003

I second the whole 'what went right' comment - I have noticed over last couple of projects I managed that we did some things right, but because they were'nt explicitly identified and commented on, they fell into disuse and then we had to learn the hard lessons all over again! It is key to identify stuff we did better than last time, even if it was only a small improvement.

And it is essential to keep both meeting notes and a summary report in writing - it is amazing how much you forget two weeks into the next project!

Friday, August 1, 2003

Post mortems (please call them this) are invaluable. Every project involves mistakes and things that could be done better next time. It's just plain common sense to reflect on this, log it and figure out how to avoid the mistakes and improve the processes for next time.

My biggest tip is ensure there is absolutely no recrimination - if there is a hint of this people won't be honest and the process will be flawed.

Friday, August 1, 2003

I second that, Yanwoo. A lot of PMs I have seen have turned into blamestorming sessions.

Friday, August 1, 2003

You may want to search the web for "Project Audit", which is another term that is used to describe the same situation.  You should really avoid just asking, "What did we do right?"  and "What did we do wrong?".  Those things tend to end up as self-congratulatory of the positives and a large finger pointing session for the negatives.

Instead, why not run down your task list for anything that completed earlier or later than expected and analyze that. "John, I see you finished coding the Widget extract in only three days instead of the 7 we had planned.  What was the difference?".  You might just learn that he was able to leverage existing code or that he had another coder help him out  or that he failed to estimate well because he was afraid of going over his allotted timeline.  (the last is really bad and you should find these things).

Or you might learn from Tom that one of his tasks took three weeks more than the two weeks you had allocated because he scrapped a lot of existing code, built some string handler on his own and spent two weeks debugging the thing.  That's good, and breeds positive discussion.  Okay, let's try to use common libraries and not recode if we don' t have to, etc.

You should have established goals, be they time, budget, resource utilization, etc.  How do you measure up against these?  What changes can you make to the PROCESS in the future (not, Clay needs to give us more money, he's miserly - but rather - We didn't communicate to finance how much this would cost, or we failed to estimate properly.  Let's look at our estimation process and see where we missed that three million dollars).

Remember, this is an investigation, so you should walk away with real knowledge and be able to change processes in the future based on what you learn.

Friday, August 1, 2003

Here's a tip I learned I learned while working for a Finnish company:

Everyone starts the meeting with a shot of vodka.

Even if it was 9:00 AM, our Finnish friends were there with a bottle of Stoli and shot glasses around the table.
No, I'm really not suggesting this but it did make for some interesting post-mortems.

Mark Hoffman
Friday, August 1, 2003

I agree with the point of being more specific than "what we did right" and "what we did wrong".

I've gone for something quite specific based on and heavily adapted from the following link:

Pete J
Friday, August 1, 2003

"Project Retrospectives: A handbook for team reviews" by Norman Kerth is your guide here.

Its published by Dorset House - which means you get a readable, short book by someone who has a strong grasp of the subject built up through practicing what they preach.

Saturday, August 2, 2003

*  Recent Topics

*  Fog Creek Home