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.

I would assert that the only people who can determine whether or not a project is successful are the project’s sponsors—the leaders (usually executives) in an organization who have responsibility during the project for deciding whether or not to continue investing in it. If you were on the Sydney city council, you might have imagined that the Opera House was worth an expenditure of $3-$4 per person for your citizenry in 1957 (several hours’ wages at the time). When the cost ballooned to $40-$50 per citizen (a week’s wages for many) and you faced difficult choices about cutting spending elsewhere, you might have felt differently. The sponsors get to decide whether the project is worth the investment and the risk. The sponsors get to decide whether to maintain, expand, or curtail scope to meet budget or schedule objectives. The primary role of the project manager is to support informed sponsor decision making.

I first read the book in 2008, but an NPR story about several cities in the US that are literally on the verge of bankruptcy due to runaway public works projects renewed my interest in the subject. One of the examples in the NPR story was Harrisburg, PA’s incinerator project that initially cost $15 million but had a final price tag of $288 million. My intention is not to kick the nice folks of Harrisburg when they are down or to fault the project manager of the incinerator project (I don’t know the details), but instead to offer their story as a cautionary tale to any project managers who might be tempted to lose sight of whose interest you are expected to serve.

Projects (particularly IT projects) can be difficult to estimate. Sometimes this is due to poor planning, sometimes it may be a consequence of unforeseen circumstances, and sometimes unknowns have a bigger impact on our projects than we expect. All a good project manager can do is be rigorous and try to inform sponsors about the likely time and budget requirements as well as the likelihood that those requirements are reasonably accurate. Sometimes surprises arise in the middle of a project. When a project has begun and actual cost and schedule performance data becomes available, project managers should provide the data should to sponsors to inform decisions about whether and how to continue.

I believe successful project management is about supporting informed sponsor decisions. Did the project manager provide timely and accurate information? Were decisions made at an appropriate organizational level? Were the right decisions escalated? Was risk managed consciously? Successful project management may not always lead to a successful project. Sponsors may make informed decisions to accept risks that undermine a project’s business case if they materialize. This is not a failure of project management.

I would argue that project success can only be determined by the project’s sponsors—not the team, observers, pundits, or consumers of the product the project creates. If sponsor goals are achieved within acceptable boundaries of time and resources, then sponsors should consider the project successful. Sponsors are allowed to modify or redefine their goals at any time during the project. In my view, determining success is not the jurisdiction of spectators after the fact, based upon how much they appreciate the project results. If that were true, the Harrisburg incinerator might be considered a successful project.

It seems to me that if we want projects to succeed, then the very first step is for us to agree upon a definition of “success.” What do you think? Was the Sydney Opera house a “success”? How would you decide that? What about the Harrisburg incinerator? Why? I look forward to your comments below.

References
1. Aaron J. Shenhar and Dov Dvir, Reinventing Project Management: The Diamond Approach to Successful Growth & Innovation (Boston: Harvard Business School Press, 2007), 21.