The project management triangle is an illustration of how a project’s constraints correlate.
It is a useful tool to help stakeholders and customers understand that they can’t get everything (“pick any two”). It can also be the starting-point for discussions about a project’s relative priorities.
The project management triangle is usually shown as in the figure below. The sides show three constraints in project management: time, cost and scope. Quality is put in the middle to illustrate how it relates to the three constraints.
The project management triangle comes in many shapes and forms. Not even necessarily as a triangle. The labels also differ slightly. Scope may be replaced by features or functionality. Cost by resources or budget. Time by timeline or schedule. The meaning is the same, though.
Sometimes the labels are put on the corners instead of the sides, as in the figure below.
The project triangle can also be shown as a trilemma. The labels are then replaced by fast, good and cheap. It is in this context you say “pick any two”. The remaining constraint depends on the other two – and cannot be controlled. For example, you can build something fast and cheap, but it will probably not be very good.
There are also other versions, for example the project diamond and PMIs point star (two inverted triangles where the second one depicts risk, quality and resources).
While these and other “evolved” versions of the project management triangle may better depict the real complexity of projects, they lose some of the simplistic beauty of the traditional triangle.
As the project triangle shows a simplified picture of a project, it works best as the basis for discussions and to illustrate a point.
As an example: in a previous post called Fixed Price Contracts - A False Sense of Security? I write about how fixed prices “lock” all sides of the triangle and significantly increase the risk of project failure. In other words, in the context of a fixed price contract, the project triangle shows how quality is the only factor workable by the contractor.
Scrum and the Project Management Triangle
It might seem like Scrum disregard the basic idea of the project management triangle. Sprints have locked time, cost and functionality. The time of a sprint is always the same. The team should not change. The team has also committed to finishing a set number of user stories, or features.
The truth is that while a sprint seemingly violates the prerequisites of the project triangle, quality is never supposed to be jeopardized.
Using the concept of velocity, Scrum teams adapt the scope iteratively after each completed sprint. It is ok not to finish all the user stories in a sprint. Sprints even have built-in quality assurance in the form of the definition of done.
As the definition of done is continuously worked on and improved, the Scrum team also assures quality of delivered code improves.