The Iron Triangle as Forcing Function

The Iron Triangle of project management asserts that Scope, Cost, and Time represent dimensions fundamentally and irrevocably bound together such that for a given project, they cannot all three remain fixed.

The Triangle specifies that project leadership can lock in at most two of these dimensions, leaving the other one to provide a relief valve for the unexpected. It is folly to plan a project and expect perfection, and, in fact, only 2.5% of projects were said to complete successfully in a study by PwC. The Iron Triangle embraces this truth and forces project leadership to respond accordingly. 

For the purposes of this post, Cost will be replaced with Team, since the size of the team tends to be the primary contributor to cost, independent of Time. With this adjustment, let’s call the selection of two fixed dimensions – with the third serving as the flexible dimension – the Fundamental Question at the heart of the Iron Triangle and frame it thusly:

The Fundamental Question: Scope, Team, and Time – Pick Two

The Iron Triangle is traditionally viewed negatively – who wouldn’t prefer their project to come in under budget, on time, and fully complete? When faced with the Fundamental Question, project sponsors typically try to negotiate for all three dimensions and are often promised all three by either well-meaning, or threatened staff. This bodes poorly, of course, because Immutable Laws respect no political pressure. Such a project is at risk from kickoff because Management is already practicing magical thinking.

But what if, instead, the Triangle is viewed as an asset? What if its inherent truth is used to guide an honest and collaborative management and development process with realistic outcomes? How can introducing a flexible dimension increase predictability? This post will assert that the only way to make the Iron Triangle work for, and not against, a given project is for project leadership to select from the outset which dimension is flexible. Furthermore, if that selection is made for the entire software development organization it has fundamental implications on how teams will deliver software and, importantly, how they define success.

The Thought Experiment

Conversations on the topic of the Iron Triangle usually don’t venture beyond bemusedly stating the Fundamental Question and moving on – in which case the answer fails to change behavior or expectations. What if project leadership chose from the outset which two dimensions are fixed and which one is flexible? What impact would this have on project success criteria? How would project processes and ceremonies change? How might the very nature of the organization change? By definition, the question is Fundamental – it can’t NOT have a top-to-bottom impact on every project, so why isn’t the selected answer posted on the wall, published on the internal company web portal, and known to every team member up to the CEO? Is it a secret? What do we fear would happen if it were known? Let’s discuss the three available choices and how their selection impacts the organization.

Scope and Team

In this scenario, project leadership has selected scope and team as fixed dimensions, and time is flexible. A development team has been assembled and knows exactly what they are building.

Pros

• Results in delivery of a specific, defined product
• If a team is sized and organized appropriately, resource contention should be low, maximizing efficiency
• Quality can increase when developers aren’t rushing and have time to properly design and test a product

Cons

• The project may take longer than planned, which may disappoint customers and lead to higher costs
• Circumstances may change and the well-specified product is no longer what customers wish for – it may be irrelevant upon delivery
• Natural attrition on unending projects may mean team composition changes after all
• Perfection may be an irresistible and unachievable pursuit
• The state of the art may change during very long-running projects, requiring rework to stay technologically relevant

Observations

There are rather few projects that have no deadline since time typically correlates with cost, and most financiers look for a return on their investment. As such, this model is rarely an intentional choice. However, when leadership doesn’t believe in the inherent truth of the Iron Triangle (again, magical thinkers), it’s common for projects to approach their delivery date and discover they are far from complete. This results in a scramble to patch together a partial product (cutting Scope) or force a developer death march or add “heads” (expanding Team), or miss a deadline (lengthening Time), an inevitable capitulation to the Immutable Law. When the deadline is flexible, however, the pressure is relieved and the Team can finish a product (Scope) and bump the delivery date (Time) as necessary.

This model may work in long-term research scenarios where a limited group of people with repeated infusions of cash can continue an effort toward a specified goal that would otherwise be unachievable. In a corporate environment, however, it tends to lead to unhappy customers – an inflexible process delivers outdated products later than planned. This is typically the fate of non-iterative Waterfall projects.

Note that if an application has quality issues upon release, then it was never fully delivered. By definition, a project must function as specified to meet the agreed-upon Scope. If there is a user-visible degraded behavior or technical debt that requires rework, then the product is incomplete and no credit is given for keeping Scope fixed.

Scope and Time

In this scenario, project leadership fixes scope and time, with the team being the flexible dimension. While the end product is specified, as well as a release date, Team size, and/or intensity flex.

Pros

• Delivered product should meet specifications and be delivered on time
• Minor team changes or limited overtime may not be overly disruptive in order to bring a project close to meeting its target home
• For smaller projects with few unknowns, it can be relatively predictable

Cons

• Resource contention and process overhead inevitably lead to diminishing returns as team members are added to a project
• Adding team members is disruptive to team dynamics and culture
• Developers are not interchangeable resources – they vary in how quickly they learn, how productive they are, and how independently they operate, rendering it difficult to estimate the benefits of adding new team members
• Unsustainable pace leads to developer burn-out/turnover
• Entirely specifying a product before the project start may lead to an obsolete product upon delivery

Observations

When any discussion of the Iron Triangle turns to Team as the flexible dimension, there is a notably high chance that someone will bring up the example that 9 women cannot gestate a baby in 1 month. This perhaps overly-visceral observation provides an excellent example of one of the major hazards of selecting Scope and Time as fixed dimensions–that being resource contention. Delivering a child, in our example, requires one – and only one – womb. It is not a divisible or shareable resource.

In software engineering, many resources are shared, a common one being source code. Though the days of pessimistic locking of source files are thankfully long past, increasing the number of developers working on a given section of code invariably will lead to increased contention, churn, and, ultimately, waste. This can only increase by adding more developers. Therefore, there is a sweet spot for any unit of source code for the number of developers who should edit it with any regularity. This strongly suggests Team should not be the flexible dimension. As well, rationally, we all know that hiring, onboarding, and training developers is time-consuming and expensive. Team dynamics become unwieldy, status meetings increase, and productivity grinds to a halt. While Conway’s Law may be used to reduce the impact of communication overhead between large groups of developers, this is complicated and worthy of its own blog post. Suffice it to say that adding team members is very quickly subject to the Law of Diminishing Returns.

Selecting a team as the flexible dimension is often preferable to a project that never ends. However, it still suffers from an inflexible perspective on what’s being delivered – defining the product too soon can result in delivering something that doesn’t satisfy its customers. Meanwhile, ensuring the entirety of a large scope of work is delivered on time is exceptionally difficult and typically not possible with custom software. There are two factors indicating a scenario in which this model might work:

• The work is relatively simple and repetitive
• The work can be done by independent team members without resource contention

This generally only applies when building on a framework in which the core is stable and repeatable units of work – such as implementing a narrowly-defined feature behind an existing API – can be done without impacting other similar work. Low training overhead, minimal resource contention, and a high degree of predictability in delivery may allow this model to scale output by team size. For high-caliber software developers, this is typically perceived as low-value work, however, and should therefore be left to more junior developers.

It should be emphasized that asking (or demanding) that developers work extra hours is considered to be expanding in the Time dimension (which should be fixed in this model) and is not an acceptable long-term Iron Triangle cheat code. It comes with its own costs, which are not inconsiderable. Low job satisfaction, burnout, and turnover are real risks. A sustainable pace should be the mantra of any team pursuing maximum efficiency. In general, team composition should be kept as stable as possible. Developers are humans with human needs for connection and purpose, and healthy teams benefit from continuity. Selecting a team as the flexible dimension is typically a poor choice for a project of any complexity and often corresponds to an employer with low job satisfaction metrics.

Team and Time

In this scenario, project leadership has determined when a product will be delivered and a team has been assembled to build it. Scope, then, becomes the flexible dimension. As opposed to the other two options, which only affect team scale and project duration, making scope flexible fundamentally alters the way projects are delivered.

Pros

• The product is delivered on time
• Team churn is low and selected to reduce resource contention, maximizing efficiency
• Feature sets can be responsive to changing customer requirements, leading to a desirable final product

Cons

• If scope and feature set change often enough, rework (waste) results; product ownership must remain strong
• The ultimate product may have a reduced feature set from the original vision in order to meet the deadline
• Projects that require a specific feature set by a specific time (e.g. for a publicly-announced release or a feature controlled by a third party) leave little room for scope changes

Observations

By this point, it should be clear that selecting Time or Team to be the flexible dimension often results in unhealthy project pathologies. Team churn has many downsides, and slipping deadlines satisfy no party. What, then, of making scope the flexible dimension?

Imagine a multi-year Waterfall project with a fixed team and deadline and with Scope nominally flexible dimension. As the release date approaches, the code must be buttoned up, tested, and left in a viable state since, by definition, this date is fixed. In such a scenario, a prior date is typically chosen, after which no new features may be added in order to ensure a functioning product is produced on time. Selecting a date that’s too early may lead to waste, or even an incomplete product, as the team is barred from delivering new code. Meanwhile, a date that’s too late may result in a low-quality product as the team scrambles to fix bugs or rushes to add ill-considered code. This is a poor way to manage Scope.

Fortunately, a much better way exists. Agile software development typically prescribes an iterative approach to delivery and, when practiced well, results in a high-quality product that is responsive to customer needs and dramatically reduces risk by focusing on delivering a functioning, evolving product. Automation is typical of high value in Agile development – Infrastructure as Code (IaC) and CI/CD allow for short iterations (sprints) that result in working code delivered to production every two weeks or even as often as every commit. When an Agile project hits its stride, the impact of the Time dimension is often dramatically reduced because production-quality code is continuously delivered. As well, Agile teams are often happier and more successful because a fixed team tightly engaged with a product owner can stay focused on customer needs without artificial deadlines and developers can see the immediate impact of their work. Prioritization of features via a backlog, then, becomes of primary importance. Selecting Scope and focusing on producing a Minimum Viable Product (MVP) and then iterating is, therefore, almost always preferable to the alternatives.

Agile turns the theoretical pathology of flexible Scope – that is, requirements changing – into an asset. A feature request arriving during one sprint in a uniform distribution, then groomed and prioritized and delivered the next, can be realized in – on average – a sprint and a half. As opposed to a project with fixed Scope, an Agile project’s scope is allowed – nay, encouraged – to change as the team works off a prioritized backlog and continuously releases production-quality code. This ensures, too, that project customers are receiving their most highly valued features without having to wait for a distant release date. For larger projects with a public audience that does have such a fixed release date, the project will be released on time and will be of high quality and, at worst, will lack only lower-priority features if the project is running behind early estimates.

Summary

As we’ve discussed, it turns out that the Iron Triangle is brittle rather than rigid. Under duress, one or more dimensions will break. As such, it benefits project sponsors, in collaboration with project leadership, to select which one of the three dimensions can serve as stress relief. At its heart, project management is an exercise in risk management. In the Iron Triangle, manipulating Team or Time mid-project generally adds risk and often provides little benefit. Allowing Scope to be flexible, however, points a development team to move away from Waterfall and towards a more responsive, modern process. As compared to the other two options, selecting Scope as the flexible dimension leads to a virtuous cycle of early delivery of a high-quality, evolving product, turning the erstwhile rigidity of the Iron Triangle into an asset.

It should be noted that not every project is delivered late, requires a major talent influx to be complete, or demands a late cut in features delivered. Sometimes the planets do align and projects work out according to one’s dreams. Since the vast majority do not, however, it is of great benefit to going into the enterprise of building software with a plan for when things inevitably don’t go perfectly. Answering the fundamental question early means that the surprises that pop up in every project can be handled by plan – adjusting one or more of Time, Team, or Scope as agreed upon prior to kickoff. In this fashion, the Iron Triangle is a forcing function for the Question and its Answer provides a map to success or failure – either break the Triangle with unknown consequences or use the selected flexible dimension to guide a response to predictable, favorable outcomes.