This article includes a list of general references, but it lacks sufficient corresponding inline citations. (August 2018) |
In project management, a death march is a project which participants believe to be destined for failure, or that requires a stretch of unsustainable overwork. The project "marches to its death" as its members are forced by their superiors to continue the project, against their better judgment. The term originated in the field of software development, and has since spread to other fields.
Death marches are usually a result of unrealistic or overly optimistic expectations in scheduling or feature scope, and often result from a lack of appropriate documentation, relevant training, or outside expertise needed to complete the project. Death marches can also be triggered by misunderstandings between parties, unresolved assumptions, mismatched expectations, and sometimes external change. Management may desperately attempt to right the course of the project by asking team members to work especially grueling hours (14-hour days or 7-day weeks) or by attempting to "throw (enough) bodies at the problem", often causing burnout.
The discomfort is heightened by project participants' knowledge that the failure is avoidable. It may have succeeded with competent management, such as by devoting the obviously required resources, including bringing all relevant expertise, technology, or applied science to the task, rather than just whatever incomplete knowledge a few employees happened to possess. Business culture pressures may play a role in addition to mere incompetence.
The term "death march" is discussed at length in Edward Yourdon's book Death March.[1] Yourdon's definition: "Quite simply, a death march project is one whose 'project parameters' exceed the norm by at least 50 percent."[2]