NotesOn: IT Fundamentals – The Seventh Triple Constraint

Introduction (V1.2):

Everyone familiar with project manager roles (IT or otherwise) knows, or knows about the so called Triple Constraints (i.e. six have been identified and are widely accepted).  However.  There is a Seventh Constraint, a critical one to project success that, if ignored or slighted, can lead to project failure.

Background:

As a brief summary, there are six known “Triple Constraints”.  The original three are:  Scope, Time (Schedule), and Cost (Resources).  Three more were added later:  Quality, Risk and Customer Satisfaction.  You can find reference to these in PMI (Project Management Institute) related references, including Rita Mulcahy’s excellent PMP (Project Management Professional) Exam Prep book (the link to which is on my site).

However, while preparing my recent presentation to the Denver University Daniel’s School Of Business I realized that something was “bugging” me about the six constraints.  It wasn’t that I disagreed with them, for I didn’t and don’t.  But.  Nevertheless.  They somehow seemed … incomplete.  Something was missing.

As you may know, finding something that is not there and should be is more difficult than find something that is there that shouldn’t be.

The final recognition of the missing constraint came while I was writing “NotesOn:  IT Fundamentals – Simple Defined More“.   If you haven’t read it yet, I was debating the accuracy of (and thus value of) a thorough, in-depth, requirements gathering procedure that included drilling-down as many process levels as needed to reach the simple “consumable components” at the bottom of the stack.  To quote myself:

Often, in the past, I have seen this [analysis] process “sabotaged”, if you will, by:  too many predefined “hard coded” requirements, or by “my way or the highway” attitudes that will derail the entire process, or by “commitment” levels that are subject to whimsical changes, or by internal and/or external politics (empire building, etc.), or by someone in the Sales Group deciding that to get the contract a million dollars must be slashed (they don’t care from where), or by budget slashing, etc.

All of these non-process variables interrupt the time and resources required to truly work the process, from top to bottom (high level down to the logical consumable component level), and so forth as noted earlier.  Our current “instant gratification”, “rubber on the road” culture makes it difficult (though not impossible) to properly drive the entire analysis process.  …

That is when the “Ahhh-hahhh!” light bulb officially went on.

Constraint Defined:

Before going any further, it is important to define our terms in this case to define “constraint”.

The Microsoft Encarta Dictionary’s applicable definition is:

“1.  Limiting factor – something that limits freedom of action”

Merriam-Webster’s On-line Dictionary includes these two:

“1b.  the state of being checked, restricted, or compelled to avoid or perform some action

“1c.  a constraining condition, agency or force”

So, for our purposes a constraint is something that limits the freedom of choices for, and possibly the ability of, a project team to take up and complete a project.

The first six Triple Constraints have been around for some time.  For example:

Cost is a significant factor in constraining a project.  If you propose a $1.5M project and the client only has $0.5M you have an “issue”.  If everyone agreed on $1M but you starting running out of money half way through the project, you have an “issue”.

Customer Satisfaction may not be so apparent until you consider two of the rules of IT:  (1) that you must, must partner with the customer throughout the project, during all steps of the PMLC and the SDLC; and (2) that you may have developed the best system in the world, but if the customer is not at all happy with the result no matter what the quality then … you have an “issue”.

Does this make sense?  That a constraint is simply a limiter, in some way, on a project?

Constraints are necessary.  After all, no one can afford to build an un-specified project for a non-specific amount of time for an unknown amount of money, etc.

Constraints are neither inherently, natively, good or bad.  It is how they are applied to a project, and then managed, that makes them tip one way or the other.

So what is the Seventh Constraint?  Let’s find out:

The Seventh Constraint:

The seventh constraint is very simple, straightforward and terribly, terribly obvious.  It is so obvious that it has gone unstated for decades.  A case of “everyone knew”.

Even though everyone in the field of, or within reach of the field of project management does know, or should know about, this constraint … it absolutely positively needs to be officially called out, it needs to be stated in bold letters because:  failure to recognize the seventh constraint too often directly results in failed projects (however you define failure).

So what is the seventh constraint?

The Seventh Constraint is:  Commitment.

This includes the Commitment of and from the project team.  And.  The Commitment of and from those in the environment surrounding the project and  project team.  Such “outsiders” include (but are not limited to):

• Members of the Board of Directors
• Senior Executives
• Managers
• Users
• Outside Vendors / Suppliers / Consultants

All of these folks, and more, can, wittingly or unwittingly sabotage a perfectly good project … due to their lack of commitment to that project.

I don’t believe it is necessary to list out examples of “lack of commitment”.  A few are noted above, but anyone ever associated with a project has their own stories to tell.

By the way, don’t read more into this Constraint (and post) than is present.  There are other root causes for failed projects.  But.  Failing to identify, and recognize, Commitment as a constraint too often can be one.

Summary:

When you are planning your project, please make sure that you pay close attention to the Seventh Constraint from the beginning to the end.  The symptoms of wavering commitment are many, the results are not.

Hope this helps,

DP Harshman

PDF Link