Thursday, September 29, 2005

How many elements are there in the triple constraint?

In addition to the normal triple constraint elements:
1) Time (or schedule)
2) Resources (effort and/or budget)
3) Scope
discussed in this article, there are two other important elements to every project:
4) Quality
5) Customer Satisfaction

What if you delivered the scope on time and on budget but it wasn't up to the quality standards of your customer (or user of the product or service)? Would your project be a success. I think not! And what if you delivered the full-scope, it met the customer's quality expectations, was delivered on time, on budget, but you and your team were extremely difficult to work with? Would the project be a resounding success in your customer's eyes? Would they want to work with you again? Most likely not.

The article is dead on, though, in suggesting that the PM should be sure to ask the sponsor(s) to prioritize the "triple" constraint at the beginning of each project. Just remember that there are 5 elements and they are all important!

Triple Constraint--Friend or Foe?

Labels: , , ,

posted by FemPM @ 8:06 PM, Read More...  
5 comments links to this post

5 Comments:

At 11:09 AM, Anonymous Garry L. Booker said...

There is another way to express the Triple Constraint that is, I think, more pragmatic. It is:

1. Technical performance.
2. Schedule performance, and
3. Cost performance.

This is a client-centered perspective. Since everyone has clients, even those outside of the field of project management can appreciate this approach.

The reason this approach is more pragmatic is that a client has (ideally) already agreed to pay a certain amount of money and will allow a certain amount of time to accomplish certain technical objectives. The client's expectations establishes the constraints. In other words, spending resources and spending time are not true constraints -- being over budget and being behind schedule are the constraints.

A benefit of this approach is that scope, quality and client satisfaction fit neatly within the framework of technical performance.

Another huge benefit, not coincidentally, is that technical performance, schedule performance, and cost performance are synomymous with Earned Value Management. That is, EVM provides practical tools to integrate all three.

In an article published this month (http://www.metsig.org/docs/Sept_newsletter_final_final.PDF) I make the case that technical performance is always the top priority. It should come first in any discussion and any metrics program. Technical performance includes a clear understanding of what is required and desired (scope, quality, client expectations). Whether cost performance or schedule performance comes second is another client-centered question, and needs to be understood in advance. Ideally, this understanding should including acceptable margins of error called "exception thresholds."

/Garry
www.projectfrontier.com

 
At 1:00 PM, Anonymous Don Wynes said...

Playing the numbers game today: your list contains four items because Customer Satisfaction is a subset of Quality. (That is, you can't possibly have met Quality goals if you have an upset client.)

Then again, I'll offer a suggestion for getting the list back to five: Time should be on there twice!

Thanks for the great pointer to the source article; it's a simple question I don't think I ever asked in the straight ahead fashion suggested. I will now!

 
At 11:04 PM, Blogger Jerry Manas said...

All interesting points. One other perspective to muddy the waters further.

Considering that we're really using the triple constraint as a guide to make tradeoffs, one could say, "Well, if you want the project to be completed for a certain cost and by a certain amout of time, then we need to reduce scope".

But-- I've even heard 4 additional elements (giving us a total of 7 elements to consider): deliverables, quality, customer satisfaction, and risk.

For instance, keeping the above constraints of cost and time, could we keep the same scope (i.e still keep global regions in scope, all users, etc.) but do with less deliverables? Or could we use a lower acceptable level of quality (for instance a lower grade wood or a program with less features, which might be perfectly acceptable). This is different than customer satisfaction, and could indicate "grade".

Of course, we could also determine whether we could sacrifice some level of customer satisfaction (very hazardous in my eyes, but maybe there are cases where this is appropriate).

Finally, we could ask, "Could we live with the cost and time constraints and keep the same scope, if we could tolerate more risk?" Arguably this could relate to customer satisfaction, but maybe not.

At any rate, when considering tradeoffs, I think it's worth exploring cost, time, scope, deliverables, quality (which we could refer to as "grade"), customer satisfaction, and risk. Any or all could apply, depending on the industry and type of project.

Arguably, the idea of using technical performance, schedule performance, and cost performance could encompass all of these (save, perhaps, risk), but it helps to identify the elements individually if examinng tradeoffs.

All in all, a good discussion. I know it's been a matter of debate for some time in the field.

 
At 12:36 AM, Anonymous Garry L. Booker said...

Jerry,

Indeed, I do argue that all these elements fall neatly under the three broad categories: technical performance, schedule performance, and cost performance....including risk. There are three broad categories of risk that match the Triple Constraint: technical performance risk, schedule performance risk, and cost performance risk.

If we are going to include risk management -- and we should -- then I also argue that we should include its equal and opposite force: opportunity management. But once again, I think this can be divided neatly under three categories that match the Triple Constraint: technical performance opportunities, schedule performance opportunities, and cost performance opportunities. I hope I'm not beating a dead horse, but I really believe that the Triple Constraint is a robust model, and the number of primary elements in the Triple Constraint is still three. Yes, it is vitally important to identify subcategories such as scope management, deliverables, quality management, customer satisfaction management, 3 kinds of risk management, 3 kinds of opporunity management. That's why project management is a profession! :o)

/Garry
www.projectfrontier.com

 
At 10:28 PM, Blogger FemPM said...

All, I'm thrilled this post as stirred such good discussion. For what it's worth, PMI leans toward the 5 I mention also. However, I have heard industry leaders talk about risk as one of the contraints. I have to agree that risk has its place. Some organizations are willing to take a lot more of it than others!
Don't forget also that quality definitions vary - and in my mind, when you are on a project, you have to define what quality means for EACH scope item. Take a web page for example. For a content-only page, a quality deliverable could mean that there are no spelling errors and within 4 seconds the average person "gets the message". Alternatively on a page with a function, those same things are true but the function performs its duty successfully 99% of the time within 5 seconds. These could be the goals...but we all know what happens when Murphy arrives. One needs to juggle. Yes, an acceptable threshold is nice to know here - if we are hitting 95% of the time at 10 seconds, that may be acceptable for a first release. With the "fix" to occur during the "warranty period" - 2 weeks after the release. So, although this second example speaks highly to "technical performance", I'm not sure that many of the technical people I know would click with the term for the first scenario (spelling errors, etc.). But, then again, it's all semantics anyway as long as you know what you're doing...and it surely sounds like you folks do.
Again, thanks for the good thoughts. Keep them coming.
Best regards, FemPM

 

Post a Comment

Links to this post:

Create a Link

<< Return to PMThink! Project Management Gateway