I will make an attempt to put this argument into perspective, but try not to be so arrogant as to come up with an end-all answer to this argument (although towards the end I will try to 'illustrate' my method managing a project).
PMIs Triple Constraint
As defined in the PMBOK, the Triple Constraint is: A Framework for evaluating competing demands. The triple constraint is often depicted as a triangle where one of the sides or one of the corners represent one of the parameters being managed by the project team.
As such, it is just a 'framework' for evaluating 'competing demands'. The fact that it is 'often' depicted as a triangle does not mean that it is 'always' depicted as a triangle or that there are only 3 elements to the triple constraint.
Also, throughout the PMBOK guide - third edition, there are only 2 references to the Triple Constraint; once where it is defined (page 378), and once where the constraints of project scope, time & cost are also said to be affected by quality, risk & customer satisfaction (page 8).
Basically, in PMIs approach, the triple constraint is the collection of 'constraints' (not necessarily three) that are interconnected and any change in one of the constraints will have an affect on another. PMIs nine knowledge areas are the areas that every Project Manager should have knowledge of and be able to manage - Integration, Scope, Time, Cost, Quality, Human Resources, Communications, Risk, Procurement. So, in essence through the knowledge areas, PMI has increased the triple constraint from three constraints to nine.
Rita Mulcahy's Approach
In Rita's books (PMP Exam Prep, Fifth Edition: Rita's Course in a Book for Passing the PMP Exam & Risk Management, Tricks of the Trade) she considers the triple constraints to be of cost, time, scope, quality, risk and customer satisfaction. So, she thinks that there are six elements to the triple constraint.
Finding Common Ground
In my opinion, everyone is talking about the same thing but they are approaching it from a different view. If you really think about it, quality can be considered a part of scope (since it should be defined prior to the project by all stakeholders), and customer satisfaction can be considered a part of quality (since the customer will be one of the stakeholders and he will have a say in how the quality is defined and hence how the scope is defined) or the customer can also be considered a part of time since he will be driving the schedule. And finally, Risk is the unknown part of all the constraints. It is all about planning on how to react to an unexpected event. So, depending upon whether the Risk is related to cost, sope, or time, it can be considered part of the initial three elements of the triple constraint too.
My Approach
The way I manage projects, I take into consideration all the constraints of:
- Cost
- Time
- Scope
- Quality
- Risk
- Customer Satisfaction
- Integration
- Procurement
- Communications
- Human Resources
Summary
The 'Triple Constraint' refers to the framework for evaluating competing demands. How many elements this triple constraint has, depends a lot on the nature of the project. As a PM, we train ourselves to see these competing demands in our head, and make all our decisions in light of the fact that every decision that affects one element of this framework will have an impact on at least one other element as well.
© 2008 Saad Farooqi
2 comments:
Excellent post and topic! Personally, I typically use cost, time, scope, quality and risk as the constraints. Maybe we need to come up with another name as triple generally refers to 3. :-)
The other aspects; integration, procurement, communications and human resources can easily be seen as part of the other 3 or 5 constraints. I view customer satisfaction as a primary deliverable not a constraint. Maybe it's a semantic thing.
I don't see how the original triple constraint view of the project could ever become obsolete. Time, cost and scope are so fundamentally important to projects that making them less important or viewing them as "old thinking" seems absurd.
As I stated above, I add risk and quality to make 5, but really risk management is not a constraint but the primary function of a project manager.
Michael
We're both on the same page. Basically, every PM develops their own methodology through time, wherein they may view some constraints as having more importance than others, like you, in your projects, consider Risk to be a primary function of a PM or consider customer satisfaction to be a deliverable. This will all depend upon the industry, nature of the project, and the team that the PM surrounds him/herself with.
Post a Comment