Making Things Happen: Mastering Project Management (Theory in Practice)

In the updated edition of this critically acclaimed and bestselling book, Making Things Happen: Mastering Project Management (Theory in Practice), Microsoft project veteran Scott Berkun offers a collection of essays on field-tested philosophies and strategies for defining, leading, and managing projects. Each essay distills complex concepts and challenges into practical nuggets of useful advice, and the new edition now adds more value for leaders and managers of projects everywhere. Based on his nine years of experience as a program manager for Internet Explorer and lead program manager for Windows and MSN, Berkun explains to technical and non-technical readers alike what it takes to get through a large software or web development project. Making Things Happen doesn't cite specific methods, but focuses on philosophy and strategy. Unlike other project management books, Berkun offers personal essays in a comfortable style and easy tone that emulate the relationship of a wise project manager who gives good, entertaining and passionate advice to those who ask. Topics in this new edition include:

• How to make things happen
• Making good decisions
• Specifications and requirements
• Ideas and what to do with them
• How not to annoy people
• Leadership and trust
• The truth about making dates
• What to do when things go wrong

Complete with a new forward from the author and a discussion guide for forming reading groups/teams, Making Things Happen offers in-depth exercises to help you apply lessons from the book to your job. It is inspiring, funny, honest, and compelling, and definitely the one book that you and your team need to have within arm's reach throughout the life of your project. Coming from the rare perspective of someone who fought difficult battles on Microsoft's biggest projects and taught project design and management for MSTE, Microsoft's internal best practices group, this is valuable advice indeed. It will serve you well with your current work, and on future projects to come.

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

1. Calm down. Nothing makes a situation worse than basing your actions on fear, anger, or frustration. If something bad happens to you, you will have these emotions whether you’re aware of them or not. They will also influence your thinking and behavior whether you’re aware of it or not. (Rule of thumb: the less aware you are of your feelings, the more vulnerable you are to them influencing you.) Don’t flinch or overreact—be patient, keep breathing, and pay attention.

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 happen!?”). Find a way to express emotions safely: scream at the sky, workout at the gym, or talk to a friend. But do express them. Know what works for you, and use it. Then return to the problem. Not only do you need to be calm to make good decisions, but you need your team to be calm. Pay attention to who is upset and help them calm down. Humor, candor, food, and drink are good places to start. Being calm and collected yourself goes a long way toward calming others. And taking responsibility for the situation (see the later section “Take responsibility”), regardless of whose fault it was, accelerates a team’s recovery from a problem.

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.

A Guide to the Project Management Body of Knowledge: (Pmbok Guide)

The PMBOK9 Guide – Fourth Edition continues the tradition of excellence in project management with a standard that is even easier to understand and implement, with improved consistency and greater clarification.

• Standard language has been incorporated throughout the document to aid reader understanding.
• New data flow diagrams clarify inputs and outputs for each process.
• Greater attention has been placed on how Knowledge Areas integrate in the context of Initiating, Planning, Executing, Monitoring & Controlling, and Closing process groups.
• Two new processes are featured: Identify Stakeholders and Collect Requirements.

The PMBOK Guide is a standard for the project management profession. Its intention is to serve as a guide to the body of knowledge within the project management community and as practiced by members of the profession. There is no single document that contains the project management body of knowledge. Indeed, some of it is not published at all but, rather, is simply recognized as good practices and norms within the profession. This body of knowledge is growing every day.

The PMBOK Guide is not intended to be used to learn project management or project management concepts. It's especially not intended to teach or suggest PM techniques or methodologies.

This project management book is not a "how to" book nor is it a description of a methodology. It's a standard, not a methodology. PM professionals and the organizations they work for can use the PMBOK Guide as a guide for developing their own methodologies or for creating organization standards. 

It's particularly important to understand that it is not a standard or specification for the examination portion of the PMP certification. For one thing, at least 30% of the material on the examination is not covered by the PMBOK Guide. (There IS an exam on the PMBOK Guide. It's the CAPM exam, which only covers knowledge of the PMBOK Guide.)

While the PMBOK Guide only changes once every 4 years, the exam component of the PMP credential is constantly changing. Much of the material that showed up in the 4th (2008) edition of the PMBOK Guide has ALREADY been showing up on the PMP exam for several years - e.g., PTA, TCPI, etc. PMBOK Guide 4th edition came out in December, 2008, but these topics have been showing up on the PMP exam as early as 2006. The group at PMI that develops the standards (such the PMBOK Guide, the Standard for Risk Management, etc.) and the group at PMI that develops the the certifications and their corresponding exams (such as PMP, CAPM, PMI-SP, etc.) are two separate groups that DO NOT interface with each other. They are two separate groups. If anything, the standards group looks at the work that the credential group (PMP, CAPM) does and uses it as one of the many inputs for what they put into the standards such as the PMBOK Guide.