How the Iron Triangle can improve your design workflow

Hector Herradura
UX Collective
Published in
6 min readMar 27, 2020
Low angle photo of a building, triangle is the focal point.
Photo by Omar Sotillo Franco on Unsplash

Iron Triangle it’s an old paradigm used by project management to manage and to analyse the success of a project from three perspectives with one objective in mind, the delivery date. Iron Triangle term was coined by Dr. Martin Barnes circa 1969.

Learning this tool will help you to understand some basic foundations of project management and it will also help in your personal projects.

The Iron Triangle paradigm is the assumption that time, scope and cost are the main constraints of a project and that for a project to be successful it must meet these three criteria.

This idea comes from the 50s when project management started to be treated as a professional field [1]. Olsen, R. P. tried to define for the first time what was product management in 1971 using the 50s and 60s references.

Project management is the application of a collection of tools and techniques (such as the CPM and matrix organization) to direct the use of diverse resources toward the accomplishment of a unique, complex, one-time task within time, cost and quality constraints. [1]

Even thought the definition has always been a complicated subject in the project management field trough the years, and to this day, there were always a tendency to include these three criteria that has been constantly appearing in every definition: time, cost and quality/scope.

This way the Iron Triangle metaphor, also known as ‘project management triangle’ or ‘triple constraint’, was born.

How it works

First we must remember what it is.

Iron triangle diagram, a geometric triangle with one of the three criteria in each side (cost, time and scope).
Iron Triangle diagram

The Iron Triangle is a paradigm used to manage a project from three criteria or perspectives during its lifecycle. The overall project quality is affected by balancing these three criteria: time, scope and cost.

  • Time: the amount of time we have available to deliver the project at the fixed date.
  • Scope: the amount of deliverables or features which are derived from the requirements to be met by our project.
  • Cost: what it cost to produce our project in terms of: fees, materials, software, travels, cost variances…

The main idea that resides behind the triangle is that there must be a total balance between each criteria. If we modify one vertex, at least one of the other will be affected. If we enforce the balance, two of them will be affected.

This means the triangle is totally rigid due to this balance enforcement that we are applying to it. The three criteria constraint each other. If we want to cut time we will decrease scope and cost. If we want to increase scope we will have to increase time and cost. If we want to decrease the cost we will reduce the scope and time…

If you want to try an experimental UX approach you can do it by changing the three original criteria: time, scope and cost by these other criteria: technology, user and business, which are the three main fields where UX design takes place.

Some previous indications

Iron triangle mindset has also been used to define the success of a project and it’s been proved that is not the best approach. Notice the triangle is a flawed model to measure success at post-delivery stage because it’s strongly based on the delivery date criteria.

A project that maybe has been successful at the stage of the delivery can fail at the post-delivery stage when the customer uses the product, because some important features for the customer were missing.

An extreme example of this, but that it will make it clear, is the series of events that started in 2013 and involved the air bag maker company Takata. A series of defective airbags killed 25 people and provoked to recall more than 42 million cars in the U.S.A , being the largest recall for the automotive industry in that country. [2]

If we measure the project from the Iron Triangle perspective, the project was a success, since it was delivered on time, with the time available, meeting all the required costs and achieving the best scope that the company could give at that time. But it failed after the delivery date resulting in deaths and injuries, the project failed.

Also, analysing a failed project from that limited criteria is maybe omitting other criteria that could be used to gather useful insights, as Roger Atkinson said in 1999:

It is further suggested that the early attempts to describe project management which included only the Iron Triangle and the rhetoric which has followed over
the last 50 years supporting those ideas may have resulted in a biased measurement of project management success. Creating an unrealistic view of the success rate, either better or worse! [3]

For that reason we have a lot of different ways of measuring success that today are being implemented in the project management field. We have star models, square models…

Anyway, the Iron Triangle is considered a traditional paradigm, it’s the base for other paradigms and it’s still taught in project management schools and we can extract some useful knowledge from it.

How to implement it in your design projects

You can use the model in a basic way for you projects when you have a date to fulfil and during its lifecycle when something changes to analyse how that change affects the other criteria and the project.

It will help you to focus your objectives based on the delivery date. Analyse the three criteria time, cost and quality and act accordingly to what you have, adapt the balance to give the best solution you could reach.

The guide below is a collection of basic previous steps that will help you to apply the Iron Triangle paradigm in your design project:

  • Identify all the requirements your project needs, in terms of time, scope and cost.
  • Think about a clear objective you can achieve.
  • Balance the three vertex: time, scope and cost to achieve the best quality.
  • Think about uncertainties such as possible problems that could occur such as losing your hard drive, losing connection to the server… and design proper solutions for them. But also think about possible positive uncertainties such as new tools you can encounter online that would accelerate your project.

Obviously, you should not get obsessed with this paradigm since we are not in a pure project manager position but in the designer position. You should notice a better focus on your capabilities at the early stages of your project and a better monitoring system throughout its lifecycle.

Can I use to measure success?

I wouldn’t use it to measure success, as it has been shown the model is flawed to the post-delivery stage analysis and it’s mainly focused on the previous stages of a project. Furthermore, the three criteria approach (time, scope and cost) is a very limited way to think about why a project failed.

I would use it as a tool to give an overall previous look and to set up my mind on what quality should be accomplished with the amount of time, cost and scope I have, and also to keep track during the project’s lifecycle before the delivery date.

Don’t use it as criteria to define success but as general map to guide to your delivery date objective.

To measure success the are a lot of unique criteria that depends a lot from your project’s idiosyncrasy. The project success study field is ambiguous and multidimensional.

References

[1] Olsen, R. P. (1971). Can Project Management Be Defined? Project Management Quarterly, 2(1), 12–14.

[2] Takata Corporation incidents.

[3] Atkinson, Roger (December 1999). “Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria”. International Journal of Project Management. doi:10.1016/S0263–7863(98)00069–6.

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Published in UX Collective

We believe designers are thinkers as much as they are makers. Curated stories on UX, Visual & Product Design. https://linktr.ee/uxc

Written by Hector Herradura

The computer an extension of the human intellect, programmed by master control to survive by all means. Designer. https://www.linkedin.com/in/hector-herradura

No responses yet

What are your thoughts?