*One concept from PMBOK® Guide Chapter 1 is entitled Introduction is that of constraints on a project. The reason why I’m including this belatedly in my series of blog posts for chapter 1 is because there seemed to be a difference between the popular notion of a constraint in the world of Project Management today, the definition according to the PMBOK® Guide, and the definition according to some of the PMP Exam prep guides. This post takes a look at the evolution of the concept of constraints.*

1. Original definition of constraints (from 1969)

Dr. Martin Barnes first put forward the idea of an iron triangle of time, cost, and output, which he defined as the “correct scope at the correct quality.”

Fig. 1 Iron triangle of constraints (original concept)

The basic concept behind this schematic was that a change in one of the constraints would affect the other constraints. If you want higher quality, it will take you longer and/or more money to produce the product of the project. Or if you have less time than you thought, you will have to pay more to get it done on time or you may have to sacrifice on quality.

Pretty clear, right? This became known in time as the “triple constraint” of time, cost, and scope. This is the common-sense view of the concept of constraint today in the world of Project Management.

In fact, one of the members of the study group was asked the question “what are the constraints on a project” and she answered back, “time, cost, and scope” and got a lot of positive feedback for knowing the “right” answer.

2. Project Management Institute’s current definition (2011)

Now in chapter 1 of the 4^{th} edition of the PMBOK® Guide, the constraints are unceremoniously listed as the following (on page 6):

- Scope

- Quality

- Schedule

- Budget

- Resources and

- Risk.

If I tried to reproduce the same type of diagram as in Fig. 1, the first approximation would be:

Fig. 2. Project constraints (modern definition)

But wait, I would have to add arrows in between each of the six points, yielding a total of 15 diagonals or relationships between the variables.

Yikes! What has happened to the “simple iron triangle”? It is now the “hopelessly complicated hexagon.”

3. But, wait, there’s more…

Not to be outdone, Rita Mulcahy’s book adds a 7^{th} constraint to the mix, namely, that of “customer satisfaction. Oh, great, now we have a heptagon …

Fig. 3. Project constraints (Rita Mulcahy definition)

This creates a total of 21 relationships between constraints, which I will not add to the above diagram for fear of confusing the reader. What a mess! The loss of simplicity from the time of the “iron triangle” description of constraints was lamented in the excellent blog post in the blog Mosaic Projectsby Pat Weaver and Lynda Bourne:

http://mosaicprojects.wordpress.com/2009/11/19/the-demise-of-the-iron-triangle/

What went wrong? Well, it’s not the Project Management Institute’s fault for wanting a more complete definition. Blame it on a paradox of mathematics called …

4. Gödel’s Incompleteness Theorem

The problem of the definition of constraints getting a little unwieldy as it tries to be more complete is a concrete example of Gödel’s Incompleteness Theorem, which states in the realm of mathematics that:

Any effectively generated theory capable of expressing elementary arithmetic cannot be both consistent and complete.

If you try to limit yourself to just using natural numbers used for counting, the system is consistent in that there is no equation such as 2 + 2 that yields two different answers. However, there are some equations such as 2 – 4 that yield NO answers so it is not complete. So, add the negative numbers, and you’re set, right? 2 – 4 = -2, and it is consistent and complete because there is a right answer and only one right answer. However, this creates new problems in different areas such as x^{2 }= 2 that don’t have answers in this new expanded theory. So it is still not complete. And so forth, and so on, if you add irrational numbers, complex numbers to the mix. There is an essential tension between the completeness and consistency of a theory that is built into the very fabric of mathematics itself.

The early “iron triangle” theory was consistent in that it yielded a very fundamental insight, i.e., you can’t change one constraint without it affecting the others. Hence the popular engineering cliché of “faster, cheaper, better—pick two. ” This is a flippant comment, but it has deadly serious consequences, as the Challenger disaster showed that the government’s insistence to NASA, that it improve on all three elements of schedule, budget, AND quality simultaneously, was disastrously uninformed.

So in a well-meaning update of the constraint theory to make it more complete, it has lost that consistency or coherence it may once have had.

5. All is not Lost

However, if you take the original idea behind the iron triangle, i.e., “changing one constraint changes the others” and apply it to the increasingly long list of constraints, I think you’ll save the baby without having to throw out the bath water (to introduce my own cliché).

In reality, if you consider the laundry list of constraints listed in the PMBOK@ Guide, they sort of map onto the old iron triangle in this way, with the iron triangle definition of constraints on the top, and the new PMBOK@ Guide constraints underneath them.

In the end, our discussion of this in our study session proved that the new definition of constraints, although more complete, was not as consistent or as coherent as the old one.

I can just imagine if the study group member who was asked “what are the constraints of a project?”, instead of the snappy one-liner “time, cost, and scope”, had answered “well, it’s like a 7-sided polygon with 21 relational diagonals.” She would have either gained points for being brilliant or would have engendered an open-mouth stare on the other side of the table. She was better off with the old definition in the interview.

Filed under: Uncategorized |

## Leave a Reply