The Power of the Project Management Triangle

Also called the “iron triangle” or “triple constraint,” the project management triangle is a core principle of project management that applies particularly well to software engineering.

While its origins are not clear, the project management triangle has been in use at least since the 1950s, when it was widely observed in manufacturing processes.

The project management triangle asserts that the quality of any product is constrained by the budget, deadlines, and scope (features) and that the project manager can only trade between these constraints, typically at the outset of the process.

Changes in one constraint necessitate compensatory changes in at least one other such that, at most, only two of the three can be maximized at any one time, even under the best of circumstances.

In other words, if the project is completed quickly and under budget, then it will be shipped with too many defects. If the defect rate is low and the product is shipped on time, then it will be generally more expensive than the next best option. And so on.

In practice, of course, project managers seek to balance all three constraints to deliver a final product that meets basic requirements, including functionality and cost, within a specified delivery window, and discussions should be had with the client at all phases of the project to ensure that proper expectations are set and met.

Limitations of the Triangle

One of the implications of the triangle is that any of the three constraints can be changed “on the fly” in order to affect one or both of the other two.

This is typically not the case.

If a project is at risk of being late—due to late changes in scope, for example, or unanticipated technical hurdles—the project manager may be tempted to ask for more money to compensate.

Sometimes, this can work, and it may be worth it to try, but software development projects are not perfectly malleable, and it is often the case that, once begun, no amount of money can make the process finish faster.

This unfortunate reality was first described in a 1975 book called “The Mythical Man-Month” by Frederick Brooks. During his time as a software engineer at IBM, Brooks repeatedly observed that throwing more programmers at a project did not make it go faster. In fact, if anything, it tended to have the opposite effect!

This is because complex engineering projects cannot be perfectly partitioned into discrete tasks that can be worked in silos without communication between the developers. Therefore, throwing more programmers at a project tends to make it lag rather than accelerate because “the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever-increasing quantity of time.”

This is not to suggest that there are no opportunities for parsing work differently (or cutting scope) in order to accelerate a project. Often, options are available.

But it’s important to note that the three points of the triangle are not especially plastic.

Facing Risk

One of the ways clients and project managers mitigate against delays is by increasing the allotted schedule at the beginning to leave room for unforeseen issues.

Another way is by assuming higher levels of risk.

Risk is a wager. It’s a gamble on the future. In the case of the stock market, this is clear. An investor buys a stock on the expectation that it will increase in value, but nothing guarantees it will. In fact, the higher the potential rewards, the riskier the stock tends to be, and vice versa.

That same logic applies to project management. If a client chooses not to approve extra time in the schedule, they are betting that nothing unanticipated will happen. (While that is technically possible, we have never seen it.)

This is why the Project Management Institute, in their trademarked Project Management Body of Knowledge, will sometimes adapt the triple constraint into a mitigation star, which recognizes that additional tradeoffs can sometimes be made.

No one likes to acknowledge risk. Many teams would rather simply pretend it doesn’t exist, which is the surest way to succumb.

Communication is the answer

When it comes to risk, schedule, and quality, communication between the client and the project manager is key. Make sure you have a clear understanding of the scope of your project—what is included and what is left out—and talk to your project manager about risks and mitigations. And of course, be sure to leave time for that communication in your project plan.