No, not daylight savings time (which I hate, but only because it messes up the kids sleep) but early in a project is the only time where you can put some time in the Oh Crap Bank & Trust. Really, you know it’s true.

It is not that we are lazy during the beginning part of a long project, it’s that we have not usually done the proper planning in the beginning (I am guilty of this too.) Or we’ve forgetton that we need to pay attention to the runway and not just the sound of the jet engines. (Ok, that was a strained metaphor - development as a jet engine. Nice visual inside my head anyway.)

No, the beginning of the project is the only time where you can toss features/functionality out of the lifeboat in order to get a clearer and more do-able timeline to complete the project.

We’ve all been on projects where, at the very end, things are slashed out of the project (”XML export? Version 2!”) but by that time a lot has happened. It’s been planned, spec’d, managed, partially programmed, etc, etc. So you pitch XMS export out a month before go-live, but you already spend a man-month on it. Oops. Can’t get that back.

So what we’ve done is the project version of best/expected/worst case for Promote-My-Site’s feature set. We laid out what we’d like to deliver in V1 if we had a ton of guys, all the time in the world, and money-unlimited. That was fun. Then we said, what can we get done if our primary business sucks back most of our management and technology time but we still want to launch early-2008. Depressing. Then we said: assume two guys quit, but otherwise everything goes as plans. Voila, we now have best, worst, and expected cases.

Then we took the features/functions in the expected case, and started looking at dependencies. Because if you have a lot of features that depend on one difficult pivot, then you have to be pretty wary of how much leeway you really have.

In the end we have a good map of functionality that we think will satisfy the market (for a V1 product with weak competition) and a vision for V2 and V3. And we know where our touchy spots are so if we run into issues we know what disappears.

Plus, because my business partner is really smart, we also have a candidate list of V2/V3 features that we can bring back in given some slack at the end, or things we could bring in to replace features that get thrown out.

But you can’t really do any of that very well when you hit the moment. Say that your bandwidth testing fails and you have to yank your “video editing stream” option. It’s a bit late to sit down and do all that dependency and version switching stuff. It’s not that you’re suddenly stupid, but you’re certainly under a lot of pressure, probably are tired, and there are angry programmers stomping around drinking Monster from the 2 gallon jug.