Incorrect methods, use of wrong software tools and faulty project management techniques are the obvious reasons that result in Death March Projects, says Dr R Srinivasan

While discussing the success of software development in his book 'Death March', Edward Yourdon, the software guru, recapitulates his experience as follows:

"Having worked in the software industry for over thirty years, I find that our profession has a rather interesting reaction to Death March Project. In some parts of the industry, especially in Silicon Valley, such projects are glorified as a test of fortitude, somewhat akin to climbing Mount Everest barefoot". He continues to say that according to software consultants and methodologists, the reason for ending up with such projects are the deployment of wrong methods (sometimes no methods at all) or the use of wrong software tools, or following wrong project management techniques. For the benefit of those who are not aware of what a Death March Project parameters exceed the norm at least by 50 present.

We have seen some of the vital project parameters in our earlier articles. In addition to these, according to Yourdon there may be problems in completing a software project successfully due to some constraints dictated by the higher level management in an organization. We know that, as part of the project plan, two important aspects are Schedule Estimation and effort to complete the project with milestones and the human resources required to meet this schedule. However under the present scenario of business competition, time to market is very vital and so some software development organizations may be forced to compress the time schedule; in some cases even to less than half of what has been estimated under the project plan. Yourdon points out that this is the most common form of Death March Project.

The second type of constraint may happen because of too much belief and dependence on tools. The management may try to reduce the number of people estimated earlier under the misconstrued confidences that by deploying tools the productivity of the people will increase. This may backfire if the project team does not have enough exposure and training on this new technology. In rare cases the team probably might not have been consulted about the use of technology in the first place. The third constraint may be due to the budget connected with the human resources. It may so happen that to meet the effort estimation, the organization may resort to the mix and march of experienced and fresh people in the project; but if the freshers are more success of the project to meet the milestones and deadlines will run into problems. However today the customers who download the projects would like to have a look at the expertise of the proposed project team before project execution is approved.

Frederick brooks in his book 'Mythical Manmonth', points out a different problem under the topic, "Regenerative Schedule Disaster", adding manpower to a late software project makes it later. The fourth constraint to be looked into is the one that would happen due to an over-enthusiastic group or organisation. In order to impress upon the customer, with a view to getting more business in the future, the group may resort to implementing functionalities, features and performance requirements to a much higher level than was agreed upon as part of the project plan, leading to unnecessary and unexpected delays in project execution and completion. No customer will tolerate the-delay even though the group tries to convince him that he will ultimately get a product of higher performance and having many features beyond what he had planned.

What would be the result of imparting such constraints? The answer is that the project team will be forced to work twice as hard, and/or work twice as many hours per week as would be expected in the normal course. To Quote Yourdon, "Naturally the tension and pressure escalate in such environments so that the Death March team operates as if it is on a steady diet of Jolt Cola"!!.

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)