4 September, 2023

The Iron Triangle: Is it Time to Improve the Triple Constraint?

The Iron Triangle, or Triple Constraint, is one of the best-known ideas in Project Management. It competes with the Gantt Chart. To non-practitioners, it’s not as widely understood, but it is more fundamental.

We’ve been using it for years and it has many names – of which Iron Triangle is my least favorite by far! I prefer Triple Constraint. But, call it what you will, is it still fit for purpose? Or do we need to improve it, overhaul it, or even abandon it altogether?

Let’s start with an introduction. This is one of the very first videos I made for our OnlinePMCourses YouTube Channel:

The Iron Triangle: Is it Time to Improve the Triple Constraint?


In this article, I’ll address five key points:

Oops… Did I just give away the punch line? Happily, this isn’t a joke or a novel. Let’s get started.

From the Barnes Triangle to the Iron Triangle: The History of the Triple Constraint

I need to credit Adrian Dooley’s excellent short article in the Summer 2022 edition of Project (the quarterly magazine of the Association for Project Management) for my understanding of some of this history. Also, Adrian, if you’re reading: we are 100% aligned on Triple Constraint being the best name!

‘The common law of business balance prohibits paying a little and getting a lot – it can’t be done’

John Ruskin, 1819-1900

Or, as my father used to say, ‘you get what you pay for’! So, this idea is not new. Indeed, there seems to be no clear origin for the widely used axiom:

‘Good, fast, or cheap: you can pick two’

The Barnes Triangle

But, as I learned from Adrian, the modern form of a triangle dates to 1969 and Dr Martin Barnes (a founder, Chair, and President of the Association for Project Management). He illustrated the three competing tensions of time, cost, and quality as a triangle.

Since then, we have used many names for it:

  • Barnes Triangle
  • Time Cost Quality Triangle
  • Project or Project Management Triangle
  • Triangle of Balance (which helps explain an important idea)
  • Triple Constraint (which helps explain another important idea)
  • Iron Triangle
Time Cost Quality - Iron Triangle

The Iron Triangle

The Iron Triangle has become the most widely-used term. It isn’t clear to me where it first appeared, nor when it morphed from representing Time, Cost, and Quality to Time, Cost, and Scope.

Barnes did make a shift to referring to ‘Performance’ rather than Quality, which arguably includes scope. But I think focusing on Scope is a retrograde step, which I’ll discuss below.

But I do appreciate the ‘iron triangle’ metaphor. Triangles are rigid in that they cannot readily be deformed. And nothing conveys that rigidity better than ‘iron’. We think of girders and bridge structures.

Iron Triangle is both an apt metaphor AND a misleading one.

It is apt because it reminds us that we cannot escape the triangle.

But it is misleading, because the truth is that we can (and do) stretch the triangle. We can have more quality, if we are prepared to pay more. And we can save money if we are prepared to cut corners. And we can get earlier delivery if we either invest in more resources or cut quality (or scope).

Understanding How the Triple Constraint Works

All of this is about how the Triple Constraint works as a powerful thinking tool. The three corners of the triangle constrain one another.

But let’s start with another helpful name for it: the Triangle of Balance. I like this name because it reminds us that we need to bring the corners into balance. With the right budget, we can deliver to the required quality (or scope) in the agreed time. If we want to change one of these, we must change at least one other, to bring the triangle back into balance.

Another way of saying this is that the corners constrain one another. If we want to change one corner, we can, but only if we ease off on one or both of the others. The three corners are a triple constraint.

Alternative Iron Triangles: What Three Constraints?

You’ll notice that I have been flip-flopping between Time-Cost-Quality, and Time-Cost-Scope articulations. Both are, I guess, equally valid. And it’s my sense that:

  • Time, Cost, and Quality is more widely used in the UK
  • Time, Cost, and Scope is more widely used in the US

I have no idea about other places, so please do feed my knowledge in the comments below! My guess is that preferences correlate to some extent with the cultural proximity to these two countries.

In the next section, I’ll show two ways that we can resolve this by incorporating both. And we should consider them as different, because they are:

  • Quality answers the question, ‘how good do you want it?’
  • Scope answers the question, ‘how much of it do you want?’

Combining Scope and Quality

However, there are at least three ways that we can combine scope and quality into one coherent concept, to make a triangle of either:

  • Time, Cost, and Performance
    Which Barnes used
  • Time, Cost, and Specification
    Where we specify both scope and quality
  • ‘On time, on budget, on target’
    Which I used in the sub-title to my book ‘How to Manage a Great Project’

You’ll have your own favorites, but I like:

  • Schedule, Resources, Specification
    Here, schedule is just time, and ‘resources’ is a wider concept than cost, since money is just one resource, alongside labor (people), assets, equipment, and materials
  • Risk, Benefits, Investment
    This is widely used in Program Management as the major levers of control, where time, budget, and scope morph and expand over the longer timeframe
  • Value, Quality, Constraints
    This is the ‘Agile Triangle’ where the term ‘constraints’ represents time, cost, and scope (sneaky, hey!)

I have a video that explains the Agile Triangle…

Alternatives to The Triple Constraint: Different Aspects of a Project

As soon as you start to like some of the additional possible ‘corners’ of the triangle, you start to want new shapes.

The Project Diamond… or Tetrahedron

The first step is to include quality and scope on an equal footing with one another, to make a diamond shape:

Project Diamond

However, this fails to capture the sense of constraints and balance. A diamond shape is easily deformed. For that reason, in my training, I represent it as a tetrahedron (triangular-based pyramid. This has the same rigidity as a triangle and therefore better represents the need to balance the four corners.

Time Cost Quality Scope Tetrahedron

Let’s Go Large! The PMBOK Guide, PRINCE2, and PRINCE2 Agile

The PMBOK Guide (4th Edition) and PRINCE2 each introduced a set of 6 things to consider:


The PMBOK Guide refers to six competing constraints:

  1. Schedule
  2. Budget
  3. Resources
  4. Risk
  5. Quality
  6. Scope


At the same time, PRINCE2 refers to six variables, or six aspects of project performance:

  1. Timescales
  2. Costs
  3. Benefits
  4. Risk
  5. Quality
  6. Scope


Apart from superficial differences in terminology, the big difference is that PRINCE2 uses benefits, while the PMBOK Guide chose Resources (a kind-of repeat of budget). In fact, PMI was very late to the party in seizing on the importance of benefits in projects.


PRINCE2 has a whole section about the different types of project tolerances, that refers to its six aspects of project management.

PRINCE2 Agile - Fix & Flex

But PRINCE2 Agile takes this a whole lot further. It suggests that it is in the nature of agile projects that we fix time and cost. There is no tolerance to flex them, because they become committed when we establish the length and resourcing for an iteration or sprint. Indeed, one of the five ‘targets’ of PRINCE2 Agile is:

‘Be on time, and hit deadlines’

(A little tautological, if you ask me)

You may well choose to fix or flex benefits and risk. We start from a minimum acceptable benefit and a maximum risk tolerance. But, within those constraints is room for adaptation.

In agile, PRINCE2 Agile asserts, it is quality and scope that we constantly flex, by prioritizing according to the needs of our customers or users. Another of the five ‘targets’ of PRINCE2 Agile is:

‘Accept that the customer does not need everything’

However, there is another target that appears contradictory:

‘Protect the level of quality’

When you have chosen the priority to give to quality and specified the standard that the customer needs, quality becomes fixed again.

The FLEKS Model

In his Fleks Model, Hélio Costa describes 6 Value Variables that match the PMBOK 4 constraints closely:

  1. Time
  2. Cost
  3. Resources
  4. Risks
  5. Quality
  6. Scope
FLEKS Model Value Variables

However, Fleks represents them as orbiting around value. We use them to determine how to optimize value creation, and so are all subservient to this critical variable. If we need more value, we ‘fleks’ one or more of these six things. In Fleks, ‘everything is variable’!

We have a detailed article by Hélio on this website and a full interview with him too. And, of course, you can download all his free (open-source) materials from fleksmodel.com.

My Take on the Iron Triangle: Let’s Continue to Love the Triple Constraint

With so many enhancements over the years, it’s fair to ask whether the simple Triple Constraint of Time, Cost, and either Quality, Scope, or Specification is still useful. Or does it, perhaps, oversimplify what’s important in the delivery of a project? This Is especially the case when we are working in environments where:

  • All projects are hybrid projects with anything from a few to a lot of adaptive processes, methods, and tools
  • The line between a big project and a program is becoming increasingly blurred. Is it fit for an Agile Age?

I think the answer depends on what you think the Iron Triangle is for. Is it for:

  • Establishing the success criteria for a project?
  • Understanding Project priorities?
  • Balancing competing constraints?
  • Optimizing value from the choices we have available?
  • Articulating what is important in project performance?
  • Determining tolerances for variation and change?

Without a doubt, for each of these uses, the longer lists add something to our understanding and flexibility.

Why I Love The Triple Constraint

Yet, I fundamentally believe that the Triple Constraint is now down and out yet.

Because, for me, its real value is as a thinking model and a teaching tool. Explaining the need for balance and the mutual mesh of constraints provides deep insights. And exploring the range of variables and when each is important helps us develop a greater sensitivity to the details of projects in general, and our current projects in particular.

The Triple Constraint in The Agile Triangle

And, if you need any further persuading, take one last look at the triangle in the Age of Agile. The Agile Triangle may look different, but what’s that I see in the bottom right-hand corner? Do you see it? Agile evangelists may sound like they want to reject all things predictive, but there it is. At nearly 60 years old, embedded in the Agile Triangle, is the Iron Triangle – a variant of Martin Barnes’ original insight.

Agile Triangle

What are your Thoughts on the Iron Triangle?

So, what do you think? Please share your thoughts on the different versions of the Iron Triangle and it’s bigger – maybe better – cousins, in the comments below. And I will respond to every contribution.

Never miss an article or video!

Get notified of every new article or video we publish, when we publish it.

Mike Clayton

About the Author...

Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Never miss an article or video!

     Get notified of every new article or video we publish, when we publish it.