On Product Development and More...

I first heard the term Death March about 10 years ago. Our principal architect (Ross, one of the brightest engineers I have ever worked with) pulled me aside and said: "Just you watch, Doug. This project will become a Death March. And, it will be your job to guard the exits - preventing us from leaving until our daily toil is done".

Ed Yourdon (who originally coined the term) in his book of the same name, describes the Death March project as any whose "project parameters exceed the norm by at least 50 percent".

Ross’ definition was a bit simpler. He was referring to management's desperate attempt to "right the course" of this project by demanding the team work especially grueling hours.

Initially, his prediction did not phase me. After all, I had worked on difficult/challenging projects in the past. Several years prior, I was responsible for managing the development of Hewlett-Packard's low-end Intel-based server product. The term "fast-paced" did not begin to describe the intensity of developing bleeding edge commodity products and bringing them quickly to market (so as to out-maneuver the competition).

But, this project was somewhat different. Ross and a small team of engineers were revamping – no make that re-building from the ground up – the company's next generation location management product. The company’s software was sold to a very demanding set of Fortune 500 customers. Its customers would be unwilling to deploy the product until it achieved feature-by-feature equivalence of the company’s widely successful legacy location management software.

The company had decided to make an "all in" bet by hiring the best and brightest engineers with backgrounds from the top engineering schools and experience from the leading software companies of the day. It was a big money play. The stakes were high and the expectations were higher. The team was good. But the project objectives were unrealistic. And the team knew it.

In a paper entitled Surviving a Death March Product, Yourdon identifies several factors causing a Death March to occur. These include: politics, naïve commitments made by people not doing the work and naive optimism of youth. This project had them all.

Over several weeks, the situation began to worsen. If something was not done soon, team morale would suffer. I was nervous that the team would go into self-preservation mode and we would begin to have less transparent/fluent communications.

To address the problem (and ensure that the team could achieve success with a degree of certainty), we had to reset the unrealistic constraints.

Fortunately, I had a good relationship with the CEO and the rest of the executive management team (the other projects I was responsible for were running quite smoothly). Slowly, but surely, and with the backing/support of the project team, we were able to, reset the expectations of the executive management team. It didn’t happen all at once. We did this in baby steps – one at a time. We refined the target market for the first release product. We narrowed the requirements (to satisfy that refined target market). We relaxed some of the technical constraints. We defined a path to success. We were able to avoid the dreaded Death March. I am glad Ross providing the early warning. So, I could do something about it.