Marching to death

 Ever been in a project death march? Perhaps you are in one now. There are many definitions of such projects. It basically comes down to having far too much to do in far too little time, so you are asked to work long hours for a long time to make up the difference. Death marches get their name from their length, effort, and the toll they take on the participants. (I apologize for how insulting this is to those whose relatives experienced actual death marches in WWII; but unfortunately, software is full of insensitive word usage.)

It’s hard to fathom why groups continue to employ death marches, given that they are almost certain to fail, sometimes spectacularly. After all, by definition you are marching to death. The allure escapes me.

Stabs in the dark

Inept management continues to engage in death marches, so I’ll take a few stabs at explaining why.

Eric Aside Death marches are hardly unique to Microsoft, nor are they pervasive at Microsoft, a fact I learned much to my surprise when I joined the company. Microsoft’s reputation for long hours preceded it when I joined the company in 1995. I was concerned because I had a two-year-old boy and another child in the works, but my boss assured me that death marches were not the rule. His word was true, yet there are isolated instances when management at Microsoft and other companies still resort to this inane and arcane practice.

• Management is remarkably stupid. Managers choose to act without thinking about the consequences. They take a simpleton’s approach: Too much work to do? Work harder. At least managers can say they’re doing something, even if it is probably wrong.
• Management is incredibly naive. Managers don’t know that a death march is doomed to fail. Somehow they were either asleep for the last 25 years or never read a book, article, or Web site. They assume that adding at least four hours a day and two days a week will double productivity. The math works out—unfortunately, humans aren’t linear.
• Management is tragically foolish. Managers think that their team will be the one to overcome the insurmountable odds. Rules and records were meant to be broken. They’ve got the best team in the world, and their team will rise to the challenge. Apparently, they see no difference between outrunning a bull (hard) and outrunning a bullet (impossible).
• Management is unconscionably irresponsible. Managers know that a death march will fail, destroying their team in the process; but they do it anyway in an effort to be worshiped as heroes. Managers reward this behavior with free meals, gold stars, and high ratings, knowing that our customers and partners won’t be screwed by the garbage we deliver until after the next review period. I think these managers are the most deserving of a verbal pummeling by Steve’s staff.

Eric Aside Steve refers to Steve Ballmer, our beloved Chief Executive Officer, who is a strong advocate for work-life balance and practices it himself. I’ve met him several times while he was cheering on his son at a basketball game or going out to a movie with his wife.

• Management is unaccountably spineless. Managers know that the death march is doomed, but they lack the courage to say “no.” Because they won’t be held responsible if they follow the herd, there is little consequence for these cowards. Sure, the project will fail and their employees will hate them and leave, but at least they’ll have war stories to share with their gutless, pathetic pals.

Many people have written about the ineffectiveness of software project death marches, but somehow the practice continues. I can’t reason with the foolish and irresponsible, but I can enlighten the stupid and naïve and give alternatives to the spineless.

A litany of failure

Some enlightenment for the ignorant: Death marches fail because they…

• Are set up for failure. By definition you have far too much to do in far too little time. Of course you fail.
• Encourage people to take shortcuts. Nothing could be more natural than to find cheap ways to leave out work when you are under pressure. Unfortunately, shortcuts lower quality and add risk. That may be okay for small items and short time periods. But those risks and poor quality bite you when the project drags on.
• Don’t give you time to think. Projects need slack time to be effective. People need time to think, read, and discuss. Without that time, only your first guess is applied. First guesses are often wrong, causing poor design, planning, and quality, and leading to dramatic rework or catastrophic defects later.
• Don’t give you time to communicate. You could make a good argument that miscommunication and misunderstanding are at the root of all evil. Even good projects commonly fail because of poor communication. When people don’t have spare time and work long hours, they communicate less and with less effectiveness. The level of miscommunication becomes an insurmountable obstacle.
• Create tension, stress, and dysfunction. Congeniality is the first to go when the pressure is on. Issues become personal. Accidents get amplified and misconstrued. Voices get raised, or even worse, people stop talking.
• Demoralize and decimate the workforce. All the bitterness, all the tension, and all the long hours away from family and friends take their tolls on the psyche and relationships. When the project inevitably fails to meet its dates and quality goals, people often snap. If you’re lucky, it just means switching groups at the end of the project. If you’re unlucky, it means leaving the company, divorce, health issues, or even life-threatening addictions.

By the way, managers often confuse the long hours some employees ordinarily put in with death marches. Death marches are an entirely different dynamic. The difference is that a death march forces you to put in those hours. When people voluntarily put in long hours, it’s often because they love it. Such hours are full of slack time. There isn’t any tension or cause for taking shortcuts.

Eric Aside This is a critical point people often miss. Voluntary long hours are completely different from death marches.

• Undermine confidence in the process. It doesn’t take a genius to realize that death marches are a response to something going wrong. The message this sends to our employees, customers, and partners isn’t dedication, it’s incompetence. Avoiding the real issues and just working harder only undermine our corporate standing further.
• Don’t solve the problem. Working longer hours doesn’t solve the underlying problem that caused the project team to have far too much to do in far too little time. Until the underlying problem is solved, no one should expect the project to do anything but get worse.
• Reduce your options. When you’ve taken shortcuts, introduced poor designs and plans, created dramatic rework and defects, randomized your messaging, encouraged people to slit each other’s throats, demoralized the staff, undermined confidence in our ability to deliver, and still failed to hit dates and quality goals—leaving all the original issues unresolved—you have few options left. Usually this leads to dropping the quality bar, slipping the schedule, and continuing the death march. Nice job.

The turning point

So, if you find yourself with far too much to do in far too little time, what should you do? On a practical level, the answer is remarkably easy. Figure out why you’ve got far too much to do and far too little time to do it.

The answer isn’t, “Because those are the dates and requirements from management.” Why are those the dates and requirements from management? What would management do if you didn’t hit certain dates or certain requirements? Would they slip the schedule? How much? Would they cut? Which features? Are there more fundamental changes you could make in the process or approach that would alter the dynamic? Tell management that your goal is to hit the dates and requirements, but you have to plan for the worst case.

Then plan for the worst case. Build a plan that hits the worst acceptable dates with the least acceptable features. If you are still left with too much to do for the available time, raise the general alarm. Your project is dead in the water. If the worst-case plan is perfectly achievable, focus all your efforts on achieving it. Message to your employees that doing more means a review score of 3.5+, but doing less means a score below a 3.0.

Eric Aside The numbers refer to the old Microsoft rating system, which ranged from 2.5 to 4.5 (the higher the rating, the better the rewards). While a 3.0 was acceptable, most people pursued and received a 3.5 or higher.

The road less traveled

What you’ve done is escaped from the death march and created slack time to improve. Your team will likely go far beyond the minimum, but they will do so without taking shortcuts, making poor decisions, or engaging in cannibalism. You will deliver what’s needed on time and build confidence with your partners and customers.

As reasonable as this sounds, it is hard to do on an emotional level. Planning for the worst case feels like giving up. It feels weak and cowardly—like you can’t handle a challenge. How ironic; in actuality, it is entirely the opposite.

Not facing the crisis is weak and cowardly. Pretending the worst won’t happen is deceitful and irresponsible. Show some guts. Face the facts. Be smart and save your partners, customers, and employees from the anguish at the end of the road. Come out on the other side with value delivered and with your team, your life, and your pride intact.

Eric Aside On a recent nine-month project, my team had a critical service dependency take a three-month slip toward the end of the project. My team went from having four months to complete a major feature to one month. We could not slip the schedule, and we could not cut the feature (both were already committed to partners). We didn’t go through a death march. Instead, we moved into our dependency’s development environment and worked in parallel as they completed their service. This strategy not only recovered time but also reduced rework since we were able to give feedback to the service team on very early builds. We shipped on time with great customer reviews. It was difficult and people did work hard, but they also took time off and were pressured only by the desire to ship a high-quality product and support their teammates. We retained everyone after release.