, 12 comments , , ,

Programmer optimism, and the "Death March"

I’m tired of hearing lines like “programmers are such optimists,” said in a disparaging way, by people who should know better. It’s a common refrain in corporate offices, usually when a software project is running late. Often the blame is placed on the programmers who are working for free on nights and weekends to make stuff work.

The project isn’t late because developers are braggarts. It’s because management has assigned them too much to do, which, as Peter Kretzman warns is the best way to not get what you want from your I.T. organization.

The “optimist” accusation is a cheap shot, and here’s why.

Here’s the project kickoff meeting.

It’s for some strategic initiative that executive management is excited about. Once in a while, the initiative itself is kind of stupid, but for argument’s sake let’s say it’s actually a reasonable idea: we’re opening retail stores in an underserved market, adapting to a new regulatory regime, or introducing a new online product. Stuff like that.

This meeting is led by, let’s say, the CFO, who has already budgeted the project to the departmental level. Line executives under the CFO are making fifteen-minute presentations (with Power Point! Yay!) on their areas of responsibility. Every slide has bullet points for tasks, deliverables, and objectives. And then department heads break out with their teams to figure out how to make it all work. It’s a half-day or full-day exercise.

Team building! That’s great.

Now let’s say you’re in the middleware group. You’re all about the transactions and the data interfaces, right? And obviously at this point nobody’s defined a transaction set. You know it’s going to be Oracle, and the database developers are in the next group over, and they have to work hand-in-glove with the DBAs before you get any information from them anyway.

You have just seen a half dozen slides full of bullet-point tasks.

And they want a time estimate for each one. In hour terms.

That’s not crazy.

But it is crazymaking.

Of course management wants an estimate of hours. They need to take that estimate, load-factor it, and divide by something like 160 to figure the number of person-months your area’s going to need. Very logical, and quite honestly that’s the best they can do at this point.

But raise your hand if this has ever happened to you… or never mind, raise your hand if it hasn’t: You give them an hourly number that calculates out to 36 person-months, and there are four of you on the team, and so you figure that’s nine months, and they roll out the top-level Gantt charts showing your part of the project doesn’t get the ball until June, but we go live before Thanksgiving.

Naturally it’s all critical path. You don’t see slack before or after your slot on the Gantt.

Okay, that is crazy.

You’ve been in this racket long enough to know this is pushback time. You go to your team lead or your department head, on the spot, and say it. “We can’t do this. It’s nine months with everyone fully committed, and that’s not taking into account our maintenance load on everything else. They’re giving us five months.”

Then the haggling begins.

So far everything I’ve said is par for the course in classic project management, but here’s the point that people don’t seem to talk about. While it’s true that management is unqualified to dictate five calendar months or 5000 person-hours, so are you.

This is where the folk legend of programmers as optimists comes from. You gave your estimate at the kickoff meeting, but it was based on all you had at the time: bullet points and a good knowledge of your team’s abilities. Unfortunately, the project doesn’t really run on bullet points, and when management responds to your pushback, what are you going to say?

By contrast, Purchasing can say flatly that the lead time from China is six months no matter what. You can’t make the assembly contractors and ships go any faster. Finance can say with confidence that cash flow absolutely will not support a bank loan until September unless the board is willing to pay twice the interest. Logistics has a warehousing model. Marketing has stats to show that the product rollout campaign is most effective in August and is simply impossible before July anyway.

And what do you have again?

You have bullet points and what’s in your head. (I’m deliberately putting the words “head” and “bullet” close together here.)

To say that “programmers are optimists” is foolish at best. The reality is that programmers work with the most malleable part of the process. It’s true! Virtually everything we do is mental work. Even when we need “tools” they are usually the kind of thing you can order online and download in fifteen minutes.

Other specialities have the luxury of outside factors that buy time. We don’t.

So there you go.

The CFO calls her department heads in for a status meeting two weeks later. Costs for this initiative don’t fit into the budget the board approved, so 20% has to be cut. She can’t cut production costs any further, it’s already being done in China. She can’t cut financing costs. She can’t cut the construction costs because it’s already low bidder. The only place to cut time and money is where the estimates were vague and uncertain to begin with–which is you.

Stuff rolls downhill, as it tends to do, and your manager starts the Monday meeting with the announcement that the new project is simply going to have to get done in five months, not nine, with no additional resources. Can you say no to that? On what basis? Can you really argue that the bullet point “Create JSON interfaces to SQL data” is definitely going to take the 200 hours you said rather than the 80 they want you to say?

Of course not. It’s a bullet point. You’re on your way to what Yourdon famously called a “Death March” project.

Guess what.

You’re basically getting a project with “Agile” inputs and “waterfall” outputs. In this scenario, you don’t have adequate information even to make a time estimate, until it’s time to dig in. This isn’t actually bad in its own right–it’s kind of Agile in nature–but you were committed to some other, lower estimate six months ago and it can’t be increased without breaking critical path.

At this writing, I don’t have a great solution to the problem of timeline crunch. What I do know is that locking in a time schedule with nonnegotiable objectives is a near-guarantee of failure. If you make it succeed, it’s against the odds and probably your health, and if it fails… that’s not your fault.

How do you prevent Death March projects in your I.T. department? The comment section is yours.