Forced March, not Death March

Posted by Robert Merrill on January 17, 2012 under Software Development, Software teams | Be the First to Comment

For almost exactly two months, from mid-November 2011 through mid-January 2012, I was on a Forced March, meaning lots of overtime and weekend work to get a software system up and running. It’s still not live—the sponsor switched from Date-Driven to Done-Driven and slipped the launch date six weeks, but not after I’d worked pretty hard.

These are sometimes called Death Marches, after Edward Yourdon’s book, in turn named after (I guess) the Bataan Death March. This was nowhere close. First, comparing anything that’s ever happened on a software project to the likes of Bataan shows a terrible lack of perspective. Second, even as software projects go, this was short and not at all harmful for someone in my circumstances of life. Third, “death march” implies at best a selfish motive, at worst a truly sinister one, and most likely just macho stupidity (read about Electronic Arts and judge for yourself). On the contrary, this Period Of Harder Work Than I Would Have Preferred had a worthwhile aim—get the new system live in time for year-end inventory and closing of the books. All the people involved were great to work with. I willingly signed up for it.

That’s the first “Lesson from a Forced March.” Sometimes a forced march is the right response to a threat or an opportunity. Wiktionary defines it as, “Soldiers, especially infantry, being made to move at a speed that would normally tire them excessively, to meet a military necessity.” Napoleon I was a master. Says historian Alistair Horne of the French redeployment from the English Channel to the Black Forest in the fall of 1805, “Napoleon moved with this great speed, 200,000 men marching 500 miles in 40 days…So there he has already defeated half the Austrian army.” Napoleon himself wrote of the surrender of 27,000 surrounded Austrians at Ulm, “I have accomplished my object. I have destroyed the Austrian army by simply marching.”

I’ve heard the phrase, “We have an aggressive timeline,” uttered at too many project kick-offs, for no reason other than a sponsor’s ego, or a misunderstanding of software development economics or programmer motivation. Forced marches, even the software kind, are risky. There needs to be a real possibility of a real reward.

If you can’t explain why finishing on that target date is decisively superior to finishing a week later or a month later, you have no reason to undertake a forced march.

But what if you don’t know a forced march will be required until after you’ve hit the trail? There are good reasons why that can happen, and then there’s the reason it happened to me—and the second Lesson from a Forced March.

Lesson #1: A valuable (read non-arbitrary) target date can make a Forced March worth the cost and risk.