Outdated Success Criteria

I know this is going to probably get me some "hate" comments.  It seems like if I write about anything but a zombie, that's what happens. But I do like to write about topics that make people stop and think. Think of this post a bridge between a historical project management and futuristic project management.  Let's think about success in both an objective and subjective way.

I'm seeing more and more topics about the measurement of success.  Geoff Mattie just wrote a post over at the PMI Voices site, titled Can Agile Conquer the Physics of the Triple Constraint?

Geoff refers to Triple Constraint and states

The "iron triangle" as some refer to it, defines three pillars: cost, scope and time. It asserts that you have to prioritize the three with an understanding that trying to have all of them at the same time compromises quality.

I applaud Geoff in his zealousness and hope this works for him and hit customers.  Being his blog post is on the PMI website, I want to point out the the iron triangle is not in the PMBOK.  Rather, on page 6, it states

Managing a project typically includes... balancing the competing project constraints including, but not limited to Scope, Quality, Schedule, Budget, Resources, and Risk.

I remember a few years back, when taking the PMP exam, I had a question about typical project constraints.  The answer was not limited to 3 or even 4 "pillars".  So, where am I going with this?

I'm curious why people continue to measure the success of a project, merely on the basis of an iron triangle.  I think this concept is outdated and perhaps created by a project manager to help an executive understand project management at a 100,000 foot view.  I am also curious why many continue to use the Chaos report, (which leverages triple constraint) as the de facto report of industry success or failure.  I am not debating that it has historical significance.  But, I am questioning if it should be the way of measuring project success.

Jeff Sutherland has a blog post about the happiness metric.In his post, he mentions Tony Hsieh of Zappos.  I recently read the book Delivering Happiness by the Zappos CEO.  Again, what's my point?  Perhaps the Chaos report should introduce happiness or customer satisfaction at part of its success criteria.

Too subjective you think?  I think not!

I recently saw a presentation by Sanjiv Augustine as part of the VersionOne AgileLive Webinar Series

One of the concepts presented in Sanjiv's presentation was a NPS (Net Promoter Score) metric.  Think of it as a customer satisfaction or "happiness" metric.

NPS is based on the fundamental perspective that every company's customers can be divided into three categories: Detractors, Passives, and Promoters. By asking one simple question — How likely are you to recommend [Company X] to a colleague or friend? — you can track these groups and get a clear measure of company performance through its customers' eyes.

So, what is the Zappos NPS?  In a YouTube video of Tony Hsieh at the NPS Conference  (1-26-09), Tony said Zappos offered random email surveys that resulted in an 83% NPS and phone surveys resulted in a 90% NPS.  Though they lose money on some of their customers, they are an overwhelming success.

Do you believe the Standish Group Chaos Report should include NPS to define success? Are the original classifications outdated?

Kobayashi Maru for Projects

Without trying to appear to be too much of a geek, I sometimes code-name a project as Kobayashi Maru. For those out there who are not Star Trek geeks, Kobayashi Maru is a test in which command division cadets at Starfleet Academy are presented with a no-win scenario as a test of character. I use the term for a project in which management gets involved and I'm presented with a no-win scenario.  I doubt they are trying to test character. Rather, it's an example of their lack of understanding project management. I'm sure there are PMs out there who have had management redirect resources from your project to others, only to refuse to narrow scope or push out a delivery date. That is a Kobayashi Maru.  Just because I have a PMP®, don't expect me to pull a rabbit out of a hat.  On a previous program, I've looked management in the eye and reminded them that something will have to give.  Narrow scope, extend the deadline, lower quality expectation, or increase the budget.  Do something or this will be a no-win scenario.

Image from : drexfiles.wordpress.com

PMI Code of Ethics and Professional Conduct

I pride myself in the fact that I'm a very honest and hard working manager.  I define the Huether Triple Constraint as Passion, Commitment, and Skill.  I'm passionate about what I do, I'm committed to the organizations I work for, and I rely on my skills and the skills of others to be successful. As part of commitment, ethics and professional conduct should always be considered.  One of the questions I always ask myself before making a leadership decision is "Is this good for the project and our organization?"  No, I don't work for Initech and this isn't Office Space.  This is a valid question and there will be several questions on the exam that deal with ethics and professional conduct.

I recommend reading the PMI Code of Ethics and Professional Conduct. Even if you don't take the PMP, every good project manager will learn from it.

Triple Constraint

Triple Constraint

With Project Management, you must understand that EVERY project has constraints.  Unfortunately, project managers tend to ignore this and it will come back to haunt them time and time again.  Constraints include time, scope, cost, quality, risk, or any other factors that will limit what your options are when managing a project or deliverable. "Triple Constraint" is a term that originally included time, scope, and cost.  Newer definitions include customer satisfaction, risk, and quality.  If you're preparing to take the PMP® exam, include both the original and newer definitions.  Sextuple constraint just doesn't quite role off the tongue. I try to stress to stakeholders every time they try to expand scope that it will directly impact the other constraints.  If you expand the scope, you will either have to expand cost or time.  If you don't expand either of these two constraints, you're going to increase risk and lower quality.

You'll first read about constraints in section 1.3 of the PMBOK®.  PMI will only refer to them as constraints at that time.  Y0u'll find them referenced at other locations within the PMBOK as project constraints.  What you will not find in the PMBOK 4th edition is an actual definition in the glossary.