The iron triangle as an analytical tool

Abstract

This article aims to present the Iron Triangle (also known as Project Management Triangle, Project Triangle, and Triple Constraint Triangle) as an analytical tool with a focus on Project Management through the perspective of Purpose. The Iron Triangle is considered as one of the most fundamental project management models regarding success and is based on the interrelationships between key project performance metrics, which in this case are defined as constraints. Therefore, the scope of this article is mainly considering project success management. With its origins from the 1950’s, the Iron Triangle was originally applied to settle on initial project estimates and thereby evaluating the project success regarding if these estimates were met. However, this article is going to present some of the most concurrent criticisms and limitations of the classic Iron Triangle, and how key research spanning many years and crossing various industries have let to the mitigations of these issues. This has let the enhancement of the approach of the Iron Triangle into an analytical tool with the purpose of not only defining project frameworks but also to continuously assess project performance throughout its lifespan by guiding project managers to where adjustments in project constraints must be made when changes in other constraints occur.

With regards to the application of the tool, it is first presented what should be assessed and considered in its two primary PMI’s Project Management Body of Knowledge’s processes; planning and controlling. Then, practical, and strategic approaches to the balancing of the triple constraints will be presented through the Iron Triangle’s core concept of project constraint tradeoffs. Lastly, it will be discussed how project managers can leverage the Iron Triangle from representing a set of pre-defined specifications (classic view of projects) to an analytical tool focusing on value creation (state of the art view of projects) by implementing the tool alongside other crucial management knowledge areas.

The Iron Triangle and its most common variations

The Iron Triangle (also known as Project Management Triangle, Project Triangle, and Triple Constraint Triangle) is an essential tool that aims to present the concept of which project success should be understood. The Iron Triangle was proposed by Martin Barnes back in 1969 and has since then undertaken various different takes based on its purpose, constraints, and even its shape. Throughout time, the Iron Triangle has always been represented by the key project performance metrics that any project success is measured by, defined as constraints; namely Time and Cost. However, as extensively and thoroughly analysed by the rather up-to-date What is the Iron Triangle, and how has it changed? (2018), it is presented that depending on the given project specifications and other varying debatable factors, either Quality, Scope, Performance, or Requirements are most often applied interchangeably as the triangle's third constraint. So, in other words, the Iron Triangle aims to represent the constraints of whether a project is delivered on time, within its budget, and to an agreed extension of quality, scope, performance, or requirement. Hereby, the focus of the tool is defined to be within Project Management, as some of the most cited project management standards have rather aligned views of project success in comparison to the core principals of the Iron Triangle. For example, the Guide to the Project Management Body of Knowledge (PMBOK Guide) presents a comparative overview of the success definition in Project, Program, and Portfolio Management as seen in Table 1 below. Here, it can clearly be seen how the Iron Triangle is an embodiment of specifically Project Management by initially covering three out of the four areas defined by the PMBOK Guide as success.

Table 1: Comparative Overview of Success in Projects, Programs, and Portfolios. Modified from PMBOK Guide

	Projects	Programs	Portfolios
Success	Success is measured by product and project quality, timeliness, budget compliance, and degree of customer satisfaction.	A program’s success is measured by the program’s ability to deliver its intended benefits to an organization, and by the program’s efficiency and effectiveness in delivering those benefits.	Success is measured in terms of the aggregate investment performance and benefit realization of the portfolio.

The Iron Triangle is most effective in displaying and communicating interdependencies between the above-presented success criteria. As seen in Figure 1 below, the classic depiction of the tool is a triangle with each constraint located at each corner of the triangle. The primary nature of the triangle’s constraint behavior is formulated famously as “good, fast or cheap - pick two”, describing how the adjustment of focus in a specific constraint warrant compensating changes in one or both of the other constraints.

With the Iron Triangle covering such core fundamentals of project management, it has been found that the neglection of its criteria can have devastating consequences on the success of a project in spite of efficient and effective management of other project metrics. Contrarily, tunnel visioning on the tool’s criteria alone will also eventually lead to a project’s demise.

One of the newer and most popular depictions of the tool can be seen in Figure 2, where Quality is now defined as its own new dimension as the outcome of the Iron Triangle, while Scope has replaced its place as a constraint. The movement of accepting and replacing the Quality criteria truly took off with “Cost, time and quality, two best guesses and a phenomenon, it’s time to accept other success criteria”, where the Iron Triangle method primarily was criticized for its heavy reliance of often unrealistic parameter estimation and un-flexible conditions of only evaluating success by initial estimates. However, as mentioned earlier, this is not the only documented limitation of the Iron Triangle which leads to the next part of this article, the limitations of the Iron Triangle.

• 

  

  Figure 1: Classic depiction of the Iron Triangle. Own illustration based on figure from .
  ​
• 

  

  Figure 2: More recent depiction of the Iron Triangle, now with Quality as an outcome instead of a constraint. Own illustration based on figure from .

Limitations Caused by Simplicity and possible mitigations of these

With such an old-school and fundamental tool as the Iron Triangle, it is of no surprise that research has pointed out some of the tool's most obvious limitations. Instead of saving the limitations of the Iron Triangle to the very end of this article, the most crucial ones are instead addressed here before the application process. The reason for this being, that this article thereby can incorporate not only the limitations but also well-known mitigations of these when discussing the application of the tool. One of the overarching criticisms of the Iron Triangle is its over-simplification of measuring project success. This had led to two types of well-known limitations that are applicable for most projects; 1. the Iron Triangle uses the wrong measurements when measuring project success, 2. the Iron Triangle measures wrongly when measuring project success. These two types of limitations can each be classified within the IS-IT projects thinking errors ; Type I Errors being when something is done wrong, and Type II Errors being when something is not done as adequately as it could have been. Below, the most crucial limitations within the Type I & II Errors are presented

Type I Errors

• Short-term vs. Long-term. Research has suggested that the Iron Triangle is too focused on measuring short-term success criteria in comparison to more long-term focused and less tangible criteria Pinto and Pinto (1991), such as the actual benefits of the project. What is meant here is, that a too narrow focus on the Iron Triangle’s classic constraints could cloud the way for locking in on more long-term benefits.

• Broadening the constraints. Depending on the type of project, and type of industry one operates project management within, it may be very likely that Time, Cost, and Quality/Scope by them selves are not enough to define success. It is therefore suggested that project success must go beyond these by for example including, safety, risks, benefits, satisfaction etc. Toor and Ogunlana (2010) into the model. However, to expand on the Iron Triangles constraint also calls for a comprise on one of its main features, its simplicity. The PMBOK® Guide uses a popular alternative model to the triple constraint. It lists six constraints, made from two overlapping triangles in a star shape as seen in Figure 4. As you can see, the project management star also distinguishes between scope and quality. Here, it says scope is constrained by the budget and schedule, while quality is assured by managing risks and resources.

Type II Errors

• The Square Route. The famous research of R. Atkinson heavily criticized the use of the Iron Triangle as a primary model for measuring projects success. The reasoning for this being the heavy reliance of gut-feeling resulting in under or overestimation when relying on the Iron Triangle. He suggested that project success and management should not only be viewed from the perspective of the project’s own goals. The Square Route model was created by Roger Atkinson and was based on how the Iron Triangle no longer should stand by itself but surround by thee other and just as important criteria of success including; the information system, the benefits to the organization, and the benefits to the stakeholder community. The take from this is, that the Iron Triangle should not be applied as its own stand-alone model, but instead incorporated into a larger view on achieving project success. Also, notice how organizational benefits and the perspective of the stakeholders are once again mentioned as in the Type I limitations

• Project Success vs. Project Management Success. As mentioned in this article, the Iron Triangle originally aims to evaluate project success. However, since its release, research has suggested that there should be a clear distinguishment between project success, and project management success. Once again, because of the Iron Triangle’s simplistic nature, such a differentiation is not made clear enough within the borders of the tool. Project success (effectiveness) refers to the value of the project and its long-term benefits. And project management success (efficiency) refers to the delivery of requirements on time, within budget. As presented in the Type I limitations of the Iron Triangle, it appears that the Iron Triangle in its original context lacks the dimension of long-term benefits and focuses too much on the short-term outputs. It is therefore suggested that the Iron Triangle lacks factors such as project phase, project type, and satisfaction before it can fulfill the requirements of measuring long-term benefits. A relevant real-life example of this issue can be explained by the notorious Sydney Opera House project. The opera house opened 10 years behind schedule and ended up costing 1367% over budget. So, in the perspective of the Cost and Time constraints of the Iron Triangle, it would be suggested that the project was a huge failure. However, from the perspective of the project benefits it is clear that the project was a huge project success with its World Heritage status (UNESCO) and its positive effect on Australian tourism and thereby economy (https://www.pmi.org/learning/library/top-50-projects-sydney-opera-house-11757). So, many researchers have since made the distinction that the Iron Triangle now actually evaluates project management instead of project success. (ref. CHANGE)

As stated in the above limitations, it is seen that many of the issues are directly intertwined with eachother. While different projects in the industry could face varying issues with applying the Iron Trinangle, the above ones have been chosen as these appear to be the most foundational ones. With these limitations and their suggested mitigations in mind, the following sections attempts to present how the Iron Triangle can be applied from the perspective of a project manager.

• 

  

  Figure 3: Depiction of the Iron Triangle's lack of complexity​
• 

  

  Figure 4: The Project Management Star. Own illustration based on figure from
• 

  

  Figure 5: The Square Route model. Own illustration based on figure from ​

Application of the Iron Triangle

This part aims to present how project managers can apply the Iron Triangle to their projects with its presented limitations in mind.

Constraint Management

As discussed previously, the relevancy of the most relevant success criteria can vary significantly across different kinds of projects. Nonetheless, a project manager should still be able to implement and understand the best practices when applying the Iron Triangle. However, while the PMBOK® Guide does not have any direct reference of when or how the tool should be applied, a connection can be made between the application of the constraints and two critical points that appear throughout all of these from the PMBOK® Guide's process flow; planning and controlling. The general assessments having to be conducted shared for various constraints have been listed below:

Planning:

• what the constraints/ tolerances should be (if they have not been previously defined),
• who should be setting them (and when),
• how they are to be used by the project manager,
• how the sponsor/ stakeholders/ Project Board will be kept informed of the status of the constraints and project.

Controlling

• determining what is going on in the project (standard data collection/ monitoring processes),
• assessing how that compares against the constraints/ tolerances the sponsor/ stakeholders/ Project Board have agreed to with the project manager,
• whether any of the constraints/ tolerances been breeched – or threaten to be breached,
• proposing and recommending alternatives for addressing the breech.

Constraint Balancing

Figure 6: The Iron Triangle zones of balance and strategic choices. Own creation based on an illustration obtained from Project Success and Quality: Balancing the Iron Triangle.

"Instead of juggling between the three constraints as suggested by a classic triple constraints, the strategic choice is about giving priority to one or two of the three. Such prioritisation will help project team to make quick decisions and focus effort on what is most relevant." For simplicity's sake, the constraint balancing have been made on top of the classic Time, Cost, and Quality triple constraint, as these were found by Pollack, J.'s analysis to be the most interconnected, more so than any other combination of project management concepts. So, while still acknowledging that Time, Cost, and Quality is not defined as "fit for all" projects, this application process making use of exactly these for the sake of generalization and common ground. Various zones and possibilities of balancing of strategic choices have been visualized in Figure 6, and described as following:

1. Immovable deadline - do what is necessary to hit it
2. Cost is everything - time and quality must give
3. Requirements must be met, however, slowly or expensively
4. Time and cost immovable, quality must give
5. Quality must be delivered within budget, but no hurry
6. Deadline is fixed, quality must be met, the sponsor is prepared to pay
7. An evenly-balanced situation - everything is negotiable to deliver success

This interplay between the constraints can also be applied to the case of the Project Management Start as presented above. However, this will of course result in a way more complex and intertwined list of strategic choices to consider.

Avoid Tunnel Vision

To not apply the Iron Triangle as its own stand alone tool. Must not neglect Business Case, Vision, Long-Term benefits, and priorities (what are the ACTUAL success criteria of this very project?). Discuss the importance of not neglecting benefit and customer satisfaction (relation back to Type I and Type II errors).

Annotated bibliography

Key references:

A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)

Managing Successful Projects with PRINCE2, 6th Edition (2017)

Test

Test

Test.

Test.

Test.

Test.

Test.

Test.

Test.

Test.

Test.

Test.

Test.

Test.