Pretty much every project I’ve ever been involved in, both professionally and in my personal life, has conformed to this theory; I look back on projects that I did before I knew about the concept and think “yeah, actually, those were the project triangle trade-offs we made”. As a software business, Terzo Digital staff have managed dozens if not hundreds of software projects and this principle applied to all of them; however, it also applies to projects in many other walks of life.
I now always bear it in mind with current projects – it’s very useful to step back from the day-to-day and think about the project in the context of the triangle and remind myself where this particular project fits, and what the limitations are. Cryptic? All will be explained…
Some examples of projects
Here are some examples of projects which conform to the Project Triangle Principle (PTP). I’ve chosen them to illustrate that the PTP can be applied to very different types and sizes of project, and that you can use the PTP to help make decisions and trade-offs to achieve the most important outcome for your project.
I’ll introduce the examples now, and then come back to them later to show how the PTP applies to them.
Example A: In 1962 President Kennedy pledged to put a man on the moon and to bring him back safely before the decade was out. The Apollo program was born, and the US, despite Kennedy’s untimely death the following year, fulfilled his commitment.
Example B: Britain’s Second High Speed line (HS2) was proposed by the Labour government in 2009 and approved by the secretary of state in 2012. Various legal and pressure-group challenges ensued and the work hasn’t yet started. The first part of the line was originally proposed to open in 2026.
Example C: Take a standard software development project: a common commercial structure agreed between a client and a supplier is what’s known as “fixed price” – a fixed price for a fixed scope of work. The scope is generally fixed by an agreed specification.
Example D: Doing a home extension. You save for months, if not years, and finally you feel like you have enough to go ahead with the work (maybe against a rough estimate that an architect gave you sometime in the past). You get the architect in to re-work your plans and you commission a building firm to get underway with the work.
Overview of the Project Triangle
The principle can be conceptualised with a diagram of a triangle, with each side labelled with one of three key constraints. The current “state of play” of your project is represented by a dot in the middle; the closer you are to a given side, the closer your project is on-track for that aspect. As you push towards one side (i.e. aspect), you inevitably pull further away from either or both of the others.
Time
The first edge of the project triangle is “Time”. The closer to being on time (or even ahead of time – how often does that happen?) compared to what you originally planned, the closer you should be to that side of the triangle. So if you’re bang on time, you’re on the edge:
If your project is slipping behind schedule, you move towards the centre of the triangle:
And if your project is way off the time estimate, you move furthest away from the “time” side:
Cost
The second side of the triangle is labelled “Cost” (or “price” or “money” – they’re all the same thing for a project). This represents the total forecast cost for the project (the sum of what’s been spent and what you’re predicting to go). Just like “time”, the closer your current forecast to the original budget, the closer you should be to the “cost” side:
Third side
The definition of the third and final element of the project triangle is a bit more flexible. It’s often called “quality”, but equally it could be “specification”; sometimes it’s labelled “risk” if risk is a bigger problem on your project than quality and spec. All of these things represent some key, intrinsic quality about the deliverable.
The same rule applies – the closer you are currently to the original specification (if that’s what you’ve decided is the most important aspect to manage), the closer to that side you should be.
What this means for your project
Now, in principle, it should be possible to “achieve” all three aspects of the Project Triangle, where “achieve” means that when the project has finished, it was on time and on budget compared to the original plan, and the specification was delivered as it was originally envisaged. However, in most cases, as a project progresses, things change.
Things change for a huge variety of reasons, such as: requirements change, or the project needs to be delivered quicker, or the budget is reduced, or people have under-estimated how long it will take, or the cost of the materials is higher than expected, or the complexity is worse, or…. In fact, it’s very unusual for a project not to change as it progresses. In fact, there’s a whole chapter of the project manager’s manual which deals in “change management”.
Furthermore, if a project is above a certain size, or timeframe, or complexity, the likelihood of change on a project becomes increasingly certain.
So, as things change around him, the project manager has to change the plan, adjusting aspects of it in response to what is imposed upon him. This inevitably leads to trade-offs, and compromises.
The trade off
And thus we get to the key bit of advice that’s at the core of this principle:
“Pick any two”
or
You can’t optimise all three.
Another way to think of the sides of the triangle as “Fast”, “Good” & “Cheap” and you can have any two, but not all three.
The good news is that you can choose. You can’t have everything, but you can choose which ones of time, cost and spec are most important to your project. That means you can assert control, and manage stakeholders, as things around you change.
Examples
Let’s see how this theory applies to the examples I gave.
Example A: The Apollo programme was definitive in its specification: “to send a man to the moon and bring him back safely”.
It was also crystal clear about the timescale – “by the end of the decade [1960s]”
What it made no mention of was the budget, probably because a) it’s not as inspiring to talk about grand aims in terms of being cost-effective, b) there were much larger considerations (like beating the Russians to salvage national pride in the space race and to learn lots about rockets) and c) no-one could very easily guess how much it was going to cost – this was all new territory. However, a preliminary guess was made of $7 billion dollars.
In 1973, the overall programme (which by then had finished) was reported to Congress as $25 billion.
This is what the project triangle diagram looks like for the Apollo program:
The spec and timeframe were delivered, the cost was not.
Example B: HS2 is interesting, because at the time of writing (2015) we’re really only at the start of the project; arguably, no ground has been broken so you could say we’re only really at the planning stage. I’m crystal ball-gazing here, but I confidently predict that:
- The timeframe will be allowed to slip if the whole programme is completed
- Or, the full programme may never be fully implemented – future governments could pull the piug – in which case the timeframe may be met, but the specification could be greatly reduced (e.g. phase 2 may not go ahead)
- Unless the specification is reduced, the costs will be greater than forecast.
So we have two scenarios:
- A full implementation (on spec) but the costs and timeframe overrun
- A reduced implementation, with costs and timeframe on budget.
Their project triangles look like this:
| Scenario 1: |  |
Scenario 2: |  |
I could of course be wrong, but the history of large public infrastructure projects shows that one of my predictions is the likely outcome; what I confidently predict is that the project won’t meet the original spec, and be on-budget, and be on-time.
Example C: The fixed price software project. As a supplier, you commit to providing a fixed spec at a fixed price (very often in a fixed timeframe). This can often go one of the following ways:
- The client changes their mind about what they want – thus the spec changes. The supplier project manager needs to be alert to this and to vary the contract (time and price) to cope with the impact of the changes
- The spec remains fixed and the supplier has to deliver for the agreed price. It takes the supplier longer to deliver, because “things go wrong” or are “more difficult than expected”. This is why suppliers build in contingency to their timeframe and costs so they can deal with a certain level of unknowns.
This is why software projects have project managers. As you vary one of the three key variables, the other aspects also vary and need to be managed. It’s also why software projects can go massively over-budget, can not deliver their key aims, or can run on for years longer than budgeted. I’m massively over-simplifying here, but the principles are correct.
As an aside, the fixed spec has long been a thorn in the side of software projects, and now many teams go for an “Agile” approach as an alternative method for delivering software.
Example D: Getting my house extension done. Say for the sake of argument I have a fixed budget (my savings from the last few years) – the only way to increase this is to delay the project and save for longer. To get it done now with my fixed budget, the only things in the project triangle that I can vary are the spec and / or the timescale. If I have a fixed deadline (e.g. it’s got to be done in time for my birthday party) then I may have to compromise on the scope – only getting some of my original plans completed. However, if I can cope with being flexible on timeframes, I can get the whole of the spec delivered:
Summary
Whatever you’re doing, you’ll probably have to make trade-offs. And the trade-offs for pretty much every project is:
“You can have two out of three from cost, time and specification”.
It’s not what an idealist would want. We’d all want to have our cake and eat it –to have all three of those key things. But understanding that it is very difficult to achieve all three is a good way to start your project – expectations of stakeholders can be set. Furthermore, if your project is sufficiently large or complex, then change is inevitable. When change happens, you’re likely to have to re-assess the objectives of your project and to make compromises to achieve the important ones.
Moreover, understanding this fundamental limitation – that you can only have two out of three – helps you to make choices in your project. Is the specification really fixed in stone? Or can it be varied because timescales are more important? The project management triangle gives you the understanding and a tool to ensure your project can still be a success and can achieve its fundamental objectives.
Further reading, and variations on this theme, are available from Mind Tools, Project Smart, John A Lewis & Stakeholdermap.
The author, Neil Tubman, is a director at Terzo Digital and has nearly 20 years of experience of managing software projects.