Is the Triple Constraint the WRONG way to Define Success?

Thanks for the clarification, Dave!

The more I think about it, the more this situation reminds me of the speech I presented in my Toastmasters meeting last night. I started out discussing "Meaningless Management Mantras" such as "Do More With Less" (the title was actually MeaningFUL [emphasis added] Management Mantras). They had meaning at one point, but the meaning has been lost or changed, over time, through misuse, abuse, or some other reason, and now they are mostly ineffective (but they don't have to be).

I am not saying that the triple constraint is ineffective, but I am suggesting that it is possible that it is not being used effectively. To be honest, the only people that I have worked with that even understood it have been other project managers. Maybe the shortcoming of the triple constraint is that people don't understand it. I think adding the measuers that Shenhar suggests would be great (allowing for variations due to differences in projects), but that won't solve the problem if the problem is that people don't understand the concept. Thoughts?

Aaron

Posted: May 29, 2008 6:10 PM

Risks are not constraints but risk aversion is. If risks are clearly spelled out risk adverse decision makers may have second thoughts. You must define risks and mitigation tactics but be prepared for push back.

"So of course you need to keep the elements of the triple constraint in mind when delivering projects, but should they be the focus of your efforts?" -- Simple answer is ''yes, but.'' But -- the most important focus for the project manager and team is the business objective and that can't be completely captured with time/budget/scope. The project is designed (or should be) to accomplish some business objective. That should be the over ridding focus that time/cost. budget serves.

As to quality in my experience its part of scope. If we fail to define quality objectives we will be in for surprises along the way. Is the system to be bug free? Highly resilient? Or are work arounds acceptable (due to cost/time constraints maybe.)

BTW -- Re the triple constraints -- I wrote an article about this in 2001 -- "Sign in a Bicycle Repair Shop" Its here -- http://www.gantthead.com/content/articles/18999.cfm

Bottom line is -- know what your project''s goal is or all the on time in budget success might accomplish nothing.





Posted: May 29, 2008 7:35 PM

Dave, the perspective you describe is indeed much more interesting than the traditional triple constraint. To me, project success actually looks more like a spatial construct rather than a 2-dimensional figure, more like a pyramid with an octagon as a base (1 side for each knowledge area other than integration, which is the area of the base) and customer satisfaction as the tip of the pyramid. I’m actually preparing an article explaining this in more details, to be submitted to gantthead.com in upcoming days.

Regarding current and future needs, I think that these play a key role in project selection, not in the project success. It could be argued that meeting the intended achievement of current and future needs would be a measure of success – from my perspective meeting the needs are included into customer satisfaction so they should not be treated as separate metrics.


Posted: May 29, 2008 9:45 PM

Norman, I don't think quality and scope are quite the same thing. My interpretation is that scope is defined before the project begins, and is an input to the quality measurement. However, quality is the measurement of how closely the product of the project met the requirements. Requirements are not entirely the scope.

Posted: May 29, 2008 9:57 PM

Dave,

I think the triple constraint, or whatever revision succeeds it, is simply like a mathematical theorem. It is a natural immutable law. It is simply a fact that there are tradeoffs among the 3, and perhaps the 4 or more, depending on revisions. But the measurements you mention are metrics which can measure project success and focus the team on measurable goals. Regardless, the "triple constraint" holds true.

Posted: May 29, 2008 10:03 PM

Dave,

Understanding the goal should focus where to apply constraints - triple or otherwise. Metrics allow for the understand of how we are applying the triple constraints, but the triple constraints won't tell you if your project is successful. Only your customer - the one requesting the primary deliverable - can let you know if you've met their expectations.


So while it is possible to deliver late and over budget, and still have a satisfied customer. It is essential to know where you are in the delivery cycle - you must know if you're off schedule and over/under budget. How else can you accommodate changes in scope? So while I like to think that the customer satisfaction is the final arbiter of project success - managing the triple constraints is the only way I know of to get there.

Posted: May 30, 2008 8:34 AM

Dave -

Thanks for this topic and your clarification, it seems to have resonated with many folks.

Norm -

Great point, thanks! To me, quality is the squishy underbelly of the triple constraints. Here is how I see it . . .I would posit that quality constrains a project. Quality has two key components: conformance to standards and/or requirements; and fitness of use. In other words, the service or product has to meet the standards and it also has to actually work. If I create something that exceeds the requirements, I am meeting the quality standards but exceeding scope. It is semantics, and we could debate this all day and never agree about whether I exceeded scope or quality or both. Heck, I changed my mind twice while writing this. But the fact remains that conformance to standards and fitness of use constrain a project as much as scope or cost or schedule. Donald's example of the Sydney Opera House above is wonderful. If this project had come in on time and on budget, the scope and quality would have definitely suffered. I think this is why quality always goes to the center of the triangle - it is so utterly connected to the other three constraints. The thing about quality is that we usually see it from two perspectives: is the product imbued with a degree of excellence (how good is it?). And just as important, does it have any defects (how poor is it?). This dichotomy, in my opinion, is what makes quality more complex.


Posted: May 30, 2008 8:34 AM

@ Dave: Is it possible to rank, in a general way, his five success measures? Or does that vary too much by project? I believe it is possible, and should be done right off the bat after the charter is approved. Every project will have to tangle with these 5 elements regardless of its unique qualities. Here at the "ranch", we go through a value ranking with our project customer. We work through an exercise to discuss how to stack these elements (and others) to understand what should take precedence when there will be a trade off later. As a PM, I already know these value rankings will be thoroughly challenged later when the pressure is on, but it sincerely helps our customer to start thinking in these terms. This thought exercise forces some conversations with the customer that would have never happened before, and puts many unstated assumptions out in the bright light of day. You get an excellent opportunity to see inside the customer's head and understand their point of view as a result.

Posted: May 30, 2008 9:13 AM

Norman,
In my world, exceeding what was requested by the customer is a cost. It took extra effort that was not estimated to complete that component along with the many others that are required for a business application to work. Just my observation. ;-)


Posted: May 30, 2008 11:44 AM

Organizations should determine which methodologies they are going to use as standards but they should still customize them to fit their culture. Does the organization have a mature PMO, certified PMs and trained sponsors? Who holds the keys to the triple constraint?..the sponsor. Who negotiates with the sponsor on any of these constraints for alignment?....the project manager. Who is responsible for managing customer expectations? ....the PM and the sponsor.

I agree with Shawn's point that the triple constraint is just a tool. Also, I think quality is the fourth element but I think that the PM and the team need to work to build this into the project. Just because you don't have a QA department or a QA specialist, doesn't mean you forget quality. You should look for ways to build in quality. Also, I also agree that risks are not constraints; they are identified, mitigated, accepted or avoided/eliminated.

Project success should be defined by measuring the project delivery, product delivery and critical success factors. Project success will also be determined by an engaged sponsor, strong PM, team and business partner. Project management is an art and science and those PMs who juggle these well will define project success over and over again...



Posted: May 31, 2008 9:45 PM

Great discussion - so far I think that we as PMs agree that the 3C is something which we should not give up, we cannot do proper monitoring and controlling of our activities and deliverables if we have not set any scope, cost or schedule against them. I am wondering about the term success criteria - as I recall (please correct me if I am wrong) we define success criteria for both the product and the project - that is if we are working in line with the recommendations of PMI, I do not seem to recall that PMI "orders" us to have manage success based on 3C... In my opinion the success criteria for the project and product can be combined and can also be completely separate - lets say the contract states a payment date, that would for me be a constraint which relates to 3C and which I would manage towards on the other hand I could have success criteria which is managed outside the 3C but only to a certain degree and this would again become an interpretation of how much detail we define in our scope - many stakeholders want the project to get moving, which in theory leaves us with some unclear parts of the scope and on the expectations - which again leaves us with more risks and perhaps a rougher estimate on the cost and schedule, which then again leaves us with the criticality of the project - have you realised/experienced that very business critical project have more open boundaries for budget and resources hmmm, communicate communicate communicate and the add the basic monitoring and controlling activities - then you can deliver successful projects with the benefit of 3C.

Posted: Jun 2, 2008 10:34 AM

I think one has to be cautious not to over-generalize. All projects are subject to the triple constraints, but not all projects are subject to identical risk management methods, or quality methods. What works great, relative to quality , scope, and risk management, in one business vertical does not automatically transfer over to other verticals with equally great results. Organizational culture matters as well. So I will say there is no substitute for a Project Charter that adequately defines Project Success and how it will be measured. The number and frequency of Projects with no Charter, no Scope documentation, seems to me to be increasing. In my opinion this results in a need for PM practice clarity and improved PM methodologies that might not otherwise exist if a well written, well developed Charter and Scope document was in place to begin with. Absence of such a foundation document certainly increases project risk impacts, and the PM workload needed to mitigate risks spawned, or exacerbated, by a lack of clarity, precision, and understanding of the Project due to no Charter and no Scope document. If customer satisfaction outweighs cost, time, scope, quality or risk constraints, then this needs to be stated in the Project Charter. If a specific risk management methodology is to be utilized, or other specific elements of the definition of Project Success exist, then these should be clearly stated, or included by reference if stated elsewhere in corporate policy statements (ITIL, ITIM, CMMI, etc). One measure of a well developed, well written Project Charter is that it is reviewed, referenced, and cited in meetings and discussions, especially scope, quality and risk discussions.So, the question I would ask to clarify the above discussions is this: "In the project you are referencing in your post, when was the last time the Project Carter was referenced in a risk, scope or quality discussion?" If the answer is "never" then either the Charter is inadequate or doesnt exist, or the PM needs to review the Charter and use it as the baseline to discussions, it seems to me. I am highly dubious of the need for other constructs, pyramids or whatever, as generalizations that are guaranteed to work for every Project, in every Culture. Nor do I believe one should infer that the Triple Constraints automatically define success for all Projects – rather – the Project Charter should define success in terms specific to and appropriate to that Project. Thanks Larry

Posted: Jun 2, 2008 10:40 AM

We're a very young project management team at my company and we had a discussion recently about how to define a successful project. The meeting leader said success will be measured by the project coming in on time and within budget. He failed to mention any other part of the constraint, and any other topic that has been discussed as a reaction to this post.

I strongly objected, about to launch a large overhaul to our web based calendar tool for our largest client, which was already way over budget and significantly delayed. Because we had made some major resource changes to the development team and brought in newer more junior people and transformed a small team of senior programmers into a larger team of Jr. programers (with all of the issues that come with a larger team - communication, subdividing tasks, people needing to wait on each other to finish working on files)...it got messy.

But, we got through it and still ended up launching a system that met our clients needs and was relatively bug free at launch. This was the big success. To me it''s about the fact that a decision was made to drastically change the programming team, knowing the impact it would have on schedule and budget (and potentially quality had we not been careful enough), and despite those challenges we made sure that delivering to our client''s needs was the top priority, putting schedule and budget below that. Maybe I'm way off here and maybe I didn''t handle that risk well enough. I''m still very happy with how things went.

Posted: Jun 2, 2008 9:21 PM

I agree it is time for change - but change needs to be managed carefully.
I have been using the triple constraint concept for a while now with a small twist. I have found it more acceptable to larger and more diverse groups. I transpose as follows:

Quality = Value

Scope = Good
Cost = Cheap
Time = Fast

What do you think??



Posted: Jun 3, 2008 10:58 AM

Again, I think we are all agreeing on a common theme. I would just like to elaborate on my thoughts on establishing threshold tolerances in the areas of scope, time, cost and quality constraints. The risk we face in seeing all of these constraints as absolute is that (a) the natural law of the universe suggests that we will generally be unsuccessful in failing to achieve all four in some fixed constellation of values, and (b) we potentially encourage the immature client or sponsor to invoke arbitrary or unrealistic constraints.
So all I advocate is a robust and mature dialogue between PM and client at the start of a project, to find out what is driving the project from a business perspective so that an educated and achievable view of constraints is established. As one author has pointed out, in a simple business transactional model, the constraints may be more simplistic and fixed but I detect in my own global ramblings that our practitioners are addressing a range of project models from more simple transactional to more complex business driver based projects.
The outcome of this is a mature understanding of where the genuine constraint tolerances are, which are more dominant and less flexible, and which may ( I stress, may) be less imperative and hence more flexible, from an objective understanding of the external and internal business drivers. Without doubt any trend in this area will be incremental as we would understand a tendency for clients to think that they are showing weakness by not articulating absolute, and occasionally arbitrary, constraints. At the same time, it behooves project managers to show professional behaviour, and not consider that such constraint dialogue or threshold understanding is a licence for sloppy planning and/or control.

Posted: Jun 4, 2008 12:03 AM

It has been a long time since I have measured projects solely against the triple constraints. Sophisticated and success driven clients have long looked deeper into what defines success in a project.

The triple constraint concept remains the base measure for project control, but not for success. As described by classic project theory, the planning phase explores all possibilities by all stakeholders resulting in a clearly defined and fixed scope. The planning phase remains essential and deserves as much time as is practical depending upon the nature of the project, however very few projects remain as defined early in the process.

This speaks to the reality of our world and the need for an agile management approach – except in the most tightly defined of efforts, we don’t know the true depth of a project we have completed it. As Project Managers, we establish and control a project within the constraints defined by the stakeholders. This extends well beyond the triple constraints to include the factors Mr. Shenhar describes.

Overall, our job is to ensure that a concept is implemented meeting the expectations of the stakeholders. The key is the phrase “meeting the expectations.” Expectations include not only scope, budget and schedule but also the intent of the project. The reality is that early in a project, very few stakeholders completely embrace the entirety and nuances of the changes to their business that most projects of size entail. This is not a criticism, it’s a part of what we do – ensure that as stakeholders come to realize a deeper complexity to the pre-defined requirements, we adapt the project (through an approval process) to ensure success of the project goals.

Posted: Jun 4, 2008 7:01 AM

Thanks for the summary of the concept, I am looking forward to reading this book. I expressed my initial thoughts here.



Posted: Jun 4, 2008 7:58 PM

Dave

Thanks for sharing the toughts of Aaron Shenhar with us. I do agree the triple constraint or the devil''s quadrant is too limited to manage a project, however since Scope, Time, Quality and Costs can be measured in a SMART way it is ideally for progress tracking.

What Aaron calls efficiency I would call financial tracking. All parameters can be translated into costs

The second aspect to pay attention to is the business needs in terms of
- Can the business support the outcome of the project (Business Change Management often not a part of an IT project)
- Will this increase the revenue and/or profit?
- Will this help the -end-customer or consumer

The above can be partly checked during the business case and secondly during the progress meeting by asking if there is anyhting we can do to improve the relationship, communication, etc. In this way it becomes obvious if the project still meets the business needs, the personal need of the project sponsors etc.

Finally during my team meetings and/or one to ones I am interested to know if my team members consider their work according to their ambition and challenging. Is the project successful in their eyes.

Saying all this Iit is more or less in line with the toughts of Aaron but also with the Balance Scorecard toughts of Kaplan Norton back in the 80''s.

Define your financial, external and internal criteria and finally define the future, which is in case of a project the change when the project gets implemented.

Posted: Jun 6, 2008 3:47 AM

The triple constraint focuses the mind, as an example in the UK, one of the largest projects underway is the 2012 Olympics. The timescale is fixed, the government insists that costs cannot rise, so we are left with scope. So already some of the more grandiose schemes are being cut back.

To meet the timetable scope, and eventually more cash will have to be sacrificed to get the games open on time. However it is worth bearing in mind another lesser known law of project management which involves the gestation time of elephants: There comes a time when however many elephants you throw at it, the gestation time remains the same.

Posted: Jul 28, 2008 7:33 PM

First, I would like to agree with the suggestion of several other commentators that Scope = Quality. I would assert that you cannot have a comprehensive discussion of scope (what we are doing) without talking about the quality standards by which our products and efforts will be evaluated.





I also include under "scope" compliance with process constraints and local practices, performance, reliability, etc.





Someone else had commended Shenhar's book to me (I'm only part way through) and I think it has some VERY interesting ideas in it that I would add to scope... his notion of what kind of team capacity will we have when we are done, for example is a very good one.





Someone mentioned the balanced scorecard... I think that Shenhar really moves the ball down field by expanding some of those concepts into project thinking, however I would assert that they still fit under the triple constraint (again, under sope)





I disagree with some of Shenhar's analysis, however. He gives an example of the Sydney Opera House as a project that blew out the triple constraint (something like $105M to finish a project with a budget of $7M) and suggests it was ultimately "successful" when judged years after the fact. I would disagree, unless there were a series of conscious changes along the way that extended the schedule and budget.





I don't know the details of the political situation in Sydney, but if I were the mayor of Sydney and had sold the city on a $7M investment that subsequently drove the city into tight financial straits because of cost overruns, the fact that tourists like the opera house (after I was driven from office and several other community projects were scrapped to pay for the boondoggle) would not make it a success in my eyes.





As project managers, we must NEVER lose sight of the fact that the sponsors (people who are paying for the project) get to decide what success means, and it should be written down as best we can to record the goal for ourselves and our successors. It is incumbent upon us project managers to seek a broad definition that considers some of Shenhar's interesting ideas, but THE SPONSOR'S GET TO CHOOSE, we merely advise and then try to find a credible way to deliver what we were asked to deliver.

Posted: Jul 29, 2008 4:40 PM