What is Iron Triangle of Projects?

The Project Management Triangle (also known as Triple Constraint, Iron Triangle and “Project Triangle”) is a model of the constraints of project management. Success in project management has been traditionally associated with the ability of the constraint parameters of projects in scope, time, cost, and quality called iron triangle. It is a popular metaphor pointing out that the project manager is asked to reach a reasonable trade-off among these constraints.

Project managers often require a balancing act between key factors that constrain the overall project delivery. As such, the quality of work is constrained by the project’s budget (funding and resources), deadlines (time) and scope (features). These three factors are the well-known attributes of scope, schedule, and cost as shown in the Figure below:

• Scope refers to the total amount of work involved in delivering the project
• Cost refers to the sum of all resources required to deliver that work
• Schedule reflects the time estimated or allotted to the project’s delivery.

Even if the project manager is allowed to have some flexibility to trade between constraints and obviously, changes in one constraint necessitate changes in others to compensate or quality will suffer. For example, a project can be completed faster by increasing the budget or cutting scope. Similarly, the increasing scope may require equivalent increases in budget and schedule. Cutting budget without adjusting schedule or scope will lead to lower quality.

Examples of Cost / Time / Scope

• “How much is this going to cost?” – “As much as you’re willing to spend.”
• “How long is this going to take?” – “As long as necessary.”
• “What am I going to get?” – “Whatever you tell us you want.”

Strategies for Dealing with Project Constraints

FIXED COST

Where a customer asks for a fixed price quote before agreeing to project commencement but is flexible on what is delivered and how long it takes.

• Work in absolute customer priority order – reducing the time spent on technical helper tasks will help meet short-term budget constraints (at the cost of long term, post-project, efficiency)
• Release in short (1-2 week) sprints – similar to longer waterfall projects, longer sprints tend to cost overruns to deliver on time
• Monitor velocity and burn rate – this is your key indicator of the cost

FIXED TIME

Where a customer asks for delivery by a certain date but is flexible in scope and cost.

• Work in absolute business value order – increases the number of user stories completed in a given sprint (high business value = simple, moderate-high priority)
• Enforce sprint duration – Your project will be defined by a fixed number of sprints, and extending a sprint will push out your final date

FIXED SCOPE

Where a customer asks for a fixed set of deliverables but is flexible in the time it takes to deliver and the cost of delivery. This is sometimes known as “heavy agile”.

• Focus on backlog definition and estimation during Sprint 0 to ensure accurate scope definition

FIXED COST AND SCOPE

Where the customer asks for a fixed price quote for a fixed set of deliverables. In this situation, the final date for delivery is flexible. As well as the points in fixed cost and fixed scope;

• Increase the estimated risk during Sprint 0 – to ensure your quote for the project allows for unexpected delays (which would impact on your cost to deliver)
• Update delivery date as required

FIXED COST AND TIME

Where the customer asks for a fixed price quote by a fixed time. In this situation, the exact set of features (or scope) for delivery is flexible. As well as the points in fixed cost and fixed time;

• Calculate total cost as cost per sprint – which makes your quote to the customer very simple.

FIXED TIME AND SCOPE

Where the customer asks for a fixed set of deliverables by a fixed time. In this situation, the total cost to the customer is flexible. As well as the points in fixed time and fixed scope;

• Pre-assign work to sprints during Sprint 0 – which will define the scope delivery timetable.
• Pad schedule with extra sprints – to cater to unexpected defects or technical debt
• Increase the size of the team 3-4 sprints before the end of the project if required – to ensure the set of features is completed in time.

FIXED COST, TIME AND SCOPE

Where the customer gives no flexibility in the project.

• Cancel the project – this is not an agile project.
• This should be run using a waterfall methodology such as PRINCE2 (and even they are likely to fail without some flexibility)

Iron Triangle – Traditional Project Management vs Agile

In the traditional approach, the triangle would typically look like the one on the left as shown in the Figure below. As you can see, there is a fixed scope of product requirements. So to ensure the product can be completed all of our required features, we need to be a little flexible with our resources (and budget), and schedule (deadlines). If we need the product to have a list of features described in the upfront requirement specification, perhaps we need to delay the release date by several months or more in reality.

In the Agile sense, there is a fixed schedule (in Scrum we do this through time-boxed Sprints and fixed resources. Thus when things don’t work according to the plan, it is the scope that needs to be reduced. In Agile, however, we ensure that even if we have to compromise on scope, we are still delivering the highest priority items in the product backlog for maximizing the value yielded by the project.