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
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
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.