The challenge is knowing when a project is complete. Unlike a game, which has a clear definition āWhen we shipā, some projects seem to drag on indefinitely with change orders, etcā¦
Sometimes we hardly noticed that a project has transitioned into the maintenance phase.
So consider āMidMortemsā along with Post-Mortems. These would be āretrospectivesā at significant milestones within a long project.
Your blogposts are too interesting. I was just going to sit down and check the mail, and now Iāve been here for an hour, reading, following links and (almost) ordering books.
Or simply use the term process evaluation. I used to do this during projects at uni, in the real world (as Jeff points out) I have yet to see one performed. Indeed, thereās hardly time to polish off and ensure the quality of the project already. A shame really.
Very interesting. Iām sat here on a bright December morning preparing for a post-motem Iāve organized for tomorrow morning and decided to check my bloglines account when I came across your article.
Good stuff (esp. the links)
Cheers
My employer has recently ended post-mortems. The exec in charge thinks they donāt produce useful results. Iām sort of at a loss to respond to this depth of cluelessness.
Interesting. Perhaps Iām one of the boring people but I donāt much like the word āpost mortem.ā I guess thatās 'cause the projects Iāve worked on have been successful.
We tend to hold retrospectives, but donāt do them at the end ā¦ we hold them after every release (once a month), and theyāre short. Itās amazing how much more productive and cohesive (they donāt always go hand-in-hand ā sacrificing a little bit of short-term productivity for long-term inter-relational work is a hard sell, but valuable) a team is when itās continuously reflecting on its successes and failures.
I generally respect most things out of the Pragmatic Programmers, and this oneās no exception. If you reflect on your project more often, and the team has more of a stake in the way they operate, then the project has a better chance of success, in my opinion.
Oh, and I swear, I am not, nor have I ever been, a consultant. In-the-trenches developer/retrospective facilitator here.
Iām a big fan of the postmortem in making me a better developer, but Iām usually a little nervous to have them since Iām usually the lead programmer, and managed most of the project outside the money issues. Iām the only one to get the blame for failures.
It seems like at the end of every project, the final conclusion is always āwe should have had a better statement of workā
Seems like I would have that one figured out by now.
Haacked is completely right though. Most of the projects that Iām working on now donāt have a ship date. They just transition into a new phase of the project - be it maintenance or adding features.
I do have those SOWs down though. You bill by the hour, keep track of every little thing you did. If you spent 15 minutes writing an email to explain how to use the system, you can bill for that later. At the end, just send them your spreadsheet of every hour you worked and bill. I love working like that because timelines and scope-creep are no longer issues. Blissful.