- Paperback: 410 pages
- Publisher: O'Reilly Media; Revised edition (April 4, 2008)
- Language: English
- ISBN-10: 0596517718
- ISBN-13: 978-0596517717
- Product Dimensions: 7 x 1 x 9.2 inches
- Shipping Weight: 1.4 pounds (View shipping rates and policies)
- Average Customer Review: 57 customer reviews
- Amazon Best Sellers Rank: #41,395 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Making Things Happen: Mastering Project Management (Theory in Practice) Revised Edition
Use the Amazon App to scan ISBNs and compare prices.
All Books, All the Time
Read author interviews, book reviews, editors picks, and more at the Amazon Book Review. Read it now
Frequently bought together
Customers who bought this item also bought
Based on his nine years of experience as a program manager for Microsoft’s biggest projects, Berkun explains to technical and non-technical readers alike what it takes to lead critical projects from start to finish. Here are 16 chapters on the critical and common challenges of leading projects and managing teams, diagrams, photography, and war stories of success and failure. Berkun offers practical tools and methods to make sure your projects succeed.What To Do When Things Go Wrong
From Making Things Happen, Chapter 11
2. Evaluate the problem in relation to the project. Just because someone else thinks the sky has fallen doesn’t mean that it has. Is this really a problem at all? Whose problem is it? How much of the project (or its goals) is at risk or may need to change because of this situation: 5%? 20%? 90%? Put things in perspective. Will anyone die because of this mistake (you’re not a brain surgeon, are you?)? Will any cities be leveled? Plagues delivered on the innocent? Help everyone frame the problem to the right emotional and intellectual scale. Ask tons of questions and get people thinking rather than reacting. Work to eliminate assumptions. Make sure you have a tangible understanding of the problem and its true impact. Then, prioritize: emergency (now!), big concern (today), minor concern (this or next week), bogus (never). Know how long your fuse is to respond and prioritize this new issue against all existing work. If it’s a bogus issue, make sure whoever cried wolf learns some new questions to ask before raising the red flag again.
3. Calm down again. Now that you know something about the problem, you might really get upset (“How could those idiots let
4. Get the right people in the room Any major problem won’t impact you alone. Identify who else is most responsible, knowledgeable, and useful and get them in together straight away. Pull them out of other meetings and tasks: if it’s urgent, act with urgency, and interrupt anything that stands in your way. Sit them down, close the door, and run through what you learned in step 2. Keep this group small; the more complex the issue, the smaller the group should be. Also, consider that (often) you might not be part of this group: get the people in the room, communicate the problem, and then delegate. Offer your support, but get out of their way (seriously—leave the room if you’re not needed). Clearly identify who is in charge for driving this issue to resolution, whether it’s you or someone else.
5. Explore alternatives. After answering any questions and clarifying the situation, figure out what your options are. Sometimes this might take some research: delegate it out. Make sure it’s flagged as urgent if necessary; don’t ever assume people understand how urgent something is. Be as specific as possible in your expectation for when answers are needed.
6. Make the simplest plan. Weigh the options, pick the best choice, and make a simple plan. The best available choice is the best available choice, no matter how much it sucks (a crisis is not the time for idealism). The more urgent the issue, the simpler your plan. The bigger the hole you’re in, the more direct your path out of it should be. Break the plan into simple steps to make sure no one gets confused. Identify two lists of people: those whose approval you need for the plan, and those who need to be informed of the plan before it is executed. Go to the first group, present the plan, consider their feedback, and get their support. Then communicate that information to the second group.
7. Execute. Make it happen. Ensure whoever is doing the work was involved in the process and has an intimate understanding of why he’s doing it. There is no room for assumption or ambiguity. Have specific checkpoints (hourly, daily, weekly) to make sure the plan has the desired effect and to force you and others in power to consider any additional effort that needs to be spent on this issue. If new problems do arise, start over at step 1.
8. Debrief. After the fire is out, get the right people in the room and generate a list of lessons learned. (This group may be different from the right people in step 4 because you want to include people impacted by, but not involved in, the decision process.) Ask the question: “What can we do next time to avoid this?” The bigger the issue, the more answers you’ll have to this question. Prioritize the list. Consider who should be responsible for making sure each of the first few items happens.
About the Author
Scott Berkun worked on the Internet Explorer team at Microsoft from 1994-1999 and left the company in 2003 with the goal of writing enough books to fill a shelf. The Myths of Innovation is his second book: he wrote the best seller, The Art of Project Management (O'Reilly 2005). He makes a living writing, teaching and speaking. He teaches a graduate course in creative thinking at the University of Washington, runs the sacred places architecture tour at NYC's GEL conference, and writes about innovation, design and management on his personal website.
Top customer reviews
The book is eminently readable, and the advice is well-grounded in real-world experience. As I read the book, I found myself taking notes for how to apply the information to deal with issues that were coming up in my own projects.
The tools from the PMBOK are valuable, but there are only so many times you can read a re-hash of an exam cram. "Making Things Happen" was a delightful read that reminded me why it is fun to run a project.
The book is written in a funny and informal way that allows it to be read and re-read without feeling like you're opening a textbook. I enjoyed how there weren't straight up procedures for exactly how a project manager should go about doing his/her job. There were rough guides, diagrams, anecdotes, and some suggestions for things that a manager could do, but it seemed obvious to me that these were meant to be interpreted and adjusted to fit both the situation and your own style.
I purchased this book on the Kindle. Now that I've read it, I'm considering purchasing an actual copy so I have one to flip through for reference in the future. I plan on referring this book to my coworkers as well. It has helped me define several things that I can work on to improve my success in my current job and any future jobs.
Kindly keep in mind that the above is not necessarily meant to be any sort of condemnation of the book. There are, in fact, many interesting ideas conveyed therein. But to represent this book as Mastering Project Management, as its subtitle imples, is really quite a stretch. One could probably make a good case that Mastering Project Management requires acquiring a working knowledge of the Project Management Body of Knowledge. And Amazon also makes available a very good and handy Guide to this Body of Knowledge. However, I would argue that Phillip Metzger's classic, "Managing a Programming Project", could more rightly be judged as accomplishing the goal of Mastering Project Management in a single volume. Now, readers of that wonderful book could point out that Metzger's book has a decidely Armonk, which is to say, IBM, flavor. However, Metzger's book really does provide a much better general overview to the topic of project management. Scott Berkun's book is not bad. It is simply not, as another reviewer has averred, deserving of the lavish encomiums heaped upon it by the majority of other, previous reviewers. If you want to learn how things were done successfully at Microsoft, by all means, pick up this book. But if you are looking for a more general representation of the serious business of project managment, I'd stick with Phil Metzger's. God bless.