Long IT: Rule 1

My first ultra "rule" for long IT projects is to have a realistic plan. One might think that a tautology, since any project should have a realistic plan. The difference is the consequence. Even at marathon distance, it's possible to have a nutty plan and still succeed. That almost never happens in 100s.

My first marathon was Chicago in 1993. I was in great shape, but hadn't done many long runs. I figured 3:30 was a good goal. It probably was if I was running some tiny marathon. But, at Chicago (this was before chip timing or corrals were used), I took 8 minutes just to get to the start line and another 12 to get to mile 1 due to the congestion of 35,000 runners all starting together.

To "fix" this, I started knocking out 7:30 miles. That worked fine up until mile 18, when suddenly I found myself in more than a bit of trouble. Any marathoner knows where this story goes: each mile got slower and slower, until I was barely moving at all. But, I finished. Granted, an hour later than expected (4:35), but I finished.

Make a mistake like that in a 100 and you don't finish at all.

Furthermore, a 30% overrun, while not a good thing, is not really that big of a deal in a small project. Small projects have lots of volatility and carefully trying to cover every contingency so you don't go over may cover your ass, but it also raises cost on average. Sure, some stuff will go wrong, but not EVERYTHING. So, you just go with it. Take the best guess, put it on the iteration backlog, and when it's time to go, you go the best you can.

Long projects aren't like that. Even a 10% overrun could be enough to kill the bonus of some VP who was very much counting on their bonus not being killed. Steering committees will revolt if early results don't look good; which motivates project managers to push even harder at the beginning (as I did in Chicago), often incurring technical debt that nails the project in the late stages.

It's supremely important to not go out too fast in an ultra. Taking a few seconds to deal with little things like a shoelace that's just a bit too tight, or a wet sock that's giving you a blister, have to be built into the plan. If you become a slave to the stopwatch rather than responding to the situation, you set yourself up for failure. Only by having a plan that accounts for such things can you practice the discipline of tending to all the little things properly without having senior management flip out over the cost of doing so.