Why is the Project Management Triangle so fundamental?

As a project manager you would have certainly heard about the Project Management Triangle (or Iron Triangle or Triple constraints). Some PMs live and die by this, and there’s a really good reason why.

A quick theory recap

Countless articles have been written on this topic, but let’s quickly recap. The Project Management Triangle recognises 3 aspects of a project and describes the connection between them:

• Scope (often quality is considered part of that)
• Cost
• Time

The theory behind it is as follows: in every project one would have these 3 constraints. They are very tightly interconnected, so changing one would always affect at least one other. Furthermore, you can only fix 2 aspects of the project – the remaining one needs to stay flexible.

Putting the Project Management Triangle into practice

As with a lot of things, theory is just that. You look at all different project management methodologies, frameworks and the perfect worlds they portray and it feels almost effortless to deliver a successful project if you follow a strict, predefined path.

The Project Management Triangle is no different – in a theoretical world it’s a perfect weapon in a project manager’s arsenal and could be the answer to a lot of difficult questions:

• “Can we add just 2 more pages?”
• ”Oh, I am afraid this will increase the delivery time”
• ”But you know we can’t slip – the deadline is immovable”
• ”We can throw more people onto the task – but it’ll cost more”
• ”But there’s no more money available! Just leave everything as it was then.”

Nevertheless, the beauty of the theory behind the Project Management Triangle is its simplicity. The logic is bulletproof (hence it’s often referred to as the “Iron Triangle”).

And this simplicity is really what you can put to work.

In a theoretical world Project Management Triangle is a perfect weapon in a PM’s arsenal Click To Tweet

Ensure the concept is widely understood and accepted

First and foremost, what feels natural to you may be alien to others. Even though the Project Management Triangle is a basic concept, some people are just not aware of its existence. Funny enough, it’s often the stakeholders or project sponsors who are in the dark.

Before you start using it as a shield or weapon you need to explain its premise to all stakeholders involved. Chose straightforward examples to showcase how it works.

When and how to use the Project Management Triangle?

In the real world – you are likely to get briefed on a project with a budget cap, a deadline and must-have features, all of which are predefined. Already at this point, you can start using the concept of the Project Management Triangle to negotiate yourself out of 3 aspects being constrained. It’s either you satisfy the scope and hit the deadline or you deliver the scope and fit within budget (or your client may choose to go for the deadline and budget). Whatever the choice, they have the right to fix 2 aspects for you, but you have to demand to be able to control the third aspect.

Let me explain.

You’ve done a quick estimation once briefed and realised that you cannot hit the deadlines with the resourcing limitations (because of the budget cap) and deliver to the client’s requirements.

What do you do? Try to work through a number of scenarios.

Have the difficult conversation. Your client is almost definitely a reasonable person. Click To Tweet

You would know how to balance the plan. Can you be smarter with resources? It may be one specific scope item that requires you to bring that expensive contractor in (say, a video editing guy because the client wants to get a new voiceover for that explainer video for their new shiny website launch). In this case you are not only lowering the cost (good), but also changing the scope a bit as well (bad). What’s important is you are also lowering the possibility of risk (e.g. client not happy with the edit and requesting 2 additional rounds of amends, therefore delaying the delivery of the website front page this video would be placed on) and decreasing dependencies (front page depends on the explainer video, which in turn depends on the voiceover, which depends on the voiceover artist availability, etc.).

This is of course just one route, but keeping in mind the connection between scope, cost and time you can come up with more viable options.

Once you have prepared all those scenarios, have the difficult conversation. Your client is almost definitely a reasonable person – they will understand the logic behind the Project Management Triangle. They will be even more forgiving in having to either sacrifice scope or pay more if they see you have really put effort into the analysis with their interests in mind.

Remember, remember…

Successfully negotiated increase in the budget at the start of the project? Well done, you!

You are now mid-project and things are on track. Clients are happy with the progress and loved the last 2 demos you showed them. Then, in one of the weekly status calls, they kindly ask you to look at that floating header layout. It’s something they’ve inherited from the old website and it would be a felony not to update it now that you are updating the whole website anyway.

• “It’s a small thing, right?” – they say, “You have your Front-end devs and JS guys working on the templates anyway, just ask them to fit it in, would you?”
• “Sure, should be ok” – you reply, wanting to keep the client happy.

Right? WRONG!

Why? The Project Management Triangle! Scope has increased, therefore either time or budget will have to increase no matter what. It’s the law. And with scope change alone you introduce risks and dependencies. You may be ok and running under budget now, but let’s just look at how this can unfold.

You sneak this requirement into your Dev team’s backlog, and during the planning they realise it’s there. They ask you for designs and UX across all 4 of the breakpoints they are working to. You tell them using the elements and styles they have made already. They tell you that it’s not going to fly like that.

You then go to your designer begging to fit in a quick 2 hour job. They tell you they are already working on another project and are up against a deadline, so they can’t help.

You then go to you resourcing manager hoping to find a designer who can look into this urgently. Everybody is busy as there’s a big pitch prep going on. However, there’s this new junior who may be able to help.

You grab the brand guidelines and run to that guy. You brief them, and in 2 hours you get a PSD with all 4 breakpoints represented, so it all looks good to you.

Just in time you send this to your devs and they take it into the sprint.

You exhale and hope you’ve just avoided a potentially big screw-up. Happy with yourself, you give the clients the heads-up that it’ll be in the next demo.

Two days before the promised demo your creative director walks past your Front-end dev’s desk and sees the new floating header on their screen. His face changes and he comes over to you as the project manager.

• “That header I’ve just seen – where is this coming from? I don’t remember signing this off?”

You start explaining how you skillfully got one of the junior designers to do this and that she has done a great job, as well as how the client is over the moon that we are so flexible.

• “This header is off brand completely!” you hear from the Creative Director, “Why the **** did you not review this with me? This cannot go to the client like that! And by the way, has our Head of UX seen that?”

Next thing you know what seemed like a success story turns into a nightmare. You were forced to get this done properly and go through all hoops and loops – get the UX done, multiple design iterations, internal sign-offs, etc. As a result you didn’t show anything to the client on the demo, you pissed people around you off and ended up blowing your budget since a Senior Designer, Senior UX architect and your Creative Director billed in excess of 45 extra hours to your project.

You may read this and think, “Well, it’s a classic example of scope creep”, and you would be right.

Things on a project are interconnected and there are always consequences for every adjustment Click To Tweet

But it all stems from ignoring a simple concept – you change one small thing, it’s inevitable that at least one other thing will change. Often there are other risks and knock-on effects that are introduced along the way, and so a chain reaction starts.

This is exactly the reason why the Project Management Triangle is so fundamental – it’s a very simple yet effective reminder that things on a project are interconnected and there are always consequences for every adjustment.

Be empathetic

As you grow a natural habit of being guided by the principle behind the Project Management Triangle don’t forget that it’s a theoretical model. There are other aspects of project delivery that sometimes outweigh the logical stuff, like the intangible value the project brings to the client, client satisfaction overall, client relationship status, etc. You cannot ignore these other things, and sometimes a decision needs to be in favour of them.

There are interesting iterations to the Project Management Triangle that I’ve seen – the ‘Project Diamond’ model, the PMBOK 4.0 ”star” model and the Agile version.

All are valid and are worth exploring, but the basic premise is what matters – There are always consequences.