Projects operate within an environment of constraints, be that how much can be spent, how much expertise is available, when the project has to be completed by, or a wide range of other limitations. Understanding these constraints helps the project teams make better decisions as the projects progress. For example, if the project has an immovable deadline (like the Y2k projects before the year 2000 bug in some computer software, or a Olympic games event where the date is set years in advance and hard to move), then any more scope identified could not easily be handled by letting the project just take longer, it had to be handled in other ways (such as bringing in extra resources). So by understanding the constraints, we are able to better decide how to plan a project, and how to best handle change during the project execution.
Project constraint models go under many names: Triple constraint, classic constraints, project constraints, iron triangle, project management triangle and more. This is a concept model that has many variations and not one single view of what makes up the constraints and how to present them visually. Nevertheless, the concept remains a very useful one to understand some of the underlying principles of constraints in project management.

The constraint triangle presented here in a triangle is the 'classic' triple constraints of time, cost and scope, with the triangle visually presenting some type of tension or tradeoff between these constraints. That is, change the scope and you could have an impact on time and cost. Change the allowed cost and you could impact scope or time. I have chosen to add a fourth factor of quality in the diagram as there are other factors that could be impacted. If you take a quality definition as being all the characteristics or features that determine if something meets requirements, then cost, time and scope are all quality attributes, as are many other features (for example, acceptable risk or absence of defects).
While the triple constraint is widely used, there are numerous other constraint models and presentations. Some examples:
Replacing scope with specification (useful in contract circumstances where the scope is described with a contract specification and picks up on some of the quality requirements around the scope), or adding specification as a fourth dimension (so making four aspects of scope, time, cost and specification).
Adding quality as a fourth aspect around a diamond (so making four aspects of scope, time, cost and quality). In may ways this implies a different definition of quality which doesn't includes scope, cost or time (a definition of quality such as 'free from defects' or 'meets specification').
Using a larger set of constraints, such as Scope, Quality, Schedule, Budget, Resources and Risk (which are the examples giving in the PMI Project Management Body of Knowledge 5th Edition).
Using sliders to visually represent the relative importance of various constraints to help the project team evaluate options during the project. For example, in building an Olympic games venue the deadline to complete the work may be the most fixed constraint, while in building a new spaceship the elimination of defects may be the most important constraint while the timing could slip a little if needed to get things safe.
Which project constraints are actually visualised is probably not of that much importance as long as you reach an understanding of what is important to project success and what can be changed during the project. For example, the authors preference is not to put quality against the other three traditional constraints as cost, time and scope are as important measures of quality as any other quality attributes in the 'meets requirements' or 'fitness for purpose' definitions of quality - instead scope is treated like a specification, and work estimates include the quality specific scope tasks like testing. Under this thinking, when adding quality to the triple constraints it could be placed in the middle of the triangle rather than as a new and separate aspect.

Understanding constraints and their relative importance helps the project teams and governance boards make better decisions during project planing and execution - that is, it can contribute strongly to project success and therefore is important.
However, project success can be more complex than whether the scope, time and cost plans were met. For example, in business cases the expected benefits and value returned are important when deciding whether a project should proceed or not. Little variations in scope, time and cost may not be very important if it makes little difference to whether the project delivers the expected benefits or not. A very simple example of scope versus benefits might be to ask a company CEO whether they want to own an email server or not - most CEO's don't want to own email servers, they just want reliable and secure email - the email servers just a scope item that helps deliver the benefit.
Return to Project Management.
Copyright 2015 Edward Hall. All rights reserved.
Last revised 21 February 2015.