Are the following three equations correct? Why / why not?

Rami,

this sums up my thinking very well, there are rarely definitive answers to these questions as the number of variables in most projects makes the picture too fluid.

But also, unless there is a sudden and serious deterioration in the project environment, most of these situations can be addressed/escalated over time and if necessary raised as a project CR. This provides the opportunity to gain the buy-in from management and resource teams to go that extra mile to regain lost ground.

Thanks for all comments. Here’s my own analysis. Let’s see if you agree.

The three equations I presented above are taken from a project management power point presentation by Jeremy Jay V. Lim that he called Concepts and Cases. I believe listing the three equations and calling them the Triple constraints is not correct. Here’s why:

The three competing constraints of project management remain always: Scope, Time & Cost. Now we can add to them like quality, risk, …. However, these three remain the foundation.

What I find wrong is using the equal sign as Tight Time and Tight Budget do not necessarily lead to increased costs respectively increased time.

Here’s an acceptable way of presenting the three constraints:
• increased scope typically means increased time and increased cost,
• a tight time constraint could mean increased costs and reduced scope,
• a tight budget could mean increased time and reduced scope.

While I fully agree on these three bullets, I can agree on the first equation: “Increased scope = increased time + increased cost” but I cannot agree on the second and third equation. Simply, I find replacing "could mean" by an "EQUAL SIGN" misleading.
If you don't have enough budget, you may well reduce the scope and the time.
Do you agree?

The first one could be not right too. Who stated this equation must specify what cost mean.

Nice analysis. We should not even replace typically means in the first statement by "equal to" symbol.

The answer to all the questions is it could be but not necessarily. For example.

1- For increased scope, you might be able to Fast Track the schedule so there is no additional time or cost.
2- For tight time, you might be able to Fast Track and scope reduction should be your last resort.
3- For tight budget: Scope reduction is not an option normally, but fast tracking is.

There is no black and white when it comes to those situations. You have to assess all options and chose the one that least impacts your project.