The Art of Project Management

  • Article

One of the things I had hoped could happen on this blog is a lively discussion of things I’ve read lately that others may also have read. My first attempt was some reviews of chapters in Naked Conversations. It didn’t seem to resonate with anyone, but I’m going to try again anyway.

The book I recently finished reading is Steve Berkun’s “The Art of Project Management.”

First, the title…I like to define “project management” much more narrowly than Steve. His definition seems to include vision development, business analysis, requirements gathering, product design, planning and executing a project, and much more. I prefer to define “project management” as the planning and execution part. Steve’s definition, however, is much more in keeping with the generally accepted Microsoft definition for “program manager” which could be defined as “everything not done by dev or test.” In that way, it’s a very strange title for the book. I don’t know anyone at Microsoft with the title “project manager.” Yet, the biggest strength of the book is that it does a great job of telling you the basics of what is required to be a “program manager” at Microsoft.

In fact, some material seems to be very Microsoft specific. Does anybody outside of Microsoft use the term “war team?” Steve talks about it like it is a standard industry practice. It would have been great, however, if eight years ago someone had given me this book and said, read chapter 15 so you know how the end-game is going to work and how war room functions. In fact, the whole book would be a great manual for a new PM.

By far the best chapter is 13, How to make things happen. A lot of the problems I’ve seen on projects can be traced back to the fact that people have lists of work items without any higher level lists of goals and features. The result is they’re working on the wrong stuff, working very hard and not reaching the goals of the project because it’s not clear what those goals are.

I also like his comment near the end of the chapter, “Uninterrupted time can be hard for PMs to find, so if you can’t find it, you have to make it.” That is a practice I learned when I was a stock broker. It was actually taught and institutionalized throughout the firm. Brokers went into their offices at 8am leaving instructions not to disturb them unless an order needed to be placed and closed the door until noon. This is when we did all our high priority work. After it was done we would allow ourselves to be interrupted. It’s hard to work that way within Microsoft, but I attempt to get a couple hours each day where I can focus on a critical task intently.

Other gems…

  • “Leaders are hired to amplify the value of everyone around them.” If only more managers understood this.
  • “If you can’t find any visual representation of the impact of the project on the universe, be afraid that it’s directed toward something the world doesn’t need, or that it isn’t well defined enough” You should have a visual for your vision, brilliant.
  • “More often complexity is a cop-out that hides poor writing or mediocre thinking.” Demand that writing be clear, concise and simple.
  • “Reflection is highly underrated as a decision-making tool.” We have a predilection towards action. Sitting and thinking never gets the credit or time it deserves.
  • Chapter 10 has excellent suggestions for email and meetings. He hit on most of things that make me tune out.
  • “Never walk into an important meeting without knowing the opinions of the important people in the room.” Does it ever seem like someone was totally in control of a situation you weren’t? Maybe they just did their homework.
  • On office politics…”If the (decision making) process is overly complex, or lacks visible owners for decisions, anyone who cares about the outcome will be motivated to be more political.” I would add to that, if the process and criteria are not made clear people are motivated to be political.

If I had a criticism it would be that the book puts heavy emphasis on process and leadership but gives short shift to collaboration. In the end it is how well you work together with your devs and testers and everyone else on your team that will determine your success. Stellar visions, great requirements, perfectly ordered feature lists and flawless designs are nothing if your team can’t produce a product in a reasonable amount of time using a reasonable amount of resources and that requires collaboration from everyone on the team. That can’t happen if the PM is sitting in his office writing spec all by himself.