This book is dull compared to the first book in the series, "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis". The authors take a reactive instead of proactive approach to project management. Read the four page antipattern synopsis in appendix B. The rest of the book regurgitates these items in expanded form. The text concentrates on project management problems and offers little in the solutions section. The antipattern named "standards" was helpful, however the material was duplicated from James Moore's book "Software Engineering Standards: A User's Roadmap".

AntiPatterns in Project Management contains easily read and digested templates on people, technology, and process management antipatterns. The examples are concise, yet they offer enough information that experienced programmers and project managers will cringe when they read the stories. The antipattern templates are easy to read and understand. And they provide a consistent framework for the discussion about exceptions, refactored solutions, typical causes, etc.

A very talented software engineer highly recommended this book to me as an engineering manager. I was intrigued to find that some of the Amazon.com reviews were sooooo negative. However, I bought the book anyway and found it to be quite useful.

The book uses the methodology of AntiPatterns, which is a hot topic in the software development community, to analyze problems with project management. This is simultaneously the book's strength and its weakness. Antipatterns are just one tool; one way of looking at the world; one way of analyzing a situation. Another useful addition to the toolkit is always welcome and the book clearly delivers one. On the other hand, if you are looking for the unified theory that will solve all project management problems, it doesn't deliver on that. (I am still looking for that book.)

One reason the book might receive mixed reviews is that it does have a tone of irreverence towards management. For example, in the Executive Summary, it says "The primary cause of software development failure is the lack of appropriate project management." While this may be true, some project managers may not enjoy reading about it. Similarly, the book has a tendency to identify the root cause of problems as "haste, ignorance or sloth", most likely on the part of management. This may be true, but perhaps not all that helpful or enjoyable to read.

Overall, I found the book to provide a valuable perspective on software project management. The book will not solve all of the world's project management problems but that's OK with me.
Read the book and use the principles wisely.