Sunday, June 26, 2011

Project Failures & The Chaos Reports

Diane, the Chief Financial Officer, had invited the partner of the local PwC office for this meeting.  She had only done that once before, so he knew this discussion was special.  “How do I guarantee project success?” she asked.  He didn’t need it explained that this was probably a make-or-break project for the company.  He grasped all of the nuances of this question.  After carefully considering his thoughts, he responded “There are many ways to improve the probability of project success, but none of those guarantee success.  In fact, you really can’t guarantee project success.  But there is another way:  Call the activity an experiment or research or a prototype.  Regardless of the outcome, you can claim success.  Just don’t call it a project.”

I want to take a couple of posts and discuss project failures.  In this post I’ll discuss the often quoted Chaos reports, which applies to all types of projects, and in the next post will discuss more specifically IT project failures.

Let me start this discussion by stating up front that I’ve never read a Chaos report.  The Chaos Report is published by The Standish Group and costs hundreds of dollars (or more) to purchase.  My guess is that most people who reference the Chaos Report are, like me, only familiar with the press releases, headlines, and secondary references.

Because I haven’t read the report, I can’t criticize it.  I can, however, criticize all the people who reference it to make a point about project failure.  Allow me to present a couple of examples of why the headline number of project failures is misleading and misrepresentative.

In the first example, I will use an analogy.  Assume that most people who get a dog want it trained and that most of those people choose to do it themselves rather than hire a professional.  Further, most people who go it themselves don’t dedicate enough time, don’t have the experience, don’t follow through, and thus don’t succeed.  Now, let’s survey all the people who bought dogs last year and ask them about the success of their dog training efforts.  The results, of course, will show that most dog training efforts ended in failure, despite that virtually all professional training was successful.  The headline (most failed) completely misrepresents the success of professional dog trainers.

My second concern is with the definitions of success and failure.  “Strategies for Learning From Failure,” (Amy C. Edmondson, Harvard Business Review, April 2011) describes a spectrum of failures ranging from blameworthy to praiseworthy.  Just because it didn’t meet the original (optimistic) objectives does not mean that the project was a failure.  In addition, different perspectives of the project can produce completely different opinions.  For example, both the Sydney Opera House and the Ford Taurus went tremendously over schedule and budget, but both today are regarded as tremendous market successes.  In another example, a project could be started to introduce a new product into the market.  During the exploratory phase, the team determines that it cannot meet the business objectives and it’s cancelled. The brand manager considers the project a failure because the product did not launch;  the CEO, however, considers the project a success because the company did not over invest into a failing proposition and could redirect the funds to other more promising opportunities.  So how can I accept the Chaos report headlines when the same project can elicit either success or failure results depending only on who I ask?

There are many other reasons why the headlines should be ignored:

·         If the organization has failed projects, what is their success with operational efforts (i.e., what is the organization’s success baseline in general?)

·         How does organizational project management maturity correlate with project success?

·         How do the respondents differentiate between project vs product success and failure?

·         How does The Standish Group address different viewpoints of success vs failure on the same project?

·         How does project manager experience, autonomy and authority correlate with project success?

Taken together, if a barely profitable organization with poor manufacturing processes and that had no experience delivering projects asked one of their middle managers to lead an effort to bring out a revolutionary new product, told the manager how much was budgeted, how long it would take, and who would comprise the project team (but the team members would continue to report to their current units), who would be surprised when, after a few months, they cancelled the project and called it a failure?  How many of the projects in the Chaos Reports fit this model?  If The Standish Group reported that most projects with these criteria failed, would it be newsworthy?

I have every expectation that The Standish Group conducts their research professionally and competently.  Again, I’m not criticizing The Standish Group or their Chaos Report.  I am saying that we can’t use the headlines to understand project success or failure rates;  we need the demographic details that are contained in the detailed report.  Those details, I am sure, would provide clarity on something much more important than the frequency of project failure – they would provide insight into conditions for project success.

Wouldn’t you bet those details show that projects in organizations with mature PM processes and run by qualified project managers are successful at a much higher rate?

Monday, June 13, 2011

The Project Manager’s Cycle – Redux


“What does a project manager do?  What value do I add to your project?  It’s true that I don’t contribute directly to the product or service for which the project exists.  However, if I’m doing my job well, then I add significantly to the productivity and value of the team by improving communications, eliciting priorities, and focusing the team on the key deliverables.  Further, I am your agent, seeing that we perform to plan and communicating back when we diverge from it.”





The Project Manager’s Cycle includes these activities:
·         Validate the metrics
·         Validate task status
·         Reschedule/Replan
·         Develop earned value reports
·         Review commitments
·         Conduct project team meeting
A baker’s dozen posts on the core project management elements of monitoring and controlling a project.  This series on The Project Manager’s Cycle been a pleasure to write and has also been beneficial for me.  I developed the outline of the series several years ago, but this journey required that I really flesh out the details, relationships, and components.  I appreciate all of my reader (yes, that would be you) who stayed with me through this.
A picture is worth a few words, it’s said, so I’ve tried to rough out the series in a diagram.  If I ever figure out how to make it available as a download, I’ll enable that.  In the meantime, leave a post or drop me an email and I’ll reply with a full-size PDF of version 1.0 of the diagram.  Next time I’m feeling ambitious, I’ll add the inputs and outputs, though I’m concerned that will make the diagram too busy.
We stepped on the ferris wheel together in January to start this ride.  We’ve gone around the cycle and now it’s time for us to step off.
What of this series has been the most beneficial to you?  Where have I not been clear and need to expand or improve the discussion?