New technologies, concepts, and Web 2.0 tools are popping up everywhere. How can you use them to help your project team collaborate, communicate - or just give your project an extra boost? [Contact Dave]
Situation: You want to take a broader view of managing projects.
My new favorite author spoke at our local PMI chapter meeting last night. Aaron Shenhar's book, Reinventing Project Management gives you a LOT of food for thought, but I think that one of his points is truly a breakthrough concept in our field. It cuts to the core of why there is so much controversy around PMBOK-based approaches and Agile approaches. In his presentation, given mostly to PMPs mind you, he says, "PMI has given us a great foundation. However, it's time to leave that foundation and go to the next level."
During his talk, he described a number of reasons why the standard approach to projects must change. A lot of it sounded rather "Agile" in nature. For instance, he talked about the Triple Constraint theory as being a key impediment to successfully delivering projects - because it incorrectly defines the success criteria. He said, success should not be defined just in terms of Scope, Cost, and Time - which are strictly efficiency-based. The focus should be more on business results and customer satisfaction.
His definition of success is broken down into the following categories: - Efficiency (criteria similar to the triple constraint) - Customer (criteria = customer satisfiers) - Team (criteria = customer satisfiers) - Business Needs (criteria = things like ROI, strategic fit, and competitive advantage) - Future Needs (criteria = future value, like in the case of new technology where much of the value is yet to be defined)
His theory (he describes it as 'project manager as mini-CEO') is "If you approach projects with this broader set of success criteria, you will be a better project manager, because the results will be better." It's hard to argue with that.
It feels to me like he is calling for us to combine what PMI is starting to address separately as leadership skills with the PM approach in general.
How do you define project success? If the Triple Constraint good the way it is or should some of these higher level issues always be considered when managing projects?
Hallelujah and it's about time! I completely agree. The triple constraint is useful information, but it is not the be-all/end-all of project assessment variables. (Us quality-nerds have been harping on this for years.) It is time to rethink our gold standard as PMs to incoroporate these facets of quality management and customer satisfaction.
Organizations that have formal quality management systems in place, or some type of scorecarding process probably already measure these indicators or similar ones, but the new thing is to formallly incorporate them into the project management ethos. Break the iron triangle and create a 360 degree understanding of project success.
Being able to understand the tenuous relationship of all these variables and synthesize them for optimal customer benefit is the sweet spot. I believe many things have to align in an organization to reach this capability though. Here is an opportunity for growth and application of these knowledge areas in more cross-functional ways. A good thing!
The problem with the triple constraint model is literally that it falls flat. It falls flat because it is two dimensional. A triangle just doesn't cut it. You can tell this is true when you hear PMs and PM educators try to talk about the three constraints of Cost, Quality, and Time, and,, er...Scope. Wait! That's four. And where does Risk fit in?
See?
The problem is that we need to get some VOLUME into what is a flat model. How? By making it three dimensions. The Egyptians had the right idea - pyramids. This subject will be key to our new book, "The Fiddler on he Project", in which we'll lintroduce the 3-dimensional "Constramid(R)" that takes Time, Cost, Scope, Risk, and Quality into account in a highly-intuitive model that even has a physical place for the project manager.
The best part is that you can help write this book with us, because we are expermenting with collaborative writing for this project.
Visit our wiki at http://fiddlerontheproject.wikidot.com and check it out.
The triple constraints are just tools. They are valid in helping the PM and sponsor shape basic planning, scheduling and control issues and problems. However, these are not true measures of project success. A project can deliver on all three as well as agreed-to scope (which, by the way, is represented by the size of the triangle - don't tell me otherwise, I will argue with anyone on this forever!), and still be a failure if the business case was not valid or changed mid-project, or if the end users are unable to use the perfectly-executed project deliverables.
New ways of assessing a project add dimension to the evaluation and planning processes. They also, however, raise the debate of the role of the project manager. I do not completely agree with the ongoing movement that posits that PMs should be justifying their projects, making their business cases, etc. That's the sponsor's job - the PM helps. This is where the additional dimensions of project success and evaluation can help all involved to do their jobs more effectively.
This is the latest trend in PM, as project managers are increasingly called upon to be business managers as well. Kerzner talked to our local PMI chapter about this in January, and now I'm hearing about it all over the place.
I think most PMs (except perhaps those that manage a very small part of a larger initiative) have to think about value (business results and customer satisfaction) delivered with the project objectives (time, cost, scope). I remember the first major project I managed, the implementation of an IT system for an outsourced call center to perform wireless prepaid phone activations. The requirements were very clear cut - the system had to perform all the steps of activating new phone service, with minimal knowledge on the part of the user (as these weren't our internal experienced reps, and they wouldn't have access to backend systems to troubleshoot or look up information), and it had to be done in 6 months. Even in that first project, as I furiously employed project management skills, documenting scope and budget and timeline, managing change controls, providing eloquent and timely status reports, my manager said one thing that stopped me dead in my tracks. He said, if you deliver this project on time, on budget, and exactly what you said you'd deliver, and the business hates it in a year, they aren't going to remember that you delivered it perfectly. If it's 2 months late and double the cost that was budgeted, but it's exactly what they need/want, in a year, they won't remember the pain of getting it up and running.
I've managed my projects by that advice ever since.
We know that the discipline of project management is about providing the tools and techniques that enable the project team to organize their work to meet specific constraints. Thus, most projects have specific schedule or time limit, budget, and scope. Understanding the project triangle or the combination of elements (time, money, and scope) will allow us to make better choices when we need to make tradeoffs.
Another approach to project management is to also consider the three constraints as finance, time and human resources. So, if you need to finish a job in a shorter time, we can throw more people at the problem, which in turn will raise the cost of the project, unless by doing this task quicker we will reduce costs elsewhere in the project by an equal amount.
These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.
But it seems that because of the rapid changes in the global market scene, the intangible factors more than the tangible elements have become the greater determinant of project success.
Management as a whole and project management in particular, are moving towards facilitation and support of collaborative activity, utilizing principles such as those of human interaction management to deal with the complexities of human interaction. That is why we talk of multi-dimensional constraints as we interact with the various facets of our micro and macro environment.
New terminologies such as human capital, intellectual capital, social capital, structural capital, relational capital and stakeholder capital are becoming buzz words in management especially in this era of the knowledge economy.
Because our society is rapidly becoming a society of organizations, institutions have the responsibility to fulfill basic social values, beliefs and purposes. Organizations will have to learn to make the quality of life compatible with their main task through management. This is because management encompasses the deployment and utilization of human resources, financial resources, technological resources, natural resources, etc.
The need to know more about project management beyond the definition but into practice, people, culture, processes, tasks, levels and application is therefore very crucial.
Is the triple constraint the wrong way to define success? I believe that it may no longer be the only way, but certainly they can provide the core tangible elements in determining project achievement. The intangible factors (R&D, design, services, etc.) are playing greater roles in the fast growing knowledge-based economy.
If you use just the triple constant only to measure success then why not just simplifly it to say if the customer who paid for the work was happy then the project was successful. Of course you would need to know upfront what their hot buttons are: project costs, time, quality, ongoing support costs, etc.
The triple constraints are not success criteria. Like any relationship - they support an understanding of limited resources and how sacrifice must be made in one area to achieve another.... pretty basic stuff.
Whenever I think about the triple constraints, I think about the Sidney Opera House. What a spectacular achievement! Delivered late and over budget. The project violated every triple constraint ! Yet - the project was successful. Why? Customer satisfaction. Everyone loved it. The Opera House defines Sidney Harbor - whenever you see a picture of it - you immediately know - it''s Australia, it''s Sidney. What a remarkable thing.
So what is the lesson? Project success is not about metrics. Projects are not done because project managers are sitting around with nothing to do this week. They're done because a customer wants something. So if we are delivering something a customer wants - why would we measure success any other way?
@Donald: So if we are delivering something a customer wants - why would we measure success any other way?
********************************************************
It's a kneejerk reflex a lot of management has to only work with that which is easily quantified: time and money. Particularly when there are decisions to make about project approval and priority, it can seem that looking at the bottom line of time and money levels the playing field among the competing projects. Satisfaction & Quality have always been at the game, but on the bench a lot It's so hard to generalize in these conversations because different organizations handle quality & satisfaction differently.
The demand for satisfaction & quality metrics depends on the values of the organization and its priorities. If one is not in a sales/profit based situation, there may not be an emphasis on time or money, so the 3 constraints were never all that relevant to start with. Quality at any cost might be the overriding proposition in other situations. Other places need the cost to drive everything else. It just depends.
No matter what, any view of a project is skewed when time, money, scope, quality, and satisfaction are not purposefully balanced in concert with one another. None of them operate in a vacuum, and I think the request is to uniformly bring that sensibility into the PM gold standard.
Thank you Dave for opening up this discussion, I was a bit lonely preaching that the project success is in the eye of the beholder, not in blindly meeting the triple constraint. This comes back to the eternal “science vs. art” debate regarding project management, where the triple constraint is the science side and the stakeholders’ satisfaction is the art of achieving project success. None is complete without the other: it’s almost impossible to achieve project success without managing the bases, and simply ensuring compliance with the bases does not ensure (by itself) a successful project.
First I would like to say that the cost is a result of how a pm manages his projects in terms of Functionality (scope) Time, Quality and Productivity (Resources) For details on this I would like to point out the articles Balancing Ty which have been posted in April and May.
However the question when a project is succeful and how to measure it is a different question where cost, as the abstract of the 4 TY''s, is only one of the parameters to measure. Success can be measured in 4 ways which is in line with the balance score card:
1 Customers, for a project read stakeholders, are their needs met
2 Financials are the acceptance and financial success criteria met
3 People Is the team pleased with the result and with their personal development and learning curve
4 Internal process perspective. Did the proejct deliver on time
The answers in these four areas will let you know if the project was a success
Project managers are measured by the goals that have been set and agreed. Of course sometimes we fail to set goals and get by-in so the goals are unclear. If so success becomes subjective and based on the political skill of the PM. For most of us it is critical to avoid this situation.
One key to success is setting clear goals and managing the changes to goals as they arise, making it clear when goals change. It is possible to have a completely satisfied customer and still be considered a failure. Equally possible is a failed project that comes in on time in budget with all scope delivered as defined. If the users, customers and stake holders never bought into the scope as defined delivering is an empty victory.
Remind your customers and other stake holders of the agreed goals every chance you get. Once a day is not too much if the opportunity is there. Remind them of what has been accomplished, where you are in the process and what is left to do. Solicit their input. Ask for by-in and/or suggestions. Never, never go off with your specs to a hidden place and build your product; you will be very disappointed if you do.
We have been evaluating Quality as well as Scope, Time, and Budget for a couple years now. Criteria for each are discussed at each stage gate (go/no go) as well as the status of each based on that criteria. Previous to this leadership did not have input into the expected Quality parameters of each project - yet asked why 'x' was not done 'properly' as projects were implementing.
Independent assessment of Quality should be included. Assess meeting customer expectations (Product Quality) as well as meeting necessary company expectations (Process Quality). With projects more and more following some basic process steps (and associated outcomes) repeatability is improved, learning curve is reduced, and estimating is improved. But beware of having too detailed/specialized a process - teams will ignore/bypass the process due to the unique nature of each project.
Shenhar''s point, I believe, is less that Cost, Schedule and Performance (nee Quality) are important, but that the Outcomes aspect of a Business Case are what really drive interpretation of success.
I was also at the PMI Chapter meeting Dave attended, and I think that Shenhar''s presentation was about the most informative Chapter meeting I''ve been to in a long time. As a practicioner of performance based project managment I tell my clients that outcomes are what important. The point being while being on time and under budget are great, and the way we need to manage our projects, its the question of "did we get what we wanted" which is answered after delivery that determines whether the project is successful. Shenhar''s point, which he made in the presentation and covers in his book is that "successful" projects can actually turn out to be failures. Witness (see pages 25 and 26) the Los Angeles, California, USA subway system (Metro). It was a PMI Project of the Year, on time, on budget, yet it didn''t deliver the business value because no one rode it (essentially). Thus it was a failure.
I think Shenhar is correct in pointing out (page 26) that the five basic measures of success are:
* project efficiency
* impact on the customer
* imapct on the team
* business and direct success
* preparation for the future
Firstly. The PM world has certainly matured in terms of the demand for clever KPI''s for a project, and the time, cost and quality view is far too low level. They certainly reflect basic performance metrics for a project, no one would surely disagree. But individualised KPI''s are critical to plan and control a project appropriately, and to measure the true success.
Secondly, making time, cost and quality sound like absolute constraints is in any case giving a false impression. Our practices need to move into a consultative framework where the client tolerance for variations in these three areas is clearly articulated and shared with key stakeholders, so that an appropriate amount of planning and control flexibility is facilitated
I think the triple constraint, as described, is still beneficial, but is only part of the picture and you make a good point. Project Management has certainly evolved over the last several years, and will continue to do so.
A speaker at a recent IIBA (International Institute of Business Analysis) referred to the CHAOS report and how the statistics for projects completing on time and within budget have shown dramatic improvement over the past several years. I think that PMI and the triple constraint played a large role in that success, and now that more projects are getting done on time and within budget, project sponsors may have more time to reflect upon whether or not the deliverables they received were actually what they needed (an area that the speaker said is not doing so well, statistically). But I also think that scope is not getting the attention it deserves, taking a backseat to cost and time.
This reinforces a personal belief that greater emphasis is needed to understand business requirements EARLY in the project. I have been assigned to too many projects, in the middle of the project, where I have had to sort out what was going on and get things back on track. No wonder customers aren't satisfied; they feel like their needs are being ignored. Maybe dealing with the success criteria that the author identifies should included in the scope of a project???
I don''t disagree that the triple constraint is often over-emphasized for "business" projects. But, many of the programs I''ve run have these simple business constraints:
1. They are fixed priced contracts with both scope and delivery dates explicity defined. Payments are made on the basis of milestones being met.
2. The customer came to us because we claimed we would create something that could not be created by our competitors
3. Our customer''s sales cycle depends upon having a working model at a once-a-year trade show. [Think the Consumer Electronics show in the first week of January in Las Vegas.]
4. Most of our business comes from client-funded projects - we have virtually no products for sale.
If we miss the triple constraints, no matter how much value we eventually create, we are out of business. You don''t make money delivering Tuesday''s election results on Thursday.
So, should the PM for the LA Subway have refused the work because the client didn''t understand that no value was being created? What is the PM''s responsibility to the client and his/her employees?
Sorry I missed the Shenhar presentation... sounds interesting!
I agree with the approach to the triple constraint, at least as far as adding scope. I think that quality to a large extent defines the criteria for scope, so I am not sure about the representation of quality in the center of the triangle...
What I am more curious about is what is meant by Project Management 2.0. If you try to think of it in terms of Web 2.0 and Enterprise 2.0, concepts that are already in vogue, you come up with a different picture. And maybe it ties back to the PMBOK in the sense of the PMBOK becoming a base document from wich we collaboratively take it to the next level, rather than by traditional, slow, more bureaucratic means. In other workds, maybe the future thinking on PM is being shaped by discussions such as these more than discussions behind closed doors!
Here's the thing . . .the triple constraints are boring and old fashioned . . .but also completely necessary. There is no getting around these concepts as constraints. Any assigned task must consider three basic constraining factors: What is the work (scope), how long will it take (schedule), and how much will it cost (cost). Quality is a constraint as well, and should be recognized as the fourth, in my opinion. The desire to overhaul the triple constraint theory does not get a project manager around these basic constraints. For example, risks are not constraints. Risks arise or are lessened by the constraints, but risks do not inherently constrain a project to one solution or another. Costs will constrain a project. Schedule dependencies will constrain a project. But risks are simply possible outcomes that have probabilities and impacts, and do not inherently constrain the project.
The discussion has been interesting and, in my opinion, indicative of a new wave of project metrics. Project managers need new and inventive ways of measuring success. Using the triple constraint theory solely as a measurement tool is one dimensional. But ignoring the triple constraints in planning and using something like "business value" is like trying to ignore the laws of gravity. It just won't work.
Thanks for all of your comments. Just to clarify, when I wrote this I was thinking about the way people commonly define success. Typical success definitions start with the "on time, under budget" catch phrase and work their way out from there. On the face of it, the words "Triple Constraint" indicate that 3 things are important - cost, scope, and time. You could make the argument that "quailty" is at the center of it all and reflects the importance of "all the other stuff" OR you could say the focus of this is all wrong here. Maybe there needs to be a Quadruple or Quintuple Constraint that specifically names some of these other important measurements. Who knows?
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? Or, as Shenhar argues, are they too efficiency focused? What is their relative importance in the grand scheme of things?
Is it possible to rank, in a general way, his five success measures? Or does that vary too much by project?
- Efficiency (criteria similar to the triple constraint)
- Customer (criteria = customer satisfiers)
- Team (criteria = customer satisfiers)
- Business Needs (criteria = things like ROI, strategic fit, and competitive advantage)
- Future Needs (criteria = future value, like in the case of new technology where much of the value is yet to be defined)
If I were to measure, "Total Return" on a project, I might be able to quantify in $ (some of them projected) 3 of the 5 and document soft returns for he other two. Would that be helpful and/or a better way to measure success? Perhaps it''s a "Success Star"?
On the other hand, how do you differentiate between scope and quality? In my non-software world of delivering working parts, scope is set by defining the performance metrics for the deliverable item(s). If you exceed the performance requested, are you delivering additional quality or just exceeding the scope?
"Without question, the greatest invention in the history of mankind is beer. Oh, I grant you that the wheel was also a fine invention, but the wheel does not go nearly as well with pizza."
During his talk, he described a number of reasons why the standard approach to projects must change. A lot of it sounded rather "Agile" in nature. For instance, he talked about the Triple Constraint theory as being a key impediment to successfully delivering projects - because it incorrectly defines the success criteria. He said, success should not be defined just in terms of Scope, Cost, and Time - which are strictly efficiency-based. The focus should be more on business results and customer satisfaction.
His theory (he describes it as 'project manager as mini-CEO') is "If you approach projects with this broader set of success criteria, you will be a better project manager, because the results will be better." It's hard to argue with that. 
