Scott Berkun worked for 10 years at Microsoft Corporation on IE, MSN, and Windows.  He worked for two years in Microsoft's engineering excellence group, teaching and consulting with development teams.  Now an independent consultant, he runs pmclinic, a discussion forum on project management at http://www.scottberkun.com .  He has studied computer science, philosophy, and design at Carnegie-Mellon University.

I first started to write this review several months ago, when I was about to embark on a large project where I would be responsible for managing a good-sized group trying to bring about the impossible in record time for the ungrateful; you know, the usual stuff.

 Berkun's dense and only slightly picture- or diagram-populated work seemed to mean that reading it would be more like "work" than the sort of "fun" one has reading other types of books, for example, many book about Python.  I did give it a few stabs, looked at most of the pictures and diagrams, and read a paragraph here and there, and, well, back to work! So the book got put back on the shelf, to be read "another day".

Several months afterward, when the large project that was initially the impetus for needing this book disappeared, it seemed like this book would just forever collect dust.  But then, there were all those smaller problems, those open-source collaborations, those volunteer projects, and the constant questioning: "Could there be a better way?"

Dust off Berkun's book!  What is the intended audience?  New or experienced team leaders and managers.  Individual contributors, testers, other contributors.  Students of business management, product design, or software engineering.  Who is _not_ in one of those groups?  Who doesn't want to learn to do what that do better?

The book can be read cover-to-cover, or, as I've used it, when a particular chapter is of interest.  Berkun suggests that you read chapter one, "A brief history of project management (and why you should care)" - it's only 16 pages and gets you oriented for the rest of the book.

And that rest of the book is organized in three major sections, Plans, Skills, and Management, with 5 chapters within each of these major sections.

Besides the style of writing that allowed me to jump into a topic of interest and start immediately benefiting, the other thing I liked was the smooth interweaving with, if you will, philosophy and motivation with solid "here's what to do" advice.  For example, in the chapter "The truth about schedules" we learn that schedules server three functions, that big schedules must be divided into smaller schedules, that estimates are probabilities (which works against schedule accuracy), and that schedules must be made with skepticism, not optimism. (Programmers tend to be optimists.).  But even with those basics, there are clearly hard-learned lessons rolled in:  Take the risk early in the project, because late-term risk is much worse.  Gauge the team's confidence and experience working together (might seem obvious in retrospect, but this is easy to overlook when in the heat of a project).  Match milestones to project volatility.  Make sure the team knows the planning philosophy.

This "hear are some industry best practices" coupled with the "in-the-trenches" wisdom that only comes by having done it - that is the essence of this book's strength.

Another nice thing Berkun does is produce comprehensive lists from time to time that you can, well, just crib and use directly.  For example, in the "Writing the good vision" chapter, he provides a page and a half of important questions that must be answered before any sort of project vision can be articulated, such as "How is this not a technology in search of a problem?"  and "Why will these customers buy or subscribe to this service?" and "What is this project _not_ going to accomplish?"  and  "What are some likely ways this project may fail?  and how can they be minimized?".

There is even a chapter "Power and politics".  Whenever you get more than two people together, you've got politics.  And programmers tend to underestimate its importance.  It's great to see this subject fairly tackled here with the same objectivity as the other subjects.

Bottom line: buy this book!  You'll immediately get a benefit by reading the one or two chapters that are most effecting your work right now.  Then keep it on your bookshelf.  Because in a week, or a month or two, when your situation changes, you'll find more sage advice in there.  You'll be glad you have your friend Scott close by.