Skip to content

The Root Cause of the Death March

When I ask the question “has anyone heard of a Death March” at developer conferences and meetups, I’m always surprised that the overwhelming majority raise their hands immediately. It’s as if they’ve all experienced this pain for themselves and are looking for a sympathetic ear. 

As I’ve posted previously Wikipedia.org defines a “Death March” as “a project which participants believe to be destined for failure, or that requires a stretch of unsustainable overwork.” From my experience, this seems like a reasonable way to describe a Death March. 

What Makes a Project Destined for Failure

Sometimes a Death March is a project trending towards failure because the code is not ready. The code may be full of bugs, built on a sketchy design, using poorly chosen technologies and/or frameworks. Yet, the deadline is fixed and looming.

Other times, the management-dictated deadline is simply not realistic. The team members are asked to put in an absurd amount of overtime in an attempt to “get it done on time.” The term “code like hell” comes to mind in these situations. Typically coding like hell doesn’t cut it. Instead, emotions soar as the approaching deadline causes morale to sink to an all-time low for everyone involved.

Why Does This Happen?

In all cases I’ve experienced, the Death March is always born, unintentionally, by a series of management decisions. These choices are based on good intentions to achieve some major milestone by a particular date, that either saves money, or makes money. The date chosen is also significant; it may align with the start of a quarter, precede a major marketing/sales event, or be before an IPO, merger, or acquisition.

Note, management is not selecting the deadline based on analysis of the scope of work, driven by estimates, aligned on a Gantt chart accounting for all dependencies, and buffered to ensure the date is achievable. That is how we avoid a Death March…more on that later. 

The Root Cause of a Death March 

This may come as a massive surprise, but the reality is, these Death Marches that are so painful for the dev teams involved are ultimately and completely our fault. 

I know this sounds harsh & ridiculous and you’re tempted to stop reading, but please let me explain. Management selects a date, seemingly out of thin air, for one very basic reason. They don’t trust the dev teams to hit any date we pick or the date we pick exceeds some threshold of acceptability.

Management doesn’t trust us because we have repeatedly demonstrated we cannot hit our deadlines. Now to be fair, when we miss deadlines, it is often due to changing/inadequate requirements. It may be some 3rd party dependency that was introduced/delayed or some bad data that was not as expected (to name a few).

The excuses are many and vast and yet regardless of all of these, it is still our fault.

 How We Take Back Control

The good news is that we are responsible for causing our own Death Marches. That means we are also in control of avoiding them. Once we can consistently and repeatedly hit the deadlines that we presented to management, they will stop picking dates for us.

Instead, they will come to us asking “when can it be done?” The trick here is to never miss another deadline. Sounds too simple right? How can we never miss a deadline when there are so many things outside of our control? We can’t control the scope of work, requirements, 3rd party dependencies, other project priorities, etc?

 Achieving What Seems Impossible

Just to be very clear, completing back-to-back projects on schedule with high-quality is not only possible, but it should actually be the norm. 

We must understand that we cannot obtain this level of achievement without taking control of planning our software construction process. We take a proactive approach and craft a plan to build our architecture. Then we must track our progress consistently every week while trending forward to see if we are still on track toward completion. 

When we become off-course, we compensate by changing activities, adjusting resource assignments, and modifying dependencies until we are back on schedule. This course correction is repeated until the deadline is achieved without sacrificing quality.

A Magic Trick We Do Every Day, But Not in Our Software Projects

There’s one key technique that helps us be on time in everyday life that we completely avoid in our software projects. When we have an important appointment to get to, we use this technique every time.

Take for example you are taking a trip by plane. Let’s say your flight leaves at 7:00 am and you live a 30-minute drive away from the airport. Would you dare leave your house at 6:30 am? No, of course not. You would leave the home at 5:00 or 5:30 to account for traffic, luggage check-in, security checkpoint, the onboarding process, a bathroom break, maybe a coffee shop stop, etc., right? 

Why don’t we do this with our software projects? We know that we have changing scope/requirements, 3rd party dependencies, and other project priorities requiring our time. Why not accommodate all of these with just a little bit of “slack time” planned intentionally as we do with every important appointment? 

This “trick” seems so obvious when planning to make it “on time” for a plane flight. Why not take the exact same approach and apply it to our software projects?

We can establish a network of activities required to complete our software development most efficiently by aligning the sequence of development by our architecture dependencies, then by our human resource dependencies.

Interjecting a little bit of “slack time” in key places in that plan enables a few of these activities to slip without impacting the final release date. Combine this “trick” with tracking your progress and implementing course correction to complete all our software projects on schedule. 

Never Death March Again

Mastering these design and planning ideas will set you and your team apart as industry leaders. Just like learning any specialized skill, these ideas require practice to master. They also need guidance from an experienced architect and engineer. The good news is that you now know it is possible. Now all you have to do is let me be your guide. I’ll show you how to eliminate the Death March and enjoy the success you deserve.