Javalobby

Mr. Mahal has worked his way through all aspects of software development. He started as a software engineer and learned how to design and architect software systems in different industries. He has been a director of engineering, product management, and professional services; mid-career he worked for a company dedicated to training engineers in collecting requirements and understanding OO and conducted research into why software projects fail; and before starting Accelerated Development he rescued a technology startup in Vancouver as their COO. Accelerated Development is dedicated to the production of high quality software through implementing light weight engineering practices for all size organizations up to Fortune 500. Dalip is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

Death March Calculus

02.08.2013
| 1756 views |
  • submit to reddit

We Recommend These Resources

NOSQL for the Enterprise

In the previous post Stop It! No… really stop it. we talked about 5 worst practices and their impact on a software project.  However, all 5 worst practices will be present in a Death March.

Ed Yourdon, one of the pioneers in software engineering, wrote "Death March" to describe the common practice of setting up a software project which is not feasible.

That is, between the time, resources, and functionality (quality) desired for the project, there is no way to complete the project successfully.   Ed states that a death march is one in which one of the project parameters exceeds the norm by at least 50%.

A death march project is often known by the entire project team to be virtually impossible to succeed at.  To understand some of the motivation of why senior management creates death marches or why people participate in them you would need to read Ed's book.


In the previous article we showed this table:

Worst Practice Productivity Quality
Friction/antagonism among team members -12.0% -15.0%
Friction/antagonism among management -13.5% -18.5%
Inadequate communications with stakeholders -13.5% -18.5%
Layoffs/loss of key personnel -15.7% -21.7%
Excessive schedule pressure -16.0% -22.5%

Since senior management has asked for specific functionality that can not be produced by the current team in the given time frame, the first problem is the presence of excessive schedule pressure.  So right at the start of the project your productivity will be down 16% and quality will be down 22.5%.

With a compressed time schedule there will not be enough time to capture all the requirements from the stakeholders.  You will have to settle for partial requirements and hope to interpolate the missing requirements.  This will cause inadequate communications with stakeholders and drop the productivity 13.5% and the quality by 18.5%.  Unfortunately, these effects are cumulative with the excessive schedule pressure and you will now be down 29.5% productivity and 41% on quality.

There is no shortage of opinions in a software team; in the best teams they combine their opinions to make the best decisions.  When time is compressed we don't make good decisions in our teams and end up with friction at the management and team level. This will cause us to have friction/antagonism among management because they will have different opinions on how to execute the death march;  antagonism in management will lead to friction/antagonism among team members. These two issues will combine to drop productivity by 27% and quality by 37%.  The cumulative effect of all practices will have productivity down 64.5% and quality down by 78%.
When the project is obviously not going well, people will quit and/or be fired.  In particular, key personnel have a tendency to leave because they are the ones that have the easiest time finding new employment. If this happens then the final numbers will be productivity down 86.2% and quality down by 98.7%.

If you don't believe the numbers then you have never been on a death march!
The problem is that excessive schedule pressure will inevitably cause the other worst practices to come into existence.  Starting a project where excessive schedule pressure is present is virtually a guarantee that failure will occur.  In fact, the only death marches that have a chance at success are small teams with projects that are 3-6 months long.

Possible Way Out

The only way to solve the problem of excessive schedule pressure is to balance the three elements (time, resources, and functionality) of the project until you have a feasible project.  Since project teams are relatively fixed this means:
  • reducing the functionality that needs to be produced
  • moving back the project end date
  • both reducing functionality and moving back the project end date
Experienced project managers on a death march will be aggressively reducing scope as soon as the project starts.  But this is no guarantee that they will get rid of enough functionality to bring the project into a feasible state.

If your organization has put you on a death march then the only possible solution is to find another job.  Hoping that somehow a successful project will result when you start off with excessive schedule pressure is futile, the mathematics shows that project failure is a virtual certainty.
You have more chances of winning big in the lottery and retiring than of completing a death march successfully.
Published at DZone with permission of Dalip Mahal, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

"Starting from scratch" is seductive but disease ridden
-Pithy Advice for Programmers