The iron triangle as an analytical tool

Latest revision as of 17:54, 28 February 2021

Written by Jonatan Larsen Edry

[edit] Abstract

This article aims to present the Iron Triangle (also known as the 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 trade-offs. 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.

[edit] The Iron Triangle and its most common variations

The Iron Triangle (also known as the 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^[1][2] 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^[3][1]. However, as extensively and thoroughly analysed by the rather up-to-date What is the Iron Triangle, and how has it changed? (2018)^[3], 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^[4] (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^[4] as success.

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 behaviour is formulated famously as “good, fast or cheap - pick two”^[5][6], 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^[4]. Contrarily, tunnel visioning on the tool’s criteria alone will also eventually lead to a project’s demise^[3].

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”^[7], 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.

[edit] 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 apparent 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 projects thinking errors ^{[9] [7]}; 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 of the Iron Triangle within the Type I & II Errors are presented.

[edit] 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^[10] 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 not only achieving but also measuring long-term benefits. While the classic triple constraints of the Iron Triangle are by themselves not able to measure these benefits, a relevant side-track to this topic is the large area of Earned Value Management (EVM) that manages to build upon the foundations of the triple constraints to do exactly so.

• 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 themselves are not sufficient to define success^[11]. It is therefore suggested that project success must go beyond these criteria by for example including safety, risks, benefits, satisfaction etc.^[12] in the model, as depicted in Figure 3. 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 is called the Project Management Star^[8] and it lists six constraints, made from two overlapping triangles in a star shape as seen in Figure 4. Here, it says scope is constrained by the budget and schedule, while quality is assured by managing risks and resources. This also means, that the Project Management Star distinguishes between the constraints of Scope and Quality.

[edit] Type II Errors

• The Square Route. The famous research of R. Atkinson^[7] heavily criticized the use of the Iron Triangle as a primary model for measuring projects success. The reasoning for this being the heavy reliance on gut-feeling resulting in either underestimation or overestimation when relying too heavily on the tool. R. Atkinson suggested that project success and management should not only be viewed from the perspective of the project’s own goals but on its surroundings as well. In relation to this, strong connections can be made to Table 1 above, where it is seen that success from a Program and Portfolio perspective is related to the organizational benefits and value. The Square Route model was created by R. Atkinson and is based on how the Iron Triangle should not stand by itself but instead considered as a part of three other and just as important criteria of success including; the information system, the benefits to the organization, and the benefits to the stakeholders. The model can be seen in Figure 5 below. The model represents 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 incorporated as key success criteria, similar to what was mentioned in the Type I limitations and success definitions in Table 1.

• Project Success vs. Project Management Success. As previously stated, 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^[13]. 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 project value and its benefits focused on the long-term. And project management success (efficiency) refers to the delivery of requirements within budget, on time, and to the agreement of other chosen constraints^[3]. 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 the dimensions of for example factors such as project types, project phases and satisfaction, as mentioned previously, before it can fulfil the requirements of measuring long-term benefits.
  A relevant real-life example of this issue can be explained by the well-known Sydney Opera House project. The opera house opened 10 years behind schedule and ended up costing 1367% over budget ^[14]. So, from 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 the economy as well.
  So, based on these distinctions, many researchers have actually agreed upon that the Iron Triangle by its core actually evaluates project management instead of project success.^[3]

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

[edit] Application of the iron triangle

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

[edit] 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^[4] 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^[4] process flow; planning and controlling. The general assessments having to be conducted shared among various constraints have been summarized and listed below:

Planning: ^{[4] [15]}

• The identification of constraints and their respective threshold
• Who should be setting the constraints
• How they are to be used by the project manager
• How the stakeholders of the project are going to be informed of the constraints’ status throughout the life cycle of the project

Controlling: ^{[4] [15]}

• To determine the situation of the project through monitoring processes
• To assess how the situation aligns with the constraints the stakeholders and project manager has agreed to
• To identify if any constraints are either about to be or already have been breached
• If a potential breach has been identified; propose alternatives for undertaking the breach.

For each potential constraint, the PMBOK Guide's^[4] presents varying process flows in between planning and controlling for each distinct managerial project area. However, a whole article could be written for each project constraint management area, and since the core of the Iron Triangle also primarily revolves around the flows of planning and controlling, this article is restricted to these. The detailed planning and controlling flows with their respective inputs and outputs for example the most common constraints are found in the PMBOK Guide's^[4] (6th edition); scope^[4] [pp. 124-137, 167-172], time/schedule[4] [pp. 179-182, 222-230], cost^[4] [pp. 235-239, 257-270], quality^[4] [pp. 277-287, 298-306]. The planning and settlement of constraints and their thresholds should occur before project kick-off as estimative metrics. In this part, it can be said that the Iron Triangle is applied rather statically. However, the same can not be said when the tool is applied in a controlling manner. For optimal usage of the tool, it is required by the project manager to consider continuous monitoring and control of the constraints, resulting in a flexible use of the tool. If done correctly, this would allow for analysation of possible constraint threshold breaches and to develop reactive action plans.

[edit] Constraint Balancing

Figure 6: The Iron Triangle's zones of balance and strategic choices. Own illustration based on figure from ^[1]

While the Iron Triangle should not be restricted to initial project estimates, it is here where the tool’s strength within planning is present. The project manager should in agreement with the stakeholders not only identify relevant project constraints, but also the thresholds of these. A strategic approach to handle the constraints is to prioritize one or two of three constraints instead of altering between all three. This approach has been shown to help project managers and their team to make faster decisions and centralize the focal point of what is relevant more easily. However, it is also here where the previously presented recompense dynamic of the Iron Triangle shines through. It is within this aspect of the tool that the project manager should attempt to balance the constraints according to the related project. For simplicity's sake, the example of constraint balancing in Figure 6 have been made on top of the classic Time, Cost, and Quality triple constraint, as these were found by Pollack, J.'s analysis^[3] to be the most interconnected, more so than any other combination of project management concepts. So, while still acknowledging that Time, Cost, and Quality are 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 strategic choices have been visualized and enumerated in Figure 6, and described as following:

1. Fixed deadline - compromise on budget and quality if needed to hit it
2. Unbudgeable cost - time and quality must be compromised
3. Quality is steadfast - allowed to be met expensively and/or slowly
4. Time and cost are fixed - quality must be compromised
5. Within budget, the quality must be met - allowed to be met slowly
6. The quality must be met within a fixed deadline - allowed to be met expensively
7. Neither project manager nor stakeholders have predetermined constraint thresholds - open for negotiation

However, while balancing the constraints in the planning phase of the project, it is also highly relevant throughout the controlling and monitoring of the project. The reason for this being, that projects are never static, and can face many unexpected changes to either of the project constraints. This can lead to unexpected breaches of the agreed constraint thresholds, which is why a project manager must be prepared to be flexible and re-arrange/re-balance the applied Iron Triangle. For example, if the budget is cut short in the middle of the project life cycle by stakeholders, alternative constraint strategies must be presented where for example certain quality requirements are neglected. This behaviour is also the great example of how the tool differs in its application within planning versus controlling. This interplay between the constraints is also highly relevant in the case of the Project Management Star as presented above. However, the star will with its additional constraints result in a more complex and intertwined list of strategic choices to consider. So, while the star grants more flexibility to the project manager, it could also result in a case of overwhelmingness and blurred focus.

[edit] Avoid tunnel vision - what about Program and Portfolio management?

A crucial aspect is that the project manager does not exclusively focus on the Iron Triangle and its constraints alone – they must avoid tunnel vision. As presented by R. Atkinson and his Square Route model ^[13], the project managers should not sorely be fixated on the project’s own goal. This ties back to the presented lack of long-term measurements in the Iron Triangle and its lacking distinguishment between project success and project management success. To achieve a broader view on project success, the project manager must look beyond the borders of the Iron Triangle where additional constraints and additional dimensions to the tool are not necessarily sufficient. Instead, to achieve more value-focused project success, one should attempt to include the business case and vision of not only the project, but the organization as well. In relation to Program and Portfolio success, the organizational benefits, and the overarching strategies are in focus. Therefore, in the case of a project functioning within a program and/or a portfolio, the project manager must align the project with not only its classical constraints but most importantly the defined expected program benefits and the strategic vision of the program and the portfolio. By managing the project success within these types of constraints, e.g., business cases, organizational goals, portfolio strategies, the Iron Triangle as an analytical tool will be reinforced. It is therefore critical to apply the Iron Triangle with the rightful purpose of being an analytical tool alongside (but not exclusively) the management knowledge areas presented in this article to steer an on-going project in the direction of success.

[edit] Annotated bibliography

• Project Management Institute, Inc. (2017). Guide to the Project Management Body of Knowledge (PMBOK Guide). ^[4]
  

  The PMBOK Guide is a key reference of this article. With its highly relevant standard for project management, it was first and foremost used to find proper definitions of Project, Program, and Portfolio success. With its elaborative step-by-step processes, it was also used to generalize and summarize the process flow of planning and controlling based on its presented project management knowledge areas.

• Pollack, J., Helm, J. and Adler, D. (2018). What is the Iron Triangle, and how has it changed? ^[3]
  

  This paper has made extensive research on 109,804 project management records from 1970 to 2015 to explore how the Iron Triangle is defined in a real-world practice and how it has changed. This has resulted in a paper collecting, applying, and summarizing some of the most important key-literature of the Iron Triangle throughout time. It has also led to a very comprehensive collection of Iron Triangle limitations where the most universally acknowledged ones were presented in this article.

• Wright, Andrew, and Therese Lawlor-Wright (2018). Project Success and Quality: Balancing the Iron Triangle. ^[1]
  

  While this chapter is primarily focused presenting Quality’s importance of project success, it has been used in this article for its good and simple definitions of the Iron Triangle and its various behaviors. It also presents a thorough practical application process of balancing the Iron Triangle and its core constraints in different manners which was used as inspiration for this article as well.

• Roger Atkinson (1999). Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. ^[7]
  

  Roger Atkinson presents not only one of the most acknowledged criticisms of the Iron Triangle not measuring success properly, but he also presents a framework to mitigate it through the Square Route. It is also within this paper that R. Atkinson applies the Type I and Type II Errors to classify his criticisms in the perspective of projects thinking errors.

• Siegelaub, J. M. (2007). Six (yes six!) constraints: an enhanced model for project control. ^[15]
  

  This article is primarily focusing on an extension of the Iron Triangle with three additional constraints. While this version of the tool is not the most acknowledged one, the article still manages to present a clear and thorough application of the tool in the light of PRINCE2 and PMBOK Guide. With the article’s foundation in these project management standards, it presents some very relevant examples of the tool seen in action.

^{[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]}

[edit] Bibliography

1. ↑ ^{1.0 1.1 1.2 1.3 1.4} Wright, Andrew, and Therese Lawlor-Wright. “Project Success and Quality: Balancing the Iron Triangle.” Project Success and Quality: Balancing the Iron Triangle, Taylor and Francis, 2018, Chapter 12, pp. 171–177.
2. ↑ ^{2.0 2.1} Vahidi, Ramesh & Greenwood, David. (2009). TRIANGLES, TRADEOFFS AND SUCCESS: A CRITICAL EXAMINATION OF SOME TRADITIONAL PROJECT MANAGEMENT PARADIGMS.
3. ↑ ^{3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8} Pollack, J., Helm, J. and Adler, D. (2018), "What is the Iron Triangle, and how has it changed?", International Journal of Managing Projects in Business, Vol. 11 No. 2, pp. 527-547.
4. ↑ ^{4.00 4.01 4.02 4.03 4.04 4.05 4.06 4.07 4.08 4.09 4.10 4.11 4.12 4.13 4.14} Project Management Institute, Inc. (2017). Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition) - 2. Initiating Process Group. Project Management Institute, Inc. (PMI). pp. 4-29, 543-545
5. ↑ ^{5.0 5.1} Van Wyngaard, C. & Pretorius, Jan-Harm & Pretorius, Leon. (2012). Theory of the triple constraint — A conceptual review. 1991-1997. pp. 1192-1195.
6. ↑ ^{6.0 6.1} T. S. Mokoena, J. H. C. Pretorius and C. J. Van Wyngaard, "Triple constraint considerations in the management of construction projects," 2013 IEEE International Conference on Industrial Engineering and Engineering Management, Bangkok, Thailand, 2013, pp. 813-817.
7. ↑ ^{7.0 7.1 7.2 7.3 7.4 7.5} Roger Atkinson, Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria, International Journal of Project Management, Volume 17, Issue 6, 1999, Pages 337-342.
8. ↑ ^{8.0 8.1 8.2 8.3} PRINCE2, Project management triangle: overview of the triple constraints. Blog. Posted on Friday, 26th July 2019 13:29. Submitted by ILX Marketing Team. Last accessed: 23rd February 2021. Link: https://www.prince2.com/eur/blog/project-triangle-constraints
9. ↑ ^{9.0 9.1} Atkinson RW. Effective Organisations, Re-framing the Thinking for Information Systems Projects Success, pp. 13-16. Cassell, London, 1997.
10. ↑ ^{10.0 10.1} Pinto, J., Project Management: Achieving Competitive Advantage. New Jersey: Pearson Education, 2010, pp. 35-40.
11. ↑ ^{11.0 11.1} AXELOS. Managing Successful Projects with PRINCE2 2017 Edition, The Stationery Office Ltd, 2017. pp. 15-17.
12. ↑ ^{12.0 12.1} Toor, S. and Ogunlana, S. 2010. “Beyond the ‘iron triangle’: Stakeholder perception of key performance indicators (KPIs) for large-scale public sector development projects”. International Journal of Project Management, 28(3): 228-236.
13. ↑ ^{13.0 13.1 13.2} De Wit, A. 1998. “Measurement of project management success”. International Journal of Project Management, 6(3): 164–70.
14. ↑ ^{14.0 14.1} Sydney Opera House: For Demonstrating Architecture's Power to Refine a City (Most Influential Projects: #50) (2019). PM Network, 33, 94–95. Last accessed: 23rd February 2021. Link: https://www.pmi.org/learning/library/top-50-projects-sydney-opera-house-11757
15. ↑ ^{15.0 15.1 15.2 15.3} Siegelaub, J. M. (2007). Six (yes six!) constraints: an enhanced model for project control. Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Newtown Square, PA: Project Management Institute.