TOPIC: So constaints have ballooned....

...from the old and well understood "triple constraints" of scope, time and cost to now be 6 (or more). After reading this I'm struggling with understanding how the "new" constraints are separate from the old constraints. For instance we now have quality and risk added as constraints but in my mind dealing with them will still affect one of the original 3. Can someone explain how the additional 3 (or more) constraints actually enhance the PMBOK that we have to work with?

Erik,

From my point of view, nothing has really changed.

I know this is a strange thing to say, so let me explain:

The "traditional" triple constraints are a metaphor that allows you to explain to someone who is new to PM that these constraints affect each other. If you change one up, then another one needs to go down. However, nobody ever agreed upon what these "traditional" triple constraints really were. Some people even had a list of 4 triple constraints.

Over the past few years the prevailing opinion was that the "traditional" triple constraints really don't represent the real life project environments. Everybody KNEW that we had a multitude of constraints that affected each other in untold ways, but the image of these "triple" constraints was so ingrained in our teaching and thinking that we kept using the it.

So in this update to the PMBOK Guide the PMI is simply documenting what's really happening on all our projects: We have a multitude of constraints.

- The skill level of our resources affects quality
- Increasing quality requirements affects cost
- A cut in our budget means we cannot hire skilled resources
- Unskilled resources will affect our project schedule.
- Cutting your schedule back by two weeks will lower your budget but affect your cost and resources.

We look at this quite in-depth in episode "E01.36 Competing Project Constraints".

But in the end the concept is a simple one: If you make a change to one area of your project you will affect another.

Thank you for your reply Cornelius. I agree that there are, and always have been, a multitude of constraints in a project. My point is more of a philosophical issue. It seems to me, based off of my own experience, that regardless of the trigger for a constraint..be it a risk, or quality issue etc..that the end result will roll up into affecting your scope or time or budget or all three (most likely since they are tightly linked). I think the ambiguity is that no one seems to have placed a qualitative value to any of the constraints so that a new PM can get a concept of the hierarchy of importance. Wouldn't that be a better approach than adding new "constraints" at a peer level with the traditional definition? Your thoughts?

Erik,

Per definition, each project is unique.

Some of them are resource constrained, some are budget constrained and others are time constrained. So the "hierarchy" of constraints changes with each project. If you must have your project finished by October come rain or shine, and then the default hierarchy says that the budget has the highest value in the hierarchy you will just laugh at the system.

So I personally see no need for such a hierarchy - but I bet that a book on this topic would sell quite well...