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:
- 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.
- 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.” 
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.