The project scope, often captured in a scope statement, is the “work” that needs to be completed in order to deliver the project objectives.
The project schedule, is the timeline associated with each task and the sequence of each task, within the project, this is often captured in either a task diagram or a gant chart.
Each of the 3 constraints have be to considered when a change in the project occurs as one or more of these [triple] constraints directly are affected. When one or more of these constraints change it has a knock on effect on the others. Often, in real life projects there is what is known as scope creep - which are ever changing requirments - this is a symptom of either a non-existent or poor change control process. As you could imagine the if the requirements as been added as a project is in the execution phase, then you could easily have a knock on effect with not only the schedule (as more time is required to add these new requirements,) but also the cost will spiral out of control.
Another issue to watch out for is: in the initail stages of the project it will become quite apparent (if you question the project sponsors effectively) is that usually one of the constraints is quite rigid , this is what the project sponsors are very reluctant to move. For example, if the project is to launch a new product to market and this is very time sensitive, maybe the company wants to get to market before their competitors, then Timeis a rigid constraint. At this stage, you should emphasis this point to the project sponsors (as there is no point highlighting later in the project when the going gets tough), that time cannot be moved therefore you may need flexibility on the Cost and the Scope of the project. As you have highlighted and explained this at an early stage using this model then when you need to add more resources or cost to the project then the project sponsors are aware of this. By the way as a (very important) side point, clear communication, especially with the poject sponsors on a regular bassis is very important to a projects success.
As part of the below comment by Priscilla, here is an updated version of the triple contraints.








6 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
In the PMBOK they usually put a circle around the triangle to represent quality, because the project essentially operates within the quality management strategy applied to it.
Priscilla,
This is a very good point, I have also seen “quaility” where I have objectives in the Model above. By balancing/controlling the triple contraints you directly effect the quality of the project. I have just checked my copy of the PMBOK it states “Project quaility is affected by balancing these three factors”. I shall update the diagram and put it at the end of the blog post. Thanks so much for your input.
A good way to determine scope constraints and avoid scope creep is do a list of what’s NOT in scope. This helps cristalise for the client/project sponsors what they’re not getting as the project output/product.
Nice piece Mark.
Some examples of skewed project triangles might help convey the message here:
“Each of the 3 constraints have be to considered when a change in the project occurs as one or more of these [triple] constraints directly are affected. When one or more of these constraints change it has a knock on effect on the others.”
Some pedantic stuff:
“As you could imagine the if the requirements as been added as a project is in the execution phase”
needs a rewrite.
…and a typo here:
“Another issue to watch out for is: in the initail stages ”
initail
…and here:
“Timeis”
…and it’s usually “gantt”, not “gant”
The ‘Triple Constraint’ is a bit like Douglas Adams’ definition of a trilogy. Sometimes Scope and Quality are considered jointly as Performance, i.e. what the product of the project actually does, and how well it does this. In addition, change request should also be considered under the headings of Risk and Customer Satisfaction as well - a change request that doesn’t impact Scope, Time, Cost or Quality, but reduces the impact of a negative risk should be considered favourably.
So now we have a triple constraint of six items. As Adams says, it brings a whole new meaning to the word trilogy….
Mark,
Interesting piece on the challenges of project management. I think an agile approach has a part to play - where resources and time are considered fixed in terms of delivering iterations of software, but requirements/features can vary according to the business priorities.
With an agile approach, you can found that costs are managed better as the team manages itself and is productive and that requirements can be varied according to the feedback and lessons learned from previous iterations.
Richie