Home / Books / Book Reviews / Book Review: The Art of Project Management

Book Review: The Art of Project Management

Please Share...Print this pageTweet about this on TwitterShare on Facebook0Share on Google+0Pin on Pinterest0Share on Tumblr0Share on StumbleUpon0Share on Reddit0Email this to someone

I’ve been working professionally as a software engineer for several years and I learned more in the first 100 pages of this book than from my years of experience in the industry. Scott Berkun provides examples from real world experiences so you don’t have to make the same mistakes to learn what you should and shouldn’t do.

The topic of project management is a potentially dull subject but the conversational tone, with the occasional humor makes the read pleasant and engaging.

Even if you’re not a manager, the information provided in the book is essential to make you aware of the issues that projects face and what you can do to avoid the common pitfalls of software development.

I highly recommend it for all members of a team that has to design, implement, test and deliver (on time, no less) a product in some form or another.


To give you a deeper overview, here’s a short biography from the back of the book cover.

Scott Berkun worked for 10 years at Microsoft Corporation on projects including Internet Explorer, MSN and Microsoft Windows. He worked for two years in Microsoft’s engineering excellence group, teaching and consulting with development teams. He currently works as an independent consultant in project management and product design and he runs the pmclinic, a friendly discussion forum on project management issues at www.scottberkun.com.

Incidentally, I was first introduced to Scott’s work by subscribing to the pmclinic mailing list. If you’re involved with project management issues, the forum is a great way to learn how others are solving the problems and challenges you face on a regular basis.

Now on to the book. If you want to get a firsthand glimpse of the writing style and content, chapter 3 is available for free at artofpm.com (here’s a direct link to the PDF).

I’ve included the table of contents to give you a clear idea of what is covered in the book. I’ve summarized the chapter summaries to give you an broad overview of what’s covered in each chapter.

1. A brief history of project management (and why you should care)
The long history of project management, dating back to the Egyptian pyramids, the general role of a project manager (PM), how to find balance in what you do and what you should and shouldn’t do (e.g. you should help to coordinate different members of your team, you shouldn’t micromanage your team).

I. Plans

2. The truth about schedules
Schedules allow for commitments to be made, allow people to see their contribution to the project as a whole and enable the tracking of progress. Even when schedules slip, they still have value. They should be made with skepticism understanding that all estimates are probabilities.

3. How to figure out what to do
Different projects demand different approaches to planning. A discussion of the process of gathering and writing requirements, how asking questions forces good thinking and how to use problem statements to define and communicate requirements.

4. Writing the good vision
The value of a well-written, relevant vision document and what makes them useful.

5. Where ideas come from
The quality of ideas, why not to think outside the box and why ideas are only good or bad in relation to the goals of the project.

6. What to do with ideas once you have them
Changes will cascade through a project. The use of affinity diagrams to consolidate ideas. How to track questions that need to be resolved before specifications can be completed.

II. Skills

7. Writing good specifications
The three things specifications should do. The difference between specifying and designing. The simplest way to define and control spec quality.

8. How to make good decisions
Sizing up decisions before spending too much time on them, the most flexible method for comparative evaluation and how information and data make decisions for you (Hint: they don’t).

9. Communication and relationships
How to get people to do their best work, the communication bottleneck, other common communication problems, the easiest way to improve relationships.

10. How not to annoy people: process, email, and meetings
Why people get annoyed, how to run useful meetings and how to accelerate progress and prevent problems.

11. What to do when things go wrong
No matter what you do, things will go wrong. Common situations to expect and how to learn from them, the value of negotiation, how to help your team deal with different kinds of pressure.

III. Management

12. Why leadership is based on trust
How to build trust and how it is lost. Using delegation to build trust, responding to problems while maintaining trust and the core of leadership: trusting in yourself.

13. How to make things happen
Ordered lists, prioritizing, how and when to say no, handling the critical path and keeping the team honest.

14. Middle-game strategy
How to take corrective action, what to do when your project is out of control, milestone-based planning and how to use change control.

15. End-game strategy
Big deadlines are a series of small deadlines, how to improve your team’s ability to hit dates, the postmortem process and what to do when your project makes it out the door (Hint: be very, very happy).

16. Power and politics
The different kinds of political power, when power is misused, the political constraints to consider and how to solve political problems.

Powered by

About dan

  • Abhinav Vaid

    8. How to make good decisions
    Sizing up decisions before spending too much time on them, the most flexible method for comparative evaluation and how information and data make decisions for you (Hint: they don’t).

    I think the answer to this is “making informed decisions”. I really do not think spending time is not good, but yes there is a line that needs to be drawn so that planning itself eats up the entire time.

    I also very strongly agree that following up processes blindly is definitely not the key to success, as there are various parameters with respect to the same. Even the Processes vary to a very large extent with respect to Projects and Products Organization. Later come various technology domains and so on.

  • No problem – thanks for the updated review Dan.

  • Dan, I tried two rather gentle suggestions before I brought out the flyswatter. If you felt insulted by my reaction to your initial rather abbreviated review, well, I’m not the only one who found it too short.

    The updated version is MUCH more helpful, and that’s what makes a good review. Thanks for the expansion!

  • dan

    Thanks for your comments Scott, and thanks for the link to the free chapter. I knew there was one out there, but I forgot where it was.

    The Proprietor: Your concerns are, as Scott already mentioned, addressed directly in the book. I too have had to deal with far too much process for the process’ sake to the detriment of a successful release.

    Scott frequently reminds the reader to make sure what you’re doing is working well within your own context instead of blindly following a particular methodology, citing examples of when it may not make sense to spend 6 months on the design, and other times when it may be essential to do so.

    Fear not, I’m currently working on a deeper, more detailed review. My apologies to Scott for making him have to chime in to review his own book 😉

    Oh, and DrPat, here’s some free advice: A spoonful of honey will catch more flies than a gallon of vinegar. Try encouraging people to do better without insulting what they’ve done and you’ll find you get much better results.

  • Surprise – it’s the author here. Despite being several light years away from objective on this I thought that until Dan or someone else provides a deeper review, I could answer some of the questions raised. I checked the blogcritics.org comments policy and didn’t see anything prohibiting authors chiming in, so here goes.

    As far as the value of the book and why you should read it:

    1) I stayed away from the traps of most management/leadership books I found. There’s not much jargon and no big theories. Instead it’s a book of advice on the things leaders often get wrong. It’s highly prescriptive and example based. And in many cases the mistakes I use to make points are ones I made myself as a manager on the early Internet Explorer and Windows projects at Microsoft.

    2) I picked chapters around both skills and kinds of work – the top 15 most important things. Chapter titles include: How not to annoy people, what to do when things go wrong, the truth about schedules, and how to make good decisions. All the topics you’d expect are in there, but they’re folded into chapters that reflect common questions or challenges leaders have.

    3) I wrote the book as a conversation. It’s what I wish someone had told me when I started leading projects, and it’s written in the way I’d want to be talked to. Informal, honest, direct, comical, relevant, practical.

    And in response to the Proprietor’s point – I totally agree with you. Your point is what drove my choice of chapter topics. Here’s a quote from from Chapter 2:

    “The worst thng is to blindy follow a set of rules or procedures that are clearly not working, simply because they show up in some famous book…”

    At least two chapters in the book, How to make good decisions and what to do when things go wrong, are written with your point in mind. They focus directly on how to deal with all the things that can’t possibily be covered in a single book.

    Last point: You can also see for yourself – there’s a free chapter “How to figure out what to do” up at http://www.artofpm.com. The writing style in the book is similiar to what you’ll find in other essays I’ve written on leadership and management at http://www.scottberkun.com/essays.

    And I’m glad to answer any and all questions about the book. I’ll check back here, or you can contact me at http://www.scottberkun.com/.

  • You’ll never know, though (unless you buy the book), because Dan is being so – well, stingy with his review…

  • One of the major flaws with most project management texts I have read, along with the methodologies I’ve encountered along the way is that they are far more focused on risk management for the service delivery organization than they are on delivering the project’s result on time and at the desired quality level. While the goals are of course aligned in many respects, a careful observation will show that most of the texts and methodologies support a CYA mentality far more than an effective approach for executing. There are simply too many real-world constraints built into any project management scenario for a theoretical framework to work as planned, and there’s precious little advice in these tomes on how to adopt these frameworks to a real world scenario (ever work in NYC and have to deal with a union, for example?).

    I well remember a project where we had a well defined drop-dead date, a well-defined ultimate deliverable, quantified risks and penalties associated, and yet we had a program management office that was insisting on ridiculously detailed project charters for each little substream within that project because the methodology demanded it. Had we acceded to their requests to keep reworking the charters instead of getting on with the crucial design and implementation work we would likely have still been there. This is the kind of scenario a book like this should deal with….

  • “If you want to sell the steak, you’ve got to let ’em hear it sizzle.”

    I don’t suggest you reproduce the whole book here – just clue us in to WHY you were impressed by it.

    Incidentally, Dan, I am myself an engineer, and have years of project management under my own belt. I frequently write reviews of technical materials, so on both levels, I know it’s possible to give your reader more than “I liked it” in such a review.

    How about it? Make a U-Turn, come on back, and expand your remarks. There’s time…

  • Let’s try again – why should we read the book – you don’t give us much reason to, other than saying you liked it, and the author recommends it.

    Please treat these comments as constructive, per se, a review needs some meat for a purchaser/reader to chew on.

  • dan

    If I told what I learned, you wouldn’t have much reason to read the book, now would you?

  • How about letting us know a little more about why you were impressed? You say you learned more in the first 100 pages of this book than from my years of experience. Like what, for instance?

    You quote the author in a comment: I believe there are concepts and tactics that underlie the various systems and methodologies. Why not give us one or two examples of such concepts and tactics?

    You’ve still got time to edit this post. As it stands, it’s barely a review, more like a drive-by…

  • dan

    He intentionally doesn’t espouse any particular methodologies over one another. I’ll just quote him on the subject:

    My goal in this chapter and in this book, isn’t to debate and compare methodologies or systems for doing things. Instead, I believe there are concepts and tactics that underlie them all and which need to be mastered in order to succeed with any methodology.

  • Some more information about the specifics of the book would be appreciated – what methodologies does it espouse, what technique does it recommend for herding cats, etc.