Fog Creek Software
Discussion Board




Postmortems...

... and not the Quincy kind.

Does anyone ever do them?  Does anyone ever follow the recommendations that arise?  How big should a project be before it needs a pm and when should it be done?

Boofus McGoofus
Tuesday, July 20, 2004

Game Developer magazine usually has a postmortem each issue.

Buddy Jasper
Tuesday, July 20, 2004

Even if there is no intention to follow the recommendations, the process can be cathartic and very therapeutic and menally healthy for all.

The recommentations are not going to be institutionalized nor should they be. An addtional value is that participants can point to the formal report of a past death march and say "We are doing the same now as before and we decided that was a bad idea in this report." Being able to point to the written report gives complaints a new form of credibility.

Dennis Atkins
Tuesday, July 20, 2004

In general, a post-mortem is most useful in an atmosphere where improvement is a cultural value in the organization; seen as desirable on both an individual and team basis.  If people aren't interested in improvement, or worse, if they are interested mainly in CYA (usually due to personal failings, lack of desire, or a blame-oriented attitude towards mistakes/failure), it's pretty much guaranteed not to accomplish its supposed purpose.

As for size and timing, I think a post-mortem is best done by a small group, when all of the problems and mistakes are still fresh in the mind but there has been enough time to think them over and see them from a distance.  Say, a week after the end of the project.

Finally, note that you can have multiple post-mortems.  The QA team can PM their efforts; the development team theirs; etc.  You can PM the first phase of a project, the second phase, the nth phase.  You can have a technical PM, financial-oriented PM, management PM.

But, this is all very idealistic.  In reality, everyone has an agenda, and number one is usually "don't admit to anything publically".  It's rare that you have an environment where it's safe to talk about mistakes and problems.

Should be working
Tuesday, July 20, 2004

To follow up to Should Be, would it be possible to have a "half" post mortem?  To identify things that went well and gloss over what went badly?  Or is that a complete waste of time aside from the ego stroking?

Boofus McGoofus
Tuesday, July 20, 2004

Most places I have worked have such a punitive attitude that a post-mortem is impossible. In particular, nobody will ever admit they made a mistake for fear of punishment.

It is a truism of psychology that those who will not admit to their own faults can never overcome those faults.

dot for this one
Tuesday, July 20, 2004

what about a simple 3+/3-

like said above, some companies go way overboard.

Patrick
Tuesday, July 20, 2004

For both Should be and Boofus:

My favorite post mortem was at the Camel. They did a production install of a new module during a maintenance window, did post-install checks, everything worked, they went home.

Two days later the air raid sirens went off and the module was rolled out fast when they realized that production data wasn't going into the production database. Analysis revealed a hard-coded database path in a middle-tier component, so the production data was going to the test database.

The post mortem was all about some missing signature on an approval form, and how the QA team didn't know to change this hard-coded path, yadda, yadda.

I asked "how come the production system can see the test database?"
Blank stares.
"If the production and test systems were completely firewalled, then the installation tests would've failed and the remedy could've been found at leisure instead of writing two days data to the wrong database"

The discussion went back to the missed signature (which wouldn't have changed anything)

They never closed that firewall hole.

[sigh]

Philo

Philo
Tuesday, July 20, 2004

ROTF, Philo.  Any idea how things are going there now?

OP, if you want to make it a feel-good session, by all means leave out the "oops" parts.  Taking what another poster said though, you can do a +3/-1.  "We did this, this and this right, but we goofed that up."

A real PM addresses root causes, BTW.  This means asking "why" and "how".  Not just blindly identifying things that went right/wrong and then doing/not doing them in the future.  That's reactionary.  Sometimes, you do the right thing (or avoid doing the wrong thing) by pure luck.  If you want real improvement, you need to make an effort to understand how decisions were made.  And then improve the decision-making process so you can arrive at better decisions in the future.

Should be working
Tuesday, July 20, 2004

"Game Developer magazine usually has a postmortem each issue."

Once you've read two, you've read them all.

Read the first one for the mistakes, and the second one for the addition of "we didn't avoid any of the mistakes in all the post-mortems available to us" to the list of mistakes.

After that, there's rarely anything new.  ;)

the blind leading the lind through a minefield
Tuesday, July 20, 2004

Hey hey, in my case I've postmortem-ed projects with the same dev team at two different companies, which I found incredibly educational.

If you're not in the kind of environment where everyone will be honest and open about mistakes and cares about improvement, but you still want to learn something yourself, you can.  Just start cutting people until you find a subset that has (or at least approaches) the right qualities and take those guys out to lunch.

Mikayla
Wednesday, July 21, 2004

*  Recent Topics

*  Fog Creek Home