Software development initiative often fail because the organization sets unrealistic goals for the "iron triangle" of software development:
The development team has failed at renegotiating the situation, and is forced to try to deliver under those constraints anyway. In the end, if the team delivers at all, the quality of the delivered product suffers and the iniitiative is almost always late and over budget anyway. To be effective, project managers must understand the implications of the iron triangle.
Figure 1. The Iron Triangle.
Note that refusing to recognize the implications of the iron triangle isn't the only cause of failure, it just seems that it's one of management's more popular approaches to hamstringing an IT team. In many ways, we really need to question the ethics of "fixed-price" IT projects.
The fundamental problem is that each major group of stakeholders has a different, and often conflicting, set of priorities. IT professionals lean towards building high-quality systems, financial people seem more interested in the overall cost, senior management in the schedule, and end users in the scope. Although these are clearly stereotypes we've all been in situations where someone was overly focused on "their issues" to the exclusion of others. The problem is that when each issue has its own protagonist(s) it becomes difficult to negotiate a reasonable approach to software development. When nobody budges from their position, or is forced to budge, the team is positioned for failure.
By breaking the iron triangle, you often:
Recognize that the iron triangle must be respected. The iron triangle refers to the concept that of the three critical factors - scope, cost, and time - at least one must vary otherwise the quality of the work suffers. Nobody wants a poor quality system, otherwise why build it? Therefore the implication is that at least one of the three vertexes must be allowed to vary. The problem is that when you try to define the exact level of quality, the exact cost, the exact schedule, and the exact scope to be delivered you virtually guarantee failure because there is no room for a team to maneuver.
The solution is for everyone to be aware of this fundamental concept and work accordingly. Instead of thinking of it as an "iron triangle" you are much better to think of it as an "elastic triangle" and vary the cost, schedule, and/or scope as required. Yes, this may upset the bureaucrats within your organization that operate under the misguided assumption that we can think and plan everything through early in the lifecycle, but isn't that better than causing an IT project to fail?
It is critical to understand how flexible you are with respect to each vertex. Perhaps your resources are limited due to financial cutbacks but you're willing to develop less functionality as the result of lower expectations due to the cutback. Perhaps the schedule is critical because you have a legislated deadline (e.g. for Sarbox or Basel-2) to meet, and due to the potential repercussions senior management is willing to spend whatever it takes to get the job done. Once you understand your situation, you can choose one of the following strategies for elasticizing the iron triangle:
To define the scope up front you can set the requirements by taking a serial approach to development where you fully define the requirements and baseline them early in the initiative. Once you've baselined the requirements the next step is to choose to vary either cost or schedule - if you want to deliver quickly then you'll need to spend more money, often on highly skilled consultants and better development tools, or if you want to maximize value you may choose to stretch out your schedule instead. You just can't do both without harming overall quality. A big requirements up front (BRUF) is an incredibly risky approach because it's very difficult to actually define requirements well, the requirements change, or your stakeholder's understanding of the requirements changes. Either way, you desperately want to be able to react to these changed requirements. You might build a system that fulfills its specification, but that doesn't mean you've built the right system. A better approach is to invest a bit of time envisioning the requirements, but not trying to define them in detail.
I'd like to thank Thomas W. de Boer, Mark Graybill, Dan Hoover, Ron Jeffries, Huet Landry, Socrates Medina, Scott E. Preece, Dave Rooney, and Tim Tuxworth for their feedback regarding this article.
