Select Page


Defining and Measuring Project Success
By William R. Duncan

Most people have an intuitive appreciation for what success is, but defining it and measuring it is a bit tougher. If you’re from Arkansas, Success is a small town not far from the Missouri border. If you’re an actor, Tom Hanks is a success while Tom Arnold is not … or is he?

If we define acting success in terms of critical acclaim, Tom Hanks wins over Tom Arnold every time. If we define acting success as steady, above average pay for work that you enjoy, then Tom Arnold is quite successful.

Projects are not so very different from actors. In order to measure success, we must first define it.

But how should we define it? To the extent that the project management literature of the 1960s and 1970s dealt with project success at all, the definition was usually limited to meeting cost, schedule, and scope objectives – was the project finished within budget, on time, and according to the specifications? Later, both quality and stakeholder satisfaction were often called out separately rather than being subsumed within scope.

The common theme in all cases was that project success was defined in ways that could be measured the day the project was finished. But what about the Sydney Opera House? It cost sixteen times as much to build and took four times as long to complete as the original estimates. A project management disaster produced an enduring and inspiring civic symbol. Was this project really a failure?

Dimensions of Project Success

In the same way that quality requires both conformance to the specifications and fitness for use, project success requires a combination of product success and project management success:

  • Was the product (service, result, or outcome) of the project a success?
  • Was the project well-managed?

Simple yes-or-no answers will not suffice. We should not be asking “was your project a success?” We should be asking “how successful was your project?”

Different stakeholders will use different measures. The health and safety officer wants no injuries. The manufacturing manager wants a product that is easy to build. The ISO 9000 compliance team cries “success” if the documentation is complete. The VP of Marketing will be delighted if you get to market before your competition.

Beyond on time

Project teams are fond of defining schedule success as on time. A lovely concept to be sure, but essentially useless from a management perspective. Here are some very basic questions that this phrase doesn’t answer:

  • Is it okay to be one day late? one week? one month?
  • If we finish early, is that bad?
  • Are we measuring against the original schedule or the current baseline?
  • Do individual activities have to be on time as well?

To help overcome the tendency to oversimplify, try using a structured format for developing project success criteria. For example:

  • Stock intro: “one key success measure for this project is to have …”
  • Measurable item: “the completion date of every major milestone”
  • Comparison statement: “within”
  • Some number: “one week of the baseline schedule date”

Most projects will have at least three measures of project management success – one each for cost, schedule, and stakeholder satisfaction. Larger projects may have more, but three is the minimum.

Product Success

Useful product success measures are often hard to define. Many of the potential measures such as revenue and cost savings are beyond the direct control of the project team and will not be measurable until long after the project is finished. When this is the case, the team must determine what it can influence. For example:

  • With a consumer product, unit manufacturing cost may be key.
  • For a web-based software application, 100% compliance with public standards might be the target.
  • On an information technology project, training may be vital to user acceptance.


As with any other tool or technique, project success measures can be overdone. Use the following checklist to help ensure that your measures are good measures. They should be:

  • Complete—anything unmeasured is likely to be compromised.
  • Relevant—variances clearly indicate a need for corrective action.
  • Valid—measuring what you intended to measure.
  • Easy to understand—so that people will accept them.
  • Economical to obtain—know the value of the information.
  • Timely—in comparison to the result measured.

The bottom-line is this. Your project will be measured. Your stakeholders will decide whether it was well-managed. Someone will decide whether or not the project of your project was a success. Do yourself, your team, and your organization a service and get these measures documented and agreed to right from the start.

William R. Duncan is the principal of Project Management Partners of Lexington, MA USA. He currently chairs the Board of PMCert, the certification body of the American Society for Advancement of Project Management (asapm). He was the primary author of the original (1996) version of A Guide to the Project Management Body of Knowledge and was one of the founding members of the Global Alliance for Project Performance Standards (GAPPS) which has recently published a framework for performance-based competency standards for project managers.

© 2009 William R. Duncan –

Recommended PM App

Recommended PM App