|
It seems a great book and i bought it, but after reading the first chapters, you start to loosing the interest, is too dense and it's mostly centered in software project management, which it should say on the title.
He's also got exercises at the end of each chapter which help get thought-provoking juices flowing. 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. 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. 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.
Whoever does the project management job should know that pretty well. take responsibility. do damage control." Again, common sense. ". They were said to be "thought-provoking".
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. 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. 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. 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.
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. But isn't that just common sense. For those who gave this book a 5 star rating, I really suggest you think it again. 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. 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.
in project management. writing the idea down)" and Chapter 8 "How to make good decisions (when facing several ideas)". Okay let's check another exercise in chapter "writing the good vision", "Research visionaries. To me, this book is over praised, way too much.
" Seriously, you really believe figuring this question out will help you improve your ability for managing crisis. 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. How did they develop their ideas." We are not doing philosophy, are we. The most obvious change introduced in the second edition is the exercises introduced in each chapters. You are the only witness to the event, as the ray erased the staff's memory of the event.
BTW I actually like the author changing the book title from "the art of project management" to "making things happen". What were their visions. 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. Select any two: Gandhi, Malcolm X, Thoreau, Buddha, Socrates, Jesus Christ, or Confucius.
For example the author talked a lot about the importance of communication, trust, relationship, etc. So let's just check some of them. Well, I don't see any breakthrough ideas. 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.
Things Happen When You Say No.
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.
The theme is that "this person worked at Microsoft (when Microsoft was doing great software - whatever that means), so they must really know something. Perhaps that is why I am so disappointed. Perhaps this is the source of my disappointment. I subscribe to Berkun's blog, enjoy it, and learn from it.
The book is written in a manner that grates my teeth. 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. 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. It seems that someone would have edited this. I can't find a theme in this book.Berkun used to work at Microsoft.
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. 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). Instead, the went on and on for 200 or 300 pages about stuff. It is plagued with endless verb-preposition combinations. 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.
I am really disappointed that I am disappointed in this book. This is like a couple of other books I have read that were written by current or former Microsoft employees. I also tried to find a theme in the book. The book lacks much of the quality I find in Berkun's blog. I don't understand how those "get past" or "elude" editors.
|
