Is your project a Death March?

Death March projects are those projects that everybody has heard about where everyone on the team knows the project is pointless yet all the team members persist despite the feeling of impending doom.

The team may make attempts to correct the problem but are usually thwarted in their efforts to change. Death March projects persist for many reasons, to appease the instigators, contractual, economic, political etc but the delivery team can predict the outcome, often even at project kick-off meetings!

My first Death March was in 1992 (ouch) I was a C++ geek on a project looking for a purpose. It was the brainchild of the company Business Leader and had nothing to do with the companies core business. All the bad signs were there from the start, we had a free reign with the technology, but our usual customers didn’t know what we are working on or why – they were bankers, the product was not a banking system. From our normal customers point of view they had half of the developers in the IT department pulled from their normal duties, sent off on a program of training and were never seen again for the next 12 months – some of us they never saw again.

What we’d now call the Business Customer wasn’t interested in how his “pet dev team” were creating his “thing” nor did he give us much of a clue about it’s content. I think I saw him twice in his two year tenure with the company, although he did give his son a job in our team. There was clearly no purpose to the project, it wasn’t part of the Business Strategy and it was costing the business a huge amount of money at a challenging time for the finance sector, there was no visible customer, and nobody apart from our immediate Project Manager seemed to care about what we did on a daily basis. So why did we carry on for over 12 months?

Why didn’t someone in the team speak out?

Why didn’t the other board members or senior managers ask what was going on? We were all on the same site so there was no excuse for poor communication. We were spending huge amounts of money, we even got a Texan OO guru over – Putnam Texel (what a brilliant name) and paid her travel expenses and accommodation.  I did loads of training, anything I fancied, learned loads of stuff played esoteric academic exercises in C++, read Grady Booch, Ivar Jacobson – “Hey I just learned use cases let’s try that!” Ed Yourdon, Pete Coad and many others.

So I guess I stuck with this Death March as long as I could because it was my job and I was being told to. In my inexperience I didn’t challenge that assertion from the people who paid me and so I tried to make the best of a bad situation by increasing my technical skills so I could actually help, but ultimately the futility of the project bore down on me and I couldn’t take it any more, I started looking in Computer Weekly (remember that anyone!) at the jobs market and I jumped to a shiny new job with a Systems Integrator  – my Second Death March started the following Monday morning!

But what about the other team members, my mates, we’d worked together for about 5 years, we socialised and laughed and did stuff together. Well every single one of them either left the company or bailed from the project and then left the company, I can’t remember the exact figures but I’m sure over 50% of the team directly exited the company.

We didn’t object during the Death March because we thought somebody else knew better than us, surely the IT managers knew what was going on, surely the senior management team was concerned about the lack of governance and wanted to know what was really happening. It wasn’t our responsibility to question, it wasn’t our problem, and even if we said anything nobody listened or could do anything anyway. And if we kept our heads down nobody would notice. Some of my colleagues tried to escalate the problem, but there was a fear that it would expose us and they’d kill our project, we all had mortgages, some had kids, I had a car fetish.

My colleagues and I tried to apply some of the things we were learning to fix the problem, my motivation to acquire knowledge wasn’t just for the sake of it, all of us were absorbing any new idea that the industry was generating and we tried most of those ideas to address our problems, OO Analysis and Design to fix our product problems, Use Cases to try and fix the requirements problem, we used OO techniques to help with testing our components, this was all new stuff to us back then.

But none of it ultimately changed a thing, there was no tangible improvement because the whole thing was wrong from the outset, and we’d known it all along.

 How do you identify an impending Death March?

• Project requirements are flaky,
• Technology is misunderstood or inappropriate
• Team is incorrectly or under resourced
• Sales team sold a product that can’t possibly be delivered in time,
• The customer isn’t, can’t or won’t engage with the team.

A combination of the above list, and other contributory factors create a feeling of nervousness and anxiety, doom even, but nobody publicly challenges the situation.

 Why didn’t anything we did change things?

A complex combination of communication difficulties, a culture that discouraged negative reporting, the team’s fear of exposure, management’s lack of understanding of the teams problems, and our management’s own fear of questioning the objectives of a project which was so misaligned to the company’s strategic goals.

What would I do now?

 “STOP!, escalate, protest, or even abandon ship!”

 This may seem to be a high-risk approach but your actions could save the organization. It is difficult in such circumstances especially when one has financial and family commitments to put one’s head above the parapet and speak out.

Ultimately you need to ask the question

“Do I wish to work for a dysfunctional organization that cannot align its workbook with a valid strategy?”

If the answer to this is No, then your choice is either to change the organization or leave it; by trying to effect a change at least you’ll have done the right thing. Consider the future of organisations that fail to deliver to a valid strategy, ultimately their fate is sealed by their customers or shareholders.

What should you do if you’re in, or about to start, a Death March?

Check-out Holistic Software Engineering we’ve developed HSE to prevent your Death Marches.

---

My thanks to Ed Yourdon for his 1997 book “Death March” that resonated so strongly with me, thanks also to all of my colleagues especially if any of you recognize “the project”.

Holistic Software Engineering is co-developed with Mike MacDonagh, Technical Director – Holistic Software Consulting Ltd