The "Broken Iron Triangle" Software Development Anti-pattern

	The "Broken Iron Triangle" Software Development Anti-pattern

Home \| Articles \| Books \| Podcasts \| Contact Us \| Mailing List \| Site Map

Software development projects often fail because the organization sets unrealistic goals for the "iron triangle" of software development:

Scope (what must be built)
Schedule (when it must be built by)
Resources (how much it must cost)

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 project team delivers at all, the quality of the delivered product suffers and the project 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 project failure, it just seems that it's one of management's more popular approaches to hamstringing an IT project.

Motivation

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 issue” 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 a software project. When nobody budges from their position, or is forced to budge, the project team is positioned for failure.

Impact

By breaking the iron triangle, you often:

Cancel the project. According to the Chaos Report v3 (the most recent), 15% of projects are cancelled before they deliver a system. Yes, sometimes the real problem is that a project should never have been started in the first place, indicating that organizations need to get better at portfolio management. However, my experience is that breaking the iron triangle is often a root cause of project cancellation. Interestingly, a study of 1,027 IT projects cited scope management related to serial practices as the single largest contributing factor to project failure in 82% of the projects and was given a overall weighted failure influence of 25%.
Deliver late and/or over budget. According to the Chaos Report 51% of projects are challenged (severely over budget and/or late), with an average cost overrun of 43%. Yes, perhaps the real problem is that organizations need to improve their estimating approach. What often happens, however, is that the project team knows they won't be able to deliver on time but still tell senior management that they hope they can. Once the organization has committed resources and political capital to the project, the IT team knows that the project will likely still be supported even though it is late or over budget.
Deliver poor quality software. When development teams are forced to deliver more functionality than they have time or resources for, they are often motivated to take short cuts which inevitably result in poor quality.
Under deliver. The team fails to deliver all of the required functionality.

Solution

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 project 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:

Vary the scope. You can do this by timeboxing, which enables you to fix resources and schedule by dropping low-priority features out of an iteration when you’ve run out of time. It is interesting to note that many agile development processes, such as Scrum or Extreme Programming (XP) take this sort of approach with an agile strategy for change management.
Vary the schedule. You can set the scope (see below) and the resources and then let the schedule vary by varying the number and type of people on the team which enables you to deliver the required functionality at the desired cost. If you're tight for budget, a small team may deliver the same functionality that a large team would but take longer calendar time to do so. The more people you have on a team, the greater the amount of money you need to spend on coordination and therefore your overall costs increase. Furthermore, a handful of highly productive people may produce better work and do so for far less money than a larger team of not-so-productive people.
Vary the resources. If you set the schedule and scope you may need to hire more and/or better people to deliver the system. However, remember that there are limits to this approach: nine women can't deliver a baby in one month.
Vary two or more factors. It isn't always possible to vary just one factor. For example, it isn't possible to build an air traffic control system from scratch in a single week regardless of how much money you're willing to spend.

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

The bottom line is that something has to give, whether you want it to or not. Either one of the three iron triangle factors needs to give during a project or you can give up hope of actually succeeding. It’s your choice. Yes, it can be politically difficult to choose to take an elastic triangle approach to development but it’s a lot easier than having to explained why you failed yet again. Yes, to be fair sometimes you can guess the scope, budget, and schedule fairly closely early in a project and thereby not have a broken triangle. So, if you can honestly do such a thing (and not just delude yourself into believing you can do so), and you're willing to live with the challenges of a BRUF approach, then good for you.

Acknowledgements

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.

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer. A full description of what I do, and how to contact me, can be found here.

Last updated: August 19, 2006
|| Agile Data (AD) | Agile Modeling (AM) | Agile Unified Process (AUP) | Enterprise Unified Process (EUP) ||