This is an update of an article on my website.
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 constraints – 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 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 project well-managed?
- Was the product (service, result, or outcome) of the project a success?
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 four measures of project management success – one each for scope, cost, schedule, and stakeholder satisfaction. Larger projects may have more (e.g., separate measures of stakeholder satisfaction for the customer and the team), but four is the minimum.
Product Success. Many of the potential measures of product success 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. Nevertheless, the project team must know what they are so that project decisions don’t jeopardize the expected benefits. Product success criteria will generally fall into one of the following categories:
- Bottom line impact — revenue generation, cost reduction
- Operational impact — performance measures
- Market impact — share, potential, reputation
- Intellectual value — patents, knowledge, experience
Conclusions. 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.
They should also be subject to change control since they are likely to change during the project.
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 favor and get these measures documented and agreed to right from the start.