the art of project management

The Art of Project Management

Here’s a book review of The Art of Project Management by Scott Berkun that I wrote a week or two ago for another site.

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.

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.

Comments

 (Post a comment) | Comments RSS feed
  1. I thought for a moment that the book wasn’t very well named, until I realized that the title of your post was not the title of the book. Now I just think the post wasn’t very well named. Project management is not quite the same thing as programming. :) Now, for a book that’s really about the art of programming, Knuth’s “The Art of Computer Programming” is where it’s at.

    Comment by Levi on July 17, 2005 @ 12:35 am
  2. Whoops. I put it in the Programming category, so I must have had that in my head.

    Comment by dan on July 17, 2005 @ 7:26 am
  3. This book rooooocks. Best read in a long time.

    Comment by Steve on July 19, 2005 @ 2:07 pm

Comments are closed