The Art of Project Management

Perhaps one of the reasons I am still doing engineering work rather than supervising it 26 years after I received my BSEE is that I could never properly wrap myself around exactly what it takes to manage a project. I therefore approached this book with a great deal of trepidation. However, after I began reading it I became pleasantly surprised. Most project management books I've read in the past intersperse advice on project management with software engineering techniques and Tony Robbins style motivational anecdotes. This one sticks to the subject and is well organized. The book is not about any one specific project management methodology, but about fundamental aspects of all projects. The author recounts his own experiences while managing projects at Microsoft to provide insight into the less transparent aspects of project management. The book is divided into three major sections: "Plans," "Skills," and "Management." This organization provides a logical flow overall and allows topics to build on one another. In spite of this logical progression, the chapters are fit for random access, as the author himself recommends. One of my favorite chapters was "Figuring Out What To Do". Here the author outlines three basic perspectives: The business perspective, the technology perspective and the customer perspective. The author states that although the customer perspective is the most important of all three that is the most neglected and is the reason that many projects fail. The chapter "How Not To Annoy People: Process, Email, and Meeting" was another chapter I really enjoyed. It offers down-to-earth recommendations on dealing with annoying behavior which the author lists in five categories: When others 1. assume you're an idiot. 2. don't trust you 3. waste your time 4. manage you without respect 5. make you listen to or read stupid things Since I've been guilty of being on the giving end as well as the receiving end of some of this behavior, this chapter helped me see some of the trouble I can cause myself as well as how I can effectively deal with it when it comes from others. However, this book is more than just about how to deal with socially backwards misanthropes such as myself. It dedicates considerable space to creativity, dealing with ideas once you have them, making ideas actionable by using affinity diagrams to consolidate ideas, and employing iterative prototyping. The third section of the book, which is specifically about management issues, contains chapters such as "Why Leadership Is Based On Trust". In that chapter the author points out that trust is built through commitment but lost through inconsistent behavior. Leaders must develop enough trust that people will bring issues to them during crises instead of hiding them. Trust, then, is at the core of leadership. Part of the reason that people will not trust some leaders is dealt with in the chapter "Power and Politics." Specifically, the author points out that power is misused when p

"The beginning is the most important part of the work." So says Plato in The Republic. So perhaps it is fitting that The Art of Project Management (Scott Berkun, O'Reilly 2005, 396 Pages, ISBN 0596007868) is written by an experienced project manager that studied not only computer science and design, but philosophy as well. Clearly and thinking man, his thoughts and experiences as a product manager at Microsoft are tied into historical perspectives of grand projects of history, and translated into an easy to read and follow format. It does not matter if you are the sole developer on a project, part of a team, or the leader of a project. This book provides valuable wisdom and insight that the success of a project is dependent on strong project management and planning from the beginning to the bitter end. From The Pyramids To The Kitchen Berkun is keenly aware of and believes in the notion that project management is not a new concept. At the start of the book, he takes us back to the days when the great pyramids were built and to the present with thoughts about modern-day restaurant kitchens. The latter is highly organized chaos, much like flight operations on an aircraft carrier. In the busy kitchen, everything is run so smoothly and efficiently despite constant flux in the environment. It is the history of project management and how it works outside peoples' normal thought processes that Berkun challenges the reader with from the beginning. Learning From Failure Berkun, who openly acknowledges the mistakes, failures, and challenges of his time at Microsoft is clear that organizations need to dissect every project after the fact so that lessons can be learned and applied. Throughout the book, he also emphasizes the importance of planning and setting realistic milestone schedules that can react easily to changes without major impact. The author then leads the reader through each step of the project life cycle, interjecting thoughtful discussion and not just rigid "book rules" and theories. He acknowledges the place of theory, especially in decision making, yet shows their limits when it comes to real life, time-constrained decision making. For this reader, the biggest strength of the book is its continual focus on the human dynamics associated with communication, leadership, and politics surrounding. Berkun argues that unless these are mastered, any project is doomed to failure. Who Should Read This Book? This book should be read by any system administrator or application developer involved in any size project. It should be read by people who want to be or are program managers, It should be read by those who manage project managers. And finally, it should be read by information technology compliance and governance professionals from two perspectives. The first is two understand the dynamics of project that pose governance challenges. the other is to see how they can apply the principles to their governance implementations. Scorecard Eagle o

Written with wit and keen insight and a generous mixture of anecdotes, this book serves to bridge the gap between theoretical and practical project management. While the reader can read the chapters randomly and still find value, the linear approach may give more benefit as the succeeding chapters build on concepts previously introduced. The author presents a refreshing way to look at project management. His perspective on the value of the vision document and the timing for creating the project schedule reveal some interesting insights. A good vision document can define the domain of a project, form the basis of the requirements, and set the success criteria. In discussing scheduling, he presents research that shows what we suspected all along, that scheduling too early is not only wildly inaccurate, but also hazardous to the success of the project. Although everyone can see that a project is trouble when the deliverables slip, throughout the book the author shares warning signs that indicate that the trouble has already started, and just as important, what can be done about it. The author's perspective is strongly influenced by his years as a product manager for Microsoft. While your mileage may vary, the book is full of golden nuggets for all PM staff. I suppose that the art of project management is really about understanding what should happen in your project and what is happening (and about to happen), and then using your creativity to bridge the gap. I wish that I had this book to read ten years ago. I think that I could have saved myself quite a bit of agony.

After many years as project manager in product development, I embarked on two software development projects, a new area for me, and found that some of my management skills were not relevant. After the first project stumbled, I purchased several software project management books and, after working through them in a disciplined way (taking notes on salient points and scaling them on their helpfulness for my work) found this to be the best. It is comprehensive - perhaps a little too wordy at times - and packed with practical advice. The lists of questions which come up regularly in this book can be turned into management check lists. Scott Berkun's points anticipated many of the problems I have since encountered; I am now reading this book for the second time and noticing things that were missed on the first read. As my experience has grown, I have come to recognize the voice of greater experience speaking through this book. Recommended for novices and experienced software project managers.

Scott does a great job in this book of providing well-organized, practically useful guidance on how to work on and run a project. Even if you're not actually in charge of a project, I'd recommend this as a book to help you understand what should be getting done on it. The three biggest areas he focuses on are how to ensure a project has proper focus and clear priorities, how to run meetings and do feature-level design, and how to handle a project as it moves from start to finish. The key to proper focus and clear priorities is the tie between the mission, goals, features, and tasks in a project. Scott provides a great framework for tying them together, ensuring they're created, and ensuring the team understands them. The advice on running meetings and doing feature-level design is the only area that might not work as well for those outside of Microsoft. While I highly identify with it, and think that he's clearly stated the best practices for our environment, your mileage may vary. Finally, he does a great job of talking about the difference between the start, middle, and end-game. Many people try to use a single process throughout and either overburden the start of the project or allow the end-game to spin wildly out of control. Scott's very clear about how to apply the right level of touch and raise the process bar at safe but necessary increments as a project goes on. The only negative thing I could find in the book is that some of the proofreading on the figures wasn't up to the same quality as the text. References to figures are sometimes pointing to the wrong one, and occasionally the legends are mislabeled.