The Triple Constraint: The Project Management Triangle of Scope, Time, and Cost

As stated earlier, the concept of the project constraint triangle has been in use essentially since the first person hired someone else to perform a task. However, the project constraint triangle as we know it today became codified in the early to mid 20th century, in the manufacturing industry. Projects that resulted in finished products, from auto parts to children’s toys to airplanes, used the triangle during production. An airline like United might order twenty 707 jets from a manufacturer like Boeing, and the project would include a total budget, an overall timeline, and the expectation of the delivery of 20 complete, functioning planes. If United requested five more planes, the budget and timeline would shift accordingly.

In the last two decades, with the growth of software and global products, the project constraint triangle has adapted to fit these types of projects. The constraints are still present and relevant, but sometimes the concept of “scope” can be less finite than the delivery of a physical product, such as those twenty 707 jetliners. While scope and quality are still often considered together, there’s been a growing movement in digital projects to adapt the triangle to be a diamond, with four points instead of three.

In this model, quality is included as a fourth variable. On digital projects, quality and functionality can be variable and still result in a project’s success. While eliminating the hydraulic system on a plane would result in a non-functioning product, delivering a software project with less functionality than originally agreed upon could still be considered a success. 

Let’s say a software company is creating an update to its mapping software. The original scope included more detailed geo-locations, interactive directions, and real-time traffic information, as well as other enhancements. As the developers work on the project, they realize that the real-time traffic functionality is going to take more time or resources to accomplish than outlined in the original brief. The decision is made to hold that functionality out of this particular deliverable to keep the rest of the updates on time and on budget; the real-time traffic feature can be rolled out in a future update. 

Digital projects are continually iterative, and therefore, few things are ever considered completely “finished” in the digital world. This gives project managers and stakeholders some flexibility to keep projects moving quickly, even when they don’t deliver all the functionality initially requested – there will likely be another project that will create and deliver the missing features. In the project diamond model, “expectations” is the center and outcome of this four-sided project. If the other updates to the software release encompass enough of an improvement in functionality and ease of use, the stakeholders and end users will be satisfied. If everyone has been waiting, however, for the real-time traffic feature, the stakeholders and project managers must communicate this delay quickly and transparently, ideally with a firm new delivery date. If the outlined expectations are met or exceeded, the project is considered a success.

Some project management experts see the project triangle or diamond as not being nuanced or detailed enough to capture all the variables of a project. These experts recommend using a six-pointed star which includes components that are important, but perhaps too subjective to measure as a pillar of constraint. These include factors like risk, opinion, and value. The current thinking of the Project Management Institute and other experts is that they commend these six-pointed stars for trying to capture these important influences, but that it makes managing a typical project too complex and ultimately too cumbersome. Instead, project manager should continually weigh these other factors as a project progresses over time.