gemini://nader.pm/from-the-project-management-triangle-to-the-seesaw/

This article is a work in progress; just some thoughts I'm writing down to receive comments, think more about, and hopefully, return to, revise, and expand on.

Many people involved in projects have heard of something that goes by many names, including the "project triangle", "iron triangle", and "triple constraints", which takes different forms, including the following:

The idea is to highlight the relationships between the main constraints. For example,

Suppose you need to finish a project faster. In that case, you'll have to adjust at least one other constraint to trade it off: you can spend more money (e.g., to buy better equipment or hire more people), remove some elements from the scope, reduce quality, or any combination of these.

Are you going to build a complex for the Olympics? Then, its time is completely fixed, and you can't use it for trade-offs. The project scope is more or less fixed by what the games require, and you don't want to sacrifice quality because it will harm the country's reputation and may defeat the purpose. So, you have to be really generous with the money because anything that gets out of balance must be balanced by adjusting the project cost.

There have been many forms of this model with varying 3 or 4 nodes, but they communicate more or less the same idea. What some of them have in common is that they combine scope and quality into one node:

This looks cleaner, and honestly, separating scope and quality is not as easy as it sounds. So, the combined element is everything that defines the product (project's output).

This form of the triangle brings us closer to the common saying: Fast, cheap, or good; pick two.

Combining scope and quality into one item makes sense. Since we've done that, why not combine time and cost? After all, they represent the investment: We invest something into the project and create an output (product). Since we're left with only two items, it's a good idea to show them on a seesaw:

The pivot point of the seesaw is a triangle, which can be seen as an homage to the original triangle ;)

So, the original triangle and the current version of the seesaw suggest that we can't change one constraint without changing another; e.g., we can't reduce time without changing scope, quality, or cost. Is this always true? Well... sometimes we can do it by improving our efficiency. After all, that's why we want to have better project management! Another form of efficiency is that sometimes we can find a different approach to work, which creates the same output much faster and easier.

To make Archimedes happy, I'll show it as the potential to move the pivot point to the left or right. Are we allowed to mix physics with project management? ;)

Having efficiency in the model helps with a lot of things. Consider Brooks' Law, for example: Adding manpower to a late software project makes it later.

Adding more people (increasing the cost) usually reduces efficiency. Sometimes, the reduction is so significant that it cancels the whole thing out and doesn't let it affect time or any other element.

The people involved in the project are covered in the original triangle by the cost element; i.e., if you want to have more people or more experienced people in the project, you'll have to spend more money.

That's true, but I believe it leaves out something else: the well‑being of those people!

You can put too much pressure on the team members and finish the project faster, but it may not be ethical, and it will probably backfire in the future (maybe in the same project or in a future project). Because of its special impact, I think we should consider it a separate element.

I consider the well-being of the project team members to be an element in the pivot point that changes how much investment is needed to create the product:

I didn't want to consider the well-being of team members as a form of efficiency because while it has a relationship with the efficiency of the team, it's not limited to it.

Adding well-being makes it clear that something else is missing here: The project product is not the only thing we create, but we also leave a social and ethical footprint. The latter should also be considered, especially because it can have trade-offs with all other elements, not just well-being.

The downside of such a model is that the social and ethical footprint is not as tangible as the product and harder to measure. On the other hand, we've already established that this model is a rough rule of thumb and not a basis for calculations.

When we think about the product (scope & quality), certain outcomes are implied. When people insist on certain elements of scope or quality, what they really want are the outcomes that are expected to result from them. If you can come up with a different combination of scope and quality that can deliver the same outcome with less investment (time, money & well-being), everyone would usually be happy. This is one of the main topics of classical value engineering.

At a higher level, we should even think about these desirable outcomes. Why do we want them? Because we expect them to generate certain benefits. However, sometimes, we can get more benefits with other outcomes.

Evaluating the relationship between the product, the outcomes, and the benefits is mainly done at higher management levels with a holistic perspective that goes beyond the boundaries of the project. Yet, it's a good idea to remind everyone of this possibility; i.e., if you can't balance the seesaw, maybe you can revise the product-outcome-benefit relationship and come up with a different product that balances everything without sacrificing scope or quality:

Is value missing from this model? No. The best way to define value is the benefits to investment ratio, which are already covered.

Some people add the overall risk to the triangle. I disagree because the overall risk is a probabilistic deviation from the most likely estimates of time, cost, and other elements. It's not a separate element but the deviation of the existing elements. So, it's better not to have a separate element for it.

In my opinion, the classic triangle is not useless, but it's a good rule of thumb for thinking about trade-offs in a project. I propose the seesaw model not to reject the classic one, but to provide an alternative that may be more helpful.

From the project management triangle to the seesaw

The triangle

The number of elements

Reduction!

Other factors

More about people

What about benefits?

What about value?

What about risk?

Conclusion