Who Defines “Success” for Your Project?

An otherwise good project management book provokes Payson with definition of “success” that rubs him the wrong way. In this article, he presents his case.

One of the early evolutionary stages of being a professional is realizing you don’t have to reinvent the wheel every time you ride a different bicycle. A few hours each week spent reading blogs, journals, or books in your field can accelerate your career advancement tremendously and help you get the bigger picture sooner while avoiding the need to learn everything from your own mistakes.

As your career progresses and your knowledge and experience in the field grow, two things occur:

  1. It gets harder to find useful sources. Lots of books and articles present basic ideas that you already know after several years in the field.
  2. You get more critical of what you read. Some of what you read will contradict things from your own experience; some will challenge principles that you value. (A major evolutionary step is when you find you really hate a book or article, but you recognize that there is useful information hiding in there and slog through it anyway.

This happened to me last year in a book on risk management. I’m now reading it for a second time, because it presents a couple of thought-provoking ideas that I resisted strongly on my first pass.)

At this stage of my career, good project management books are hard to find. (If you have a recommendation, please leave it in the comments.) When your friends are project management geeks and know that you are a project management geek, they help you find what is worth reading. This is how I found Reinventing Project Management by Aaron Shenhar and Dov Dvir a couple of years ago.

This is a very good intermediate-level project management book. If you are a project management geek, you should read it. It introduces some interesting language to talk about the size and complexity of technology projects and helps guide your thinking about the challenges of larger projects. I didn’t agree with all of it, and you probably won’t either, but there are good ideas in there that will help you wrap your head around some of the complexity of large technology projects.

That said, let me address the part I hated most, explain why, and leave the final decision up to you.

Chapter 2, titled “What Makes a Project Successful,” begins with a classic case study: the construction of the beautiful, iconic Sydney Opera House. What is particularly relevant to my message is the history of the project—a very interesting story of a large and ambitious “technology project.” You can read the history in five minutes, but here is a summary from the Wikipedia entry:

“The Opera House was formally completed in 1973, having cost $102 million ... The original cost estimate in 1957 was £3,500,000 ($7 million). The original completion date set by the government was 26 January 1963. Thus, the project was completed ten years late and over budget by more than fourteen times.” (Emphasis mine)

The authors of the book say:

“Judging it purely on time and budget performance, you might conclude that the Sydney Opera House project was a textbook example of project failure. But no one really cares any more how the project was managed, and almost everyone sees the Opera House as a success story. It provides continuous income and fame to the city of Sydney, and it remains one of the most fascinating buildings in the world.” [1]

They go on to identify several noteworthy projects that appeared to be failures at first glance but that history has redeemed (in their opinion) because the projects ultimately met the long-term business goals for which the project was initiated. Their point—that we need to be thoughtful about how we measure project success—is well taken. However, I think the logic of their example is flawed and subject to dangerous misinterpretation.

User Comments

1 comment
Mark Hart's picture

Every project has multiple potentials for multiple successes. Every individual associated with a project is likely to have unique perspectives on successes. For example:


A project manager may emphasize the mismatch between forecasts and the actual project parameters. Planned project cost and duration are likely to be compared to actual project cost and duration. Success may be determined by the mismatch. Success may relate to performance. Perceived performance may be reflected on the project manager's résumé and performance evaluation. 


Sponsors have multiple perspectives on successes. Some may consider it a success that the project was approved and produced. Factors related to budget and duration are only two ways to assess the project. The forecast is one factor that impacts the probability that a particular project is funded.


Engineering and operations may need to synthesize new approaches to solve unique challenges. They may perceive greater success because of the quality of the solution rather than compliance with a derived date on a calendar.


Some individual contributors (engineers, coders, documentation specialists,...) declare success if the project provided gainful employment.


Some individuals ascribe success from non-monetary factors. Did they have the opportunity to improve their skills? Did the improve their professional network? Did this project make a difference?



An individual begins a project with a some expectations of success – a forecast. As the project progresses, any individual can evolve their perspective. Some individuals strive to move from planning projects and features to designing a context where their successes are inevitable.


May 14, 2015 - 9:04pm

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.