This book's been enjoyable and useful to read. There are some sections which didn't give me a lot of value, and I think some hard trimming to shorten the book's length would have been useful, but overall it's been a positive addition to my bookshelf.

I don't line up 100% with Berkun's approach to project management - he seems to be heavy on loading up on extensive documentation up front, and he's seemingly tepid about specs being a conversation vehicle between stakeholders and developers. I'm adamant that specs need to evolve with the stakeholders, analysts, devs, testers, and other team members being active participants in the process.

Those nits aside, I got great value out of a number of Berkun's chapters, particularly those around leadership and trust, decision making, and recovering when things go wrong. He's also got exercises at the end of each chapter which help get thought-provoking juices flowing. Additionally, there's a lot of small, useful details in this book as well, ranging from writing good e-mails to advice on running meetings.

Overall it's been a good read and I'd happily recommend it.

For those who gave this book a 5 star rating, I really suggest you think it again. To me, this book is over praised, way too much!! And there are several reasons why I am saying that.

First of all, the majority of the content has been expressed long before; I don't see anything new or groundbreaking. For example the author talked a lot about the importance of communication, trust, relationship, etc. in project management. But isn't that just common sense? Whoever does the project management job should know that pretty well. Not to mention that Agile/Scrum/XP guys have been saying these things for many years and in a much better and enlightened way.

Second, the book is flawed in the topics the authors chose to address. For example risk management is a big topic in project management, while there is only a chapter called "what to do when things go wrong" (which is not risk management exactly) and look at what he said, "calm down ... take responsibility ... do damage control ..." Again, common sense. And let's look at what the author said about the topic of execution, which makes things happen (Or "Getting things done") -- "Priorities Make Things Happen ... Things Happen When You Say No ... ". Well, I don't see any breakthrough ideas. And what I don't get is that, while the author spent so little time in talking about big topics like risk management and execution, he spent several chapters talking about how to deal with ideas, especially the ideas in design phase -- Chapter 5 "Where ideas come from" , Chapter 6 "What to do with ideas once you have them", Chapter 7 "Writing good specifications (i.e. writing the idea down)" and Chapter 8 "How to make good decisions (when facing several ideas)". For the book addressing the whole life cycle of project management, I just don't get the author's logic.

Third, it is very hard for you to read the book from cover to cover because there seems to be a tendency to go off at a tangent from time to time. The information author represented in each chapter actually prevent you from concentrating on the central topics of that chapter.

The exercises introduced in second edition are artificial. The most obvious change introduced in the second edition is the exercises introduced in each chapters. They were said to be "thought-provoking". So let's just check some of them. This is an exercise in the chapter "what to do when things go wrong" -- "One week into development, space aliens attack your office and your entire programming staff is hit with an alien space ray that makes them 50% less talented. You are the only witness to the event, as the ray erased the staff's memory of the event. ... " Seriously, you really believe figuring this question out will help you improve your ability for managing crisis ? Okay let's check another exercise in chapter "writing the good vision", "Research visionaries. Select any two: Gandhi, Malcolm X, Thoreau, Buddha, Socrates, Jesus Christ, or Confucius. What were their visions? How did they develop their ideas? ..." We are not doing philosophy, are we? BTW I actually like the author changing the book title from "the art of project management" to "making things happen". The term "the art of" has been overused, but in its original meaning, I really think it should be only referred to the great books like "the art of computer programming"

I don't mean to be harsh here and I am not saying this book is not good at all. Just seeing there are so many praises like "beg to be read cover to cover" or "great/classic..." makes me believe someone should stand up and raise a different, supposedly objective voice.

This is indeed a great introduction to project management basics, with a particular focus on web and software projects.

I found it very useful as the chapters deal organically with all the phases of a normal project, underlining challenges and dangers.

Great also all the bibliography Scott suggests, that allowed me to follow up the topics most interesting to me.

Scott's past at Microsoft and his bits of experience there that he shares in the book, are a great plus.

This is a second edition book. The first edition was titled "The Art of Project Management." The original text was "cleaned-up, enhanced, updated, and expanded."

I am disappointed in this book. I am really disappointed that I am disappointed in this book. I subscribe to Berkun's blog, enjoy it, and learn from it. Perhaps that is why I am so disappointed. The book lacks much of the quality I find in Berkun's blog.

The book is written in a manner that grates my teeth. It seems that someone would have edited this. It is plagued with endless verb-preposition combinations. I don't understand how those "get past" or "elude" editors.

I also tried to find a theme in the book. It seems to me that you can take hundreds of blog entries and write a good book,a as long as you tie the blog posts together with a theme. I can't find a theme in this book.

Berkun used to work at Microsoft. Perhaps this is the source of my disappointment. This is like a couple of other books I have read that were written by current or former Microsoft employees. The theme is that "this person worked at Microsoft (when Microsoft was doing great software - whatever that means), so they must really know something. Well, it seems that someone at Microsoft at the time had a good idea for a product (solve the right problem), and Microsoft had some good, smart people working there who could build the product (solve the problem right). The Microsft employee wrote a book wrote about what they saw, but they didn't seem to notice what I wrote in the previous sentence. Instead, the went on and on for 200 or 300 pages about stuff. None of the stuff is new or ground breaking or enlightening or anything else.

The vast majority of the content has been expressed elsewhere, long before, and in better prose. This leads me to believe that the author did little research in writing the book. Again, I love Berkun's blog, so I am disappointed to be so disappointed with this book.

Amazon is a good and fast services. I like this book so much. I will buy books from amazon again