From "Triple Constraint" to "Success Star"?

The key here is to seperate project objective/deliverables success from project management success.

Project objective/deliverable success is acheived if the project ultimately delivers its scope and meets objectives. The project can be late and over budget and still do this (within reason). This project, however, would not be a success from a project management perspective. Project management success would be more focused on the triple constraints as well as other measures such as team performance, morale, good use of the methodology, etc.

I would state that a project can acheive project objective/deliverables success without acheiving project management success, but that a project cannot be called a project management success without acheiving project objective/deliverables success.

Posted: Jun 10, 2008 11:53 AM

I think my perspectives on this might be almost heretical by comparison with the Project Management established cannon. I'm not convinced thre is a concrete, universally applicable yard stick for every project. I would prefer a universally applicable discussion framework instead.

I think the success measures depend on the values of the business sponsoring the project. In an ideal world there would be cut & dried criteria and measurements that fit all projects all the time. In my 10 years working on IT projects, I have yet to encounter an absolute situation once. I've been on teams that spent valuable time wrestling the project into submission to concrete criteria that actually didn't fit and whose data were useless.


To borrow an idea, let's begin with the end in mind.
At this point, I see the PM facilitating a conversation with key leadership to determine what success looks like for short, near, and long term durations after the project ends. I can see presenting 3 different scenarios to the management team based on some different models to help them envision impact faster.


Great - What's the model based on?
Perhaps the star doesn't have equivalent points at all. Maybe it's not a star. Maybe it looks more like the "Ka-Pow" starburst from the old Batman shows. I think it is possible to craft a fairly static list of what the criteria of the points *could* be, as guidelines to prevent chaos.


Will the PM need to do this on every project? That could be time consuming and tedious. Is there existing info from the organization to use as a springboard, such as mission statements, strategic goals, etc.?
Could you walk in with suggestions and a recommendation to start the discussion? Something to think about for sure.

I do believe it is a dialogue we need to open up with management/key stakeholders to develop this 360 degree sensibility that will govern the project's decisions along the way.


Posted: Jun 10, 2008 12:17 PM

I think that reality has it that others - probably upper management - have selected the project, and someone - a PM - has been brought on board to execute on the project. So, from that standpoint, I agree with Shawn, that there should be separate success criteria. However, I think it is a shame if a project manager does not "take the high road", understand the top level perspective, and "adopt" the project as his/her own. Such ownership would represent buy-in by the project manager of the project's objectives, not just delivery of the project. Ownership of this sort is very motivating and really is the only thing I can think of that would really keep the project on track and effectively allow the PM to communicate to the stakeholders and sponsor.

Posted: Jun 10, 2008 12:22 PM

I don''''''''t see the Triple Constraint as a means to identify success - I see it as a way to illustrate your work space. And there is the key problem: the triple constraint is a flat, two-dimensional model trying to represent a volume.




When was the last time you poured milk - or beer, for that matter - into a circle, a square, or a triangle? These shapes probably didn''t hold your liquid too well, did they?




You poured your volume of milk into a cylinder (or in the case of beer, a fluted convex dodecahedroid - see http://www.realbeer.com/library/beerbreak/archives/beerbreak20010322.php ).




The point is, we need *three* dimensions to talk properly about space. Maybe even more...but I cannot work beyond three to easily.




This whole topic will be covered with a new model called the Constramid(R) in our upcoming book, The Fiddler on the Project.



But back to the question - how do we measure project success? Come to think of it, our Constramid may actually help answer this question. In our model, the triple constraint triangle evolves into a pyramid with three walls repersenting cost, scope, and time, and the FLOOR representing that driver of project change - risk. The PM perches atop this structure, and quality is woven throughout the surfraces of each pyramid wall. The inside of the pyramid is the workspace of the project.




To me, success means staying atop the pyramid. The moving and shape-changing risk floor will inevitably pull out one wall, push out another, at any given time. And there you are, precariously perched at the peak, with these surfaces moving around under you. A successful PM - and a successful project - either has anticipated this change or can intelligently work around it. It's about balance. It's about still getting the work - the deliverables - of the project done, despite the mushy footing underneath you.




All this said, I still think that the triple constraint triangle or even our Constramid model are meant more to depict the workspace and not serve as a success model. The star model you''ve discussed here may do the trick - as long as it identifies satisfaction of all of the key stakeholders.

Posted: Jun 10, 2008 12:27 PM

Love the concept. There are so many things that contribute to project and even enterprise success.
The key for me is to focus on the value contributions and value trade-offs to stakeholders along with a high certainty of success and low negative social and environmental impacts. Perhaps an overlapping model (ven diagram) might show the interplay between the criteria better; but the star works great too.

Posted: Jun 10, 2008 12:40 PM

I like the first Star mentioned. This takes into account the future needs for the business as well as the team needs. If you burn out team members on this project you may not have them for the next one. If you do not challenge them and offer tasks that will help them grow into the next position then many won't be around for the next projects.

I also like the end customer on the first star. Sponsors may be happy that you completed the scope within time and money but the end customer will let you know if the thing is usable.




Posted: Jun 10, 2008 1:44 PM

Dave,

Models for measuring success will never measure up but they are useful aids to thought. The Star is as good as any I''''ll wager.

The simple measure of success that I like best is effectiveness. Did the project accomplish its goals? In other words did it deliver the goods -- as expected?

Some examples -- The Manhattan Project was successful because it developed a useful A-Bomb early enough in the war to make a difference. In this case schedule, while variable, was still of critical importance. In the end the project delivered the goods.

The Big Dig in Boston was over budget by a very great deal and very late if you use early or even mid project plans as a measure but that''''s not why some people think it failed. The tunnels leak and one failed and killed a user. Quality was and is poor. If it had excellent quality it probably would have been declared successful because it really did what it set out to do -- solve the traffic problems in down-town Boston cutting at least one half hour off the time to get from the suburbs to the airport. while improving the architecture, and the livability of the city. So in this case while goods where delivered they arrived like so much rotten fruit. Goods delivered but they have so far disappointed -- because they are just not up to what was expected.

The Space Shuttle is not a measurable project according to some critics because no one knows exactly why it was developed. Further, it took years for NASA to realize that it is a very unsafe mode of transportation. Many of the standard measures of success can''''t be applied to the shuttle because it is largely a tool of propaganda. But then again if it is measured that way -- as a way to enhance US international prestige -- it might be considered a success. But the poor safety record (1 failure in a few hundred launches -- compare that to any other mode of transportation that is not experimental) probably has nullified the effectiveness of the shuttle as a prestige enhancer. So.. one can easily argue that the shuttle has not delivered even as a publicity stunt.

So I'll go out on a limb and say that if a project team is hired to solve a problem and gets it solved it is successful even if the cost and time constrains are blown. Even if the ''quality'' is sub par (but it must be above abysmal and not kill people!). If the problem is perceived to have really been solved it is a success no matter what. So delivering the goods is important -- but as projects progress the nature of the problem invariably changes. It is up to the team to manage the perception of the changing problem as well as the expectations of those who shall be obeyed.

Of course there are politics so if the problem is very important and if the over runs are high the team can be cast in a bad light. So (thinking out loud) I'll go out on another limb and say that for projects with important goals, delivering the goods as expected is what counts above all other measures. (Note that expectations and perception can be and must be managed by the senior project managers and or her superiors)

The other, less important projects probably should never have been funded anyway!

Cheers,
Frank



Posted: Jun 10, 2008 8:41 PM

Sorry -- just a edit -- in the penultimate paragraph I wrote "Of course there are politics so if the problem is very important..." I meant "so if the problem is not very important."

You still may question my logic but at least this is closer to coherent! (I hope..)

Frank

Posted: Jun 10, 2008 9:12 PM

I am all for clarity, and I think the star approach can add more clarity, but so can the triple constraint if used in a more collaborative manner. It is my position that the triple constraint is not overused; it is misused by some PMs, not understood by many stakeholders, and in some cases ignored due to varying circumstances. As with any new thing, the star approach could face the apprehension of "one more thing that gets a lot of hype and goes nowhere," creating the potential for it, too, to be misused and not understood or ignored. I am not saying it is a bad idea, I am just not convinced that it addresses the root of the problem.

I am not going to claim omniscience or special knowledge of the root of the problem, but I think I can speak to part of the problem. It has been my experience that some project managers have lost their focus as facilitators and assumed the role of taskmasters. It may be that this mindset has been forced upon them for whatever reason, but it exists, and it leads to other problems on a project.

As a taskmaster, my approach would be reactive. "Business (or IT), if you change this task or requirement, you must make sacrifices in these areas..." I am not saying that this is not true, just that the taskmaster PM comes across as dictating to others, which is seldom appreciated when it comes from a PM.

As a facilitator, my approach is to work with the customer to help them understand the impact of the requested change so that the customer can make an educated decision regarding whether or not to proceed. It could be argued that the taskmaster is trying to accomplish the same thing, but the taskmaster usually ignores his or her audience''s opinion of their decision-making capabilities and/or authority.

I would be lying if I said that I was always a facilitator, but it can be a more effective approach, especially in situations when the triple constraint "goes out the window," so to speak. I have been brought into a project that requires a new network environment to be created. IT decided to use the clean slate to implement the infrastructure the "right" way. The business expects everything to work the same as it did before. Neither side has effectively communicated their expectations with the other or discussed the impact of doing it one way or another. Just to be clear, I am not the PM. I am, however, now in the position of bringing IT and the business together to discuss the right way to set up the environment in order to accomplish business objectives with a government mandate driving the deadline. All that matters now, however it is set up, is that it is up and running on time and that the business has the time they need to check out their new systems, ensuring that they are functional before the deadline.

Did the triple constraint really go out the window? No, but we''re not discussing it, either. Instead, I am shifting the task focus of the effort to collaborating to find the best solution to meet our immediate concerns that came about as a result of poor communication and collaboration. Don''t applaud, yet, we''re still not done :-)

Both the triple constraint and the star can be successful, and they can both face difficulties. I feel that the triple constraint has proven its value in the past, and it can continue to do so. The star approach could, in some ways, be considered a "re-packaging" of the triple constraint. Is it needed? It might be on some projects, but there are other factors, such as effective communication, that have a greater impact on the success of the project and need to be addressed before either the star or triple constraint can have a chance to affect the successful outcome of a project.

One final thought. Dave mentioned that the PMBOK, "does not put the Triple Constraint out there as the measure for success on a project." Star or triple constraint, maybe we should think of them as part of a PMs planning toolkit, instead of a measure for success.

Thoughts?

Aaron

Posted: Jun 11, 2008 3:30 AM

Dave thanks for taking the discussing one step further. As I have mentioned previously I think the 5 point star resembles the Balance Score Card a lot. I alos think that we should take into account that a project is limited in time, resources and costs(the triple constraint again). Meeting future needs can be done after the project has been finished and one can argue if this is measurable during the project life cycle and therewith a key success measurement. I would suggest this is mainly the responsbility of the programme and/or the Business Change Manager who is also managing the Business Case (see OCG site for Managing Successful Programmes).

As a project manager you accept a number of responsibilities like efficiency. As I argue in my articles, Balancing TY, there should be four; TIme, FunctionaliTY (scope), QualiTY, and ProductiviTY, which all result in a total cost for the project. The last one represents resourcing the project and you can argue the development of resources is also beneficial for the next project and therefore not within the responsibilities of the pm, however I experienced higher productivity when peopl get challenging and rewarding work thus for me it is a responsbility which I take seriously.

Meeting the business needs is managing the stakeholders and their expectations and if the delivery is according to their expectations the project is considered successfull even in cases when it is not as efficient as was predicted. So stakeholder expectation/meeting Business need is the counter weight for efficiency. The same can be said regarding the end-customers. If they consider the solution as fit for use and purpose it will balance the efficiency.

I would suggest the paradigma which needs to be managed is:

Efficiency = Business Needs + End-customer acceptance

whereby team needs is a part of efficiency following the balancing TY philosophy

what do you think?

Posted: Jun 11, 2008 7:59 AM

Dave, Thanks for continuing to stir the pot on this discussion. I like the star idea - very clear on the elements being separated - however, I'm not sure they are really separate considerations. If we are struggling to articulate a visual representation, why wouldn't the two stars be integrated? And if that approach is acceptable, does this limit the number of constraints? Or, does this merely mean that these are the ten identified to this point? Are there others that should be included, or others left out? I'm not sure I good at answering my own questions, but I do agree the approach does generate discussion. Perhaps these are really a Venn diagram, with overlapping constraint segments that form the stars or triangles, or double pentagrams.

Posted: Jun 11, 2008 9:43 AM

Interesting discussion. My thoughts are twofold.

• First, constraints and success criteria are simply two different things.


• And second, this does not have to be an either/or proposition. Both have and can be of value.

The constraints are the things that cannot be changed without impacting other constraints. The Project Management Triangle is a simple construct that continues to be of good value. Success criteria, on the other hand, are also very valuable, though not necessarily constraints to one another. Success criteria can be represented graphically as star diagrams, spatial diagrams, radar charts, and as Sonya mentioned as one of those Batman "KA POW" starbursts. Measuring success criteria in this way as a technique not only makes a lot of sense for the reasons outlined by Shenhar, but it also aligns quite nicely to other techniques such as project scorecarding as part of the project selection process to determine the relative merits of the project as compared to other competing project opportunities and review of the project scorecards as part of the ongoing portfolio managing process. Also, of all of the executive dashboards that I have seen over the years, not one of these dashboards has shown only the triple constraints. Always, these executive dashboards show other "success" measures for the project. Hence, it is hard to argue Shenhar's proposition and the value of establishing and measuring "success criteria" for the project.

As a side note, not too long ago I had the opportunity to play a round of golf with our club champion. I spotted that he was keeping track of his round, not on the scorecard for the golf course, but on a customized scorecard. In addition to the score for the hole, he was tracking drives in the fairway, greens hit in regulation, miss-hits by club, total number of putts, number of putts missed short, high, low, and long, and a few other things like number of three putts, percent of putts made inside ten feet, etc. I asked him why he tracked all of those stats and what he actually did with them. His response was short and applicable to so many things in life. He said that the more you measure the results of what you are doing, the better results you can achieve.

Project Success Criteria - absolutely..!

Posted: Jun 11, 2008 11:26 AM