Subscribe to ...considered harmful        RSS Feed
***** 1 Votes

Death Marches Considered Harmful

Icon Leave Comment
Some Lessons Learned

He doesn't claim to have coined the phrase, but I first heard the term "death march" in the context of software development when I read Ed Yourdon's great book on the subject, and I consider it a magisterial treatment of the topic. Having read this book is now proving useful to me, because I find myself in such a project, and I have a conceptual model and some tools for addressing the situation.
So to begin with, I would like to call this book to the attention of students considering a career in software development, or those in the field. Although we now have some better methodologies for handling development projects (lumped under the heading of "agile") the basic problem remains, and it is not likely you will get through your time in the field without experiencing a project like this: the mistakes that lead to this situation are so easy to make and so much a part of human nature that any group of people can take this wrong turn and wind up in this morass.

So let's consider the "death march" for a moment. I should say at the outset that what I have to say here is really a footnote to Yourdon, and if it is at all interesting, then you should immediately find a copy of his book and read it carefully. It's a surprisingly enjoyable and optimistic read.

What is a "death march" project?

A death march is a project which, by means of various mistakes and apparently reasonable assumptions, goes off the rails and winds up stuck, behind deadline, and in bad trouble. The trouble manifests in a bug list that increases faster than the bug fixes can be made, in reduced functionality, in diminished performance, in blame and recimination, in mistrust, and often in the eventual failure of the project. At best, a death march project goes way over budget, over schedule, and hardly resembles the originally planned product.

How does a "death march" happen?

The biggest culprit, it seems to me, is the very optimism which leads human beings to dream big dreams and try to make them real. There is a paradox of sorts here: it is pretty obvious that without this optimism, no projects worth doing will ever get under way. However, if left unchecked this optimism drives us to proceed without taking necessary elements to ensure the eventual success of the project, and therefore leads to its failure.
More particularly, a death march is the result of a project which fails to observe certain realities of the development of software. These include:

  • Failure to specify requirements and goals
  • Willingness to expand requirements and goals without expanding schedule and budget
  • Failure to develop a reasonable schedule
  • Failure to account for reasonable risks
  • Willingness to overlook unknowns
  • Failure to provide adequate communication
  • Failure to keep written records of decisions made
  • Fragmentation of project documents

These mistakes are not made because people are stupid, or because they are ignorant, or because they are malicious. They occur because people allow themselves to be guided by considerations which should not affect their decisions about software, and they justify this by assuming the best of everyone involved in the project.

Let's walk through a death march as it happens - the highlight reel, as it were. Feel free to whistle the Colonel Bogie March as we walk along.

Step 1: The great idea. It might be a new product, or an enhancement to an existing business application, or a consolidation of existing systems. In order to become a death march, it need only be a big and exciting project which brings in a large team of people, including associates not familiar with the process of software development. These will generally be necessary parties, stakeholders in the project and management staff whose function is, in principle, to facilitate the project. The side effect of this is to bring in an abundance of enthusiasm untempered by experience.
This is not to let the development side off the hook. Developers are often smart people, and like many smart people they can easily fall into the trap of assuming that their smartness allows them to defy gravity. Schedules, can be pretty loose. We're pretty good at estimating, it's not necessary to break down the steps into sub-steps and pry into our assumptions. That feature is cake, I'll bang it out in a week. And in addition, we are charged with the enthusiasm of the new project. It's going to be great - we want to get down to it, while we're high on the adrenaline. Planning is just a bother, scheduling is just time lost when we could be writing code.
After all, it's going to take us just as long to write the code whether we've scheduled it or not, right?

(Well, no: it takes a lot longer if you don't schedule it properly. I might not get to that in this entry, though.)

Step two: The honeymoon. The early stages of a project are where you get the best gains for the least effort. Going from nothing to something is the easy part. In this part of the project, the main danger is that a stakeholder, in a fit of enthusiasm, suggests some enhancements. This is only matched by the danger that the developers, in a deadly lack of pessimism, fail to reject those enhancements. This does not always happen, and it is not necessary to ensure a death march, but it is often a key factor. The project has just grown in scope, but its deadlines and budget are unmoved. At this point, because there is no schedule worth speaking of, there is no effort made to accurately estimate the added cost in time imposed by this change. Now there's a bomb in the schedule, and it won't go off for a while. But it will.

Step three: The slog begins. After a while, the excitement starts to wear off, and it begins to feel like work. At this point, the project starts to suffer from the sins of its origin. The lack of a real schedule, with real milestones, shows in a lack of regular motivation. The best motivator for a creative person is a sense of accomplishment, and if the only accomplishment we're going to see is six months or a year down the line, it starts to get a little tough. Especially since this is when we start to get an inkling that the deadline might not be the end of things. Not that anyone says anything about that at this stage, of course, but the chinks in the plan often start to let in water around this time. A "reasonable risk" comes around: one of the key members of the project is called away on jury duty. This is grand jury service: one day a week for six months. (Can't happen? Happening right now: I can't reach a key stakeholder to resolve an issue if it comes up on a Tuesday, and when he gets back in on Wednesday it takes him until Thursday to clear out his inbox. I get my answer on Friday - if I'm very lucky, I can get this issue resolved in three days, and it's clogging up the works until then.) That was a predictable risk, which we did not allow for. One of our developers had a wedding scheduled for this summer, and a honeymoon to follow. This was planned for. What was not planned for was the fire at her condo two months before the wedding, but something of that sort should have been anticipated. In any group of people big enough to make something interesting happen, over a period of time sufficient to make something worthwhile happen, you must anticipate that some sort of major disruptions will occur. Either you budget for this, and allow for some wiggle room, or you do not, but the odds say it will happen.

Step four: Things fall apart. The little things begin to build up. Friction in the gears. One slip bumps against a weak support and a corner comes down. A schedule slip pushes a planned light week back by a week. This means that one developer is on her honeymoon while heavy lifting is being done and returns to a project in disrepair and nothing to be done for a week.
Morale begins to fray. Mis-communication starts to seem essential. Personal failings become subjects of discussion. Venting begins to seem catty. More time is lost in attempting to recover the lost collegiality. And the unfixed bugs and unimplemented features begin to stand out as we come closer to a real milestone...

Step five: An undeniable failure. The first real deadline goes past, with no hint of a hope of meeting it. Emergency meetings are held. Very likely, a shift in management occurs as Those Above begin to take notice of the colossal mess that has developed while their attention was elsewhere. It is possible, but not likely, that these changes will be something other than disaster. But since these changes are made in the absence of any real data (this is how we got here) or understanding of the situation (very few senior managers have also worked on development projects) and are based almost purely on wishful thinking ("I want this project to be completed...") and unsupported assumptions ("... and if I give it two more months, it will be") it seems hardly credible that they will result in the desired outcomes.

Step six: Limping to the finish line... or falling into the ditch. This chronology could go on for quite a while more, but nothing very new would be added. More of the same, with elaborations and variations. Eventually, we either drag ourselves to an ending and call it success, or the project is abandoned. How do we know which we'll get to?
We don't. Nobody knows at this point. This is probably not a question with a straightforward answer.

So: a death march. I don't know where this story ends, because it's ongoing. It's not pleasant. I'm working stupid hours, fighting against all sorts of friction, and much of my effort is lost to the churn and chaos. Probably I seem hopeless and inefficient to my colleagues, and I have to make an effort to remember that they are all actually very smart and capable people, and not the ineffectual fools they seem on the bad days.

I'd hoped to go into a little more depth on the nature of the failures, and their reciprocal "best practices". It seems like it might be useful to unpack some of the chains of disintegration in detail. Perhaps I'll return to this topic. another time, if there's any interest.

0 Comments On This Entry


Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

May 2022

151617 18 192021


    Recent Entries

    Recent Comments

    Search My Blog

    9 user(s) viewing

    9 Guests
    0 member(s)
    0 anonymous member(s)