Death Match Anyone?
by Mike VanHilstEd Yourdon gave Tuesday's keynote on Death-March Projects. Not coincidentally, this is also the topic of his new book. Yourdon defines a death-march project as a project for which the schedule, budget, staff or resources parameters exceed norms by at least fifty percent. a death-march project could also be defined as a project for which a reasonable risk assessment would put the chance of failure at greater than fifty percent. These are projects we have all seen, and, according to Yourdon, are now the norm.
The thesis of Yourdon's talk is that death-march projects are inevitable, and cannot be solved by improved methods and tools. Software practitioners need skills to survive them, and perhaps ultimately to avoid them. These skills include political and social skills, and in particular, skills for negotiating with management.
"Death-march projects are inevitable today and the next couple of years beyond," Yourdon told the assembled audience. "The interesting question for your company is whether you want to acknowledge it." In his talk, he sounded an optimistic note, "we want these projects to succeed," but also a warning. "But surviving them is more important."
There are many reasons that death-march projects occur. According to Yourdon, the common assumptions might be that either the technical staff is dumb or their managers are evil. On a more serious note, Yourdon presented a long list of possible reasons. At the top of the list was politics. When political concerns are allowed to dominate, death-march projects often result. Other reasons include, youthful naivete ("anything can be programmed over a weekend"), the "start-up mentality" which, according to Yourdon, is common in Silicon Valley, market or other outside pressures, and unexpected or unplanned crises. Yourdon jokingly referred to the year 2000 as an example of the last. "I mean, who ever would have expected it?"
For some companies, death-march projects are part of the corporate culture. "Indeed companies may consider them to be part of their corporate advantage." Such companies look for anti-social, "young, unmarried, workaholic, techno-nerds" to staff their projects. Yourdon mentioned EDS and Anderson Consulting as possible examples.
Team members should consider the chances for a project's success as well as for personal satisfaction and know what they are getting into when committing themselves to a project. When programmers find themselves caught in a death-march project, Yourdon often suggests that they quit. "My advice is usually to run. Run very fast. Run now."
Projects with at least some chance for both success and team happiness are called "mission impossible." The reference is to an old TV series in which the same team heroically performs seemingly impossible missions in each week's episode.
Yourdon argued that to survive mission impossible projects the most important thing project managers should acquire is negotiating techniques. Project managers must be able to play negotiating games on an equal footing with business managers. Yourdon also suggested using tools to bolster their position in negotiations. As examples he described tools to improve initial estimates, tools to model the impact of change, and using time boxing to calibrate schedules based on early progress.
Yourdon described things to do and things not to do in a death-march project. Things not to do include unilaterally dictating new tools, processes, or methods. He was especially critical of "tools with the aura of silver bullets," a category in which he includes recent Java development tools. He also mentioned processes that bury the developers in paper work, this time targeting ISO 9000. Reuse headed the list of things to do. "One of my strongest answers is reuse." But reuse must to be part of an ongoing process. "You can't introduce it at the beginning of a death-march project. It gives little or no benefit in the first project." But reuse wasn't the only thing. "The one I feel most strongly about is triage," Yourdon said. Triage is the process of setting priorities and cutting things out. "If you're stuck with a problem, you've got to do triage."
Throughout the talk, Yourdon stressed the importance of including all team members in key decisions. Managers must be open about the status and prospects for the project. Tools and processes should be chosen by consensus. Triage should also involve consensus. Yourdon was critical of American management styles. The social contract, by which companies reward and protect loyal employees, has been broken. Now, in times of crisis, good people leave. Business managers are evaluated on a short term basis.
Yourdon expanded on this point in a private discussion after the talk. Three to six months is too short for managers to depend on the outcome of a project. Apropos the year 2000 problem, many CIO's will have switched companies before 1999.