6 March 2003

by Michael Mah, Senior Consultant, Cutter Consortium

In the mid- to late 1990s, time pressure on software projects accelerated dramatically under the “Internet speed” mantra. It seemed that our industry was hell-bent on bending reality with regard to time, and chants to “build it faster” were the norm.

With the current economic slowdown, the other shoe has dropped and then some. Now, not only are teams facing impossible deadlines, but they also have to make their dates under incredible cost and resource constraints. When managers are asked if time pressures have relaxed in recent times, the answer is a resounding “no.” Not only is there no schedule relief, but many projects are also working with teams that are significantly understaffed. What we have here is a breeding ground for project conflict.

At a recent speech on agile development, Cutter Business Technology Council Fellow Ed Yourdon predicted a rise in “death march” projects — those with unrealistic scope and no hope of meeting impossible deadlines and budgets.

What is an overstressed manager to do? In a recent study of estimation practices by Cutter Consortium, adding staff resources or extending deadlines showed up at the bottom of the list as a response to project conflict, according to Cutter Consortium Senior Consultant E.M. Bennatan. But 24% replied with the archaic response of “Working harder — without changing scope, budget, or team size.” It should come as no surprise that the next Cutter study focused on the IT burnout phenomena.

The largest group, at 36%, replied that they employ an iterative release approach to their projects, deploying a limited version early, followed by a feature-rich version later. Another 12% said that they reduce scope outright. Thus, 48% of the time, the response is to scale back or time-box the functionality into a predetermined schedule.

This approach to resolving project conflict is what I call “deadline- driven estimation.” That is, rather than having a set of requirements first (project scope), then coming up with an estimated schedule, proposed staffing, and budget, we’re faced with the deadline first, a fixed number of available staff (the two constraints), and having to come up with an estimate of functionality. This difficult choice is what winds up on the negotiating table among stakeholders made up of management, users, marketing, and developers.

What makes this choice difficult from a negotiation perspective is that the demand for functionality flies directly in the face of deferring some of the functionality. Clashes over functionality occur when marketing and end users are in direct opposition to development engineers on what is deemed possible by an underfunded team within the time constraints. So the basic conflict hasn’t really gone away — it’s simply shifted to a different space — from deadlines and budget, to scope and functionality within a predetermined deadline.

Here’s where managing stakeholder conflict becomes tricky, because we actually have to deal with two concurrent issues. The first is the substantive issue of project estimation and various time, cost, scope (and don’t forget quality) tradeoffs. This is a multiparameter problem that gut feel won’t solve. Software project tradeoffs are nonlinear — simple changes in one dimension result in geometric effects in another. (An example of this is the dramatic rise in defects as schedule is compressed.) Last time I checked, I couldn’t solve these types of complex problems in my head. You need a reliable estimation model to predict these scenarios. Yet nearly 50% of respondents in a recent Cutter survey replied that the predominant method of estimation is by gut feel — they do it in their heads, or at least they attempt to.

The second issue is that of conflict management and negotiation itself. It’s one thing to haggle over something like the price of a car in a basic two-party negotiation. Many people find even that difficult. But resolving differences is entirely another matter with multiple stakeholders (management, users, developers, marketing), especially when those stakeholders are groups of people. These kinds of conflicts are more akin to consensus building in the UN. When you throw in the issue of time pressure, it becomes even more difficult. People do strange things when under time pressure.

The solution is for organizations to get innovative by employing better practices in these two disciplines — software project estimation and multiparty negotiation. These are not areas in which most folks have had much formal training, but when skillful techniques are thoughtfully applied, frequent failure can be turned into certain success.

— Michael Mah, Senior Consultant, Cutter Consortium

© 2003 Cutter Consortium. All rights reserved.