The Magic Triangle: the base of project management

The Magic Triangle, or Triple Constraint, is widely seen as the fundament of project management. Controlling time, money and quality is a basic rule for project-governance. There are several variations, e.g. the Devil’s Quadrant. But the differences are not really relevant, at least not for this discussion.

Triple constraint and variations

This concept is generally accepted without much thought or discussion. But should it be? Is (a variant of) the Magic Triangle always useful?

Why is a project started?

A project is about change and is started because the current situation can be improved or is no longer sufficient. A project‘s goal is to facilitate future benefits. What is the point to deliver the required scope nicely on time and to budget when the product does not add value (anymore)? So, it makes sense to steer using the relationship between expected benefits and the required quality/scope in order to make decisions on changes caused by changed circumstances.

Every project has uncertainties. A project has as a characteristic that it is unique. It has never been delivered before under the same circumstances. That makes a project harder to plan than daily routine work. Steering with uncertainties (risks) in mind is very important.

Expected benefits and risks are important aspects next to the Magic Triangle for effective decision-making. Usually it would not be sufficient to see a project in terms of cost. Normally it would be far more effective to treat a project as an investment. This is the essence of the Business Case approach.

The Snowflake of Project Management

Customer and Supplier (Contractor)

When a project encounters major problems, often the supplier or contractor is blamed. Questions could be raised about their professionalism and sometime even their integrity. But is it that simple?

When (a part of) a project is contracted out, the Magic Triangle is the central part of the contract as the Triple Constraints. This is however only possible if the risks are reasonably manageable. Examples would often be found without mentioning projects: purchasing standard products.

If during a project many changes are expected and/or there are severe uncertainties, outsourcing (a part of) a project will normally be far less effective and even feasible. This is usually the situation for a project with an IT-component or large construction projects.

In this type of projects scope and quality can often not be clearly identified from the start. If it seems possible to also transfer risks to the contractor through the contract, the contractor will obviously charge a higher fee, similarly to in insurance fee. Even then things can still seriously go wrong, usually for the contractor. But usually also the client will suffer in some way. In the most positive case, the damage for the client will be limited to the higher fee. These extra costs will part of the business case.

Six aspects between Customer and Supplier

Unfortunately, it is far from unusual to have contracts based on the Triple Constraints while price is the most important (constrained) aspect and quality and scope are insufficiently described. As a result, the contractor will also vaguely and insufficiently commit. During the project, the client will pay high charges for even the smallest change. The contractor will use a clause for extra expensive work (out of scope) for the slightest change. The client’s attitude can be called "Penny wise, pound foolish" for negotiating the lowest price while not specifying clear demands.

Controlling time, cost and quality/scope is only useful with a contract between a client and a supplier. But the terms of the contract should be well considered and should be specific If this is not sufficiently possible, the client should steer extensively during the project and the supplier should be involved on basis of effort, time and material.

Further considerations.

The terms “supplier” and “contractor” were used so far. Usually when the term “contractor” is used, there is a commercial relationship between the client and the contractor. In many cases however the same issues arise when there is not a commercial relationship: between an “internal” client and an “internal” supplier. Consider cases where a department works for another department.

Whatever the situation, it is always important to realise that the customer’s business case is related to the supplier’s business case. The supplier’s benefits are directly related the customer’s costs.

The previous discussion also has a consequence for the role of the project manager, responsible for the day-to-day management of the project. In the case where a constrained contract is not feasible, the project should be managed by a project manager supplied by the client or at least by a project manager independent of the supplier. A project managed by a supplier’s project manager will increase the risk of low quality and – more importantly – of focussing on the wrong business case: the supplier’s business case.

Controlling only Time and Money.

There is an increasing trend to only concentrate on time and money. This is also the case in the Agile approach as propagated by the IT-sector: Timeboxing.

When a project fails, the focus is often on going over time and budget. This attitude on only time and budget is normally very destructive and is in fact usually a reason for project failure.

Controlling only on time and money will result in lack of quality and often decreasing scope. This will lead to decreasing benefits (business case targets will not be achieved). It will also lead to many requests for change and a lot of effort for repairs and corrections during the project causing time and money to spiral out of control. The low quality will also lead to high cost after the project because of higher operational cost and higher cost of maintenance.

Bitterness of poor quality

Methods: PRINCE2 vs. PMI (PMBoK)

Many years ago, I wrote an article about the differences between PRINCE2 and PMI (PMBoK). My conclusion was that PRINCE2 is a customer’s approach, while PMI/PMBoK assumes that a project is done by a supplier/contractor. Related to the previous:

PRINCE2 vs PMI

What do you think?

What do you think? Please leave a message below if you have any comments or questions.

About the author

Specialist in effective change.

Accredited MSP™ and PRINCE2® trainer.

comments powered by Disqus