Differentiating Between Project Success and Project Management Success

Differentiating Between Project Success and Project Management Success
By Satya Narayan Dash

How will you know whether the project is a success or a failure? Will you consider a project to be a success if it meets its primary objectives? Will you consider the project to be a failure if the customer is unhappy, though you have delivered it on time, within cost and strictly followed the scope? Or will you consider the project to be a success if all the stakeholders are happy with the outcome, although it went beyond the estimated cost, schedule and scope?

Let us take some of the examples. Here, I am focusing on two constraints, which are “Schedule” and “Cost”. Of course, we have other factors, most notably being scope, and others like quality, risk, and customer satisfaction. However, below are some of the world famous projects and we can safely assume that their initial estimation of scope, schedule and cost were well defined.

Case – 1: Titanic Project

The epic movie by James Cameron based on the true incident of RMS Titanic sinking with love story of a rich girl and poor boy.

Schedule: It was over schedule. It started on 1995 expected to be released by mid 1997. However it was released late 1997 / early 1998.
Cost: It was over budget. The cost was USD $200 million, which was well above the initial estimate.
Final Report: The movie has been the highest grossing film world-wide with revenues of USD $1.8 billion.

Will Titanic Project be a failure as it was over schedule and over budget?

Case – 2: Iridium Project

A system of 66 active communication satellites with spares in orbit and on the ground. It allows worldwide voice and data communications using hand-held satellite phones. It was considered to be a dream project for Motorola.

Schedule: It was on schedule. It was completed on schedule, i.e., 11 years.
Budget: Budget was somewhat more than what was estimated. However, it was within limit. The budget was around USD $6 billion.
Final Report: The project went bankrupt within a year of its launch of its service and filed for Chapter 11 of bankruptcy.

Again, the question becomes: will Iridium Project be considered a success as it was on schedule and on budget?

Case – 3: Concorde Project

The primary objective of this project was the integration between Air France and BOAC.

Schedule: It was over Schedule. It took 7 years to complete.
Budget: It was over Budget. It took close to USD $3 billion and well over budget.
Final Report: Both Government of England and France were happy as it combined Air France and BOAC.

Was Concorde Project a success as it met its primary objective?

Wrapping it up, we all know that:

  • Titanic is considered to be a success though it was over budget and over schedule.
  • Iridium is considered to be a failure though it was completed on time.
  • Concorde is considered to be a success though it was over budget and over schedule.

This brings up the differentiation between Project Success and Project Management Success. They are actually entirely two different concepts, which is normally misunderstood.

Typically a project is considered to be a success when:

  • It has delivered on promised scope.
  • It is within the schedule for the project.
  • The cost for project does not go way beyond the estimate.
  • It has managed its stakeholder’s expectation well and the most important stakeholder, i.e. customers.
  • It is of good quality.

However, it is not actually the success of the Project; rather it is the success of the Project Management, if it meets the aforementioned criteria. Proper form of project management, i.e., delivering the project within the triple constraints of time, cost and scope can make the management process a success; however, the project need not be a success. Rather projects as shown by Titanic and Concorde are considered to be successful depending on the return on monetary investment.

This makes the role of a project manager more difficult. To address it, organization while starting a project, should primarily address three things:

  1. Define target success for the project and the project manager
  2. Define target success for the organization considering the project involved
  3. Define failure for the project and the project manager

Satya Narayan Dash is the Principal Consultant and Founder of Teleox® Consulting, Bangalore, India. Prior to that, he was Project Leader with Wipro® Technologies and a Project Leader with AdventNet®, Inc. He has rich experience of 8+ years in product development, and architecture in Java® and J2EE® based Telecom solutions. As a certified Project Management Professional (PMP®) from Project Management Institute (PMI®) and MS Project 2007®, he has trained hundreds of project managers and consultants. He holds a Bachelor Degree in Electronics and Communication Engineering from National Institute of Technology, Jalandhar, India. He can be contacted at email: ndsatya@gmail.com

PMHut Team

PMHut Team

PMHut.com is a website dedicated to providing PM articles, detailed project management software reviews, and the latest news for the most popular web-based collaboration tools.

5 Responses

  1. Avatar Julian Gall says:

    I think there are a few more aspects here which need to be disentangled:

    1. The only thing wrong may be the initial estimates of cost and schedule (and perhaps benefit). e.g. Titanic. The PM often has no say in these but arrives once they have been set. If the customer decides he’d rather increase the budget than reduce the scope, that is a choice and is not an indicator of the failure of the project. It just means the budget was wrong.
    2. The business case may have been mistaken. e.g. Iridium. Again, this is not to say the project failed.
    3. The business case may have been right at the start of the project but the situation may have changed by completion. Again, not the fault of the project unless this was very obvious and no review was made.

    I think the key requirement is to separate the ultimate aim of the project from the agreed means to achieve that aim. The project manager should only be held responsible for things he can influence. Often, what he can influence is just successful delivery of the agreed project, not whether the project actually achieves what people thought it would. e.g. The Iridium PM presumably had no influence on whether the service would sell. He just delivered on time and mostly to budget.

    I think this is what you are saying in your article but I don’t think the answer is to give the project manager the responsibility for the success of the higher level project. A movie is a great example. No one can be sure whether it will be a hit, however successful the project to make it.

  2. Julian,

    Great feedback.

    Yes, a failure of the project can be not blamed on the project manager if it is delivered on time, within cost and it adheres to the scope. And that is primary reason for differentiating between a Project success and Project Management success. A successful project management does not necessarily translate to the success of a project OR a successful project does not mean that project management is a success. However, odds against a successful project without a good project management are pretty high.

    Also, I would like to point out a big picture. Senior Managers, Directors and CEO are also Project Managers at a high level. It is not only the first level of managers. They are as much as responsible for the whole outcome of the project as is the first level direct project manager.

    However, in a real world it does not happen that easily. For high profile project, the echo is heard at the highest level and they are hold responsible, but not for a low profile one. Even in case of a big budget movie, failure of the movie very much translates as the failure of the director (he is also a high level project manager) – even though it is flawlessly executed by many low level project managers. In such a case it is unfair to blame them director and all its managers.

    Hence, understanding the differentiation and defining goals for success for managers at every level definitely helps.

  3. I enjoyed reading your posting. Another example I might add is EuroTunnel, which was over budget but for a good reason in that it added greater safety. Nonetheless, the project was a success and the project managers emerged unscathed and victorious.

    Indirectly, I see you are making a case for a PPM or portfolio management approach, which applies a set of higher level metrics for measuring success. Project Managers are often just focused on scope, budget and timeline measures. Portfolio Managers look to apply metrics such as strategic fit, competitive advantage and ROI to assign value to the project.

    Depending on the weightings used, these higher level measures are the real drivers for the project, with the timeline, scope and budget being the levers management have to get the project to the point where it starts generating value.

  4. Thanks Pradeep.

    Yes, you are correct in your observation about Portfolio Management and checking the current validity of the project based on various parameters.

    Also, in normal project management their a component as Risk Management, which is very much overlooked by many. Risk Mgmt. is a continuous process to see how viable the project – even when it is midway and what can be done to prevent, avoid or completely abandon. Various techniques such as Monte Carlo, Decision Tree Analysis etc. are used. This is the work of the concerned project manager. A great project manager never looses sight of this.

  5. Avatar Mark says:

    Nonsense. The reality here is that we are often working to standards set within a project by ourselves that no one else could give a toss about. If you’ve ever delivered projects you’ll know that a successful project can easily be over budget and time as long as you’ve brought the key stakeholders with you. The real challenge is establishing project quality. What is quality? As we also unfortunately know, the stakeholder is not always the best judge of quality. And please don’t start bleating on about requirements, we’re not business analysts (well most of the time) and you’re just moving the fundamental problem from project management to requirements gathering. Let’s just go ahead and make it all the same thing. What is quality?

Leave a Reply