Making Things Happen: Mastering Project Management

Summary of “Making Things Happen” : Project management is a complicated art which requires you to master a number of things such as planning, understanding what needs to be done, writing a good overall vision statement, understanding where ideas come from, understanding what to do with ideas, writing good specifications, understanding how to make good decisions, communication and interpersonal relationships, what to do when things go badly, understanding why leadership is built on trust, making things happen, managing the strategy in the middle and at the end of the project, or understanding questions of power and politics; this book describes in detail each of these components and gives us numerous methods and tricks for mastering them.

By Scott Berkun, 2008, 370 pages.

Note: Since Making Things Happen book is both thick and complex, I am publishing the summary in two parts. This is the first.

Summary and Book Report of Making Things Happen:

Scott Berkun is an author and speaker who has worked at Microsoft for 9 years as a project manager going from Internet Explorer, Windows and MSN. In 2005, he published the first version of this book, The Art of Project Management, which was centered more around project management in the area of software development and the phenomenal success of which, for a book of this type, led to this revision, in which the subject is more general and touches on general project management, for any sector.

Every chapter ends with a list of exercises – extremely relevant – to reflect on the subjects dealt with and put them into practice. I am giving you one at the end of each chapter summary. This will definitely guide you in making things happen.

The author begins by telling us that the idea of project management goes back a long way in human history. Everything that humanity has built, from the Egyptian pyramids or the Roman aqueducts up to a Boeing 777 or the Hubble space telescope, have been designed and then implemented. Between these two stages of making things happen, is found the art of leading long and complex projects to fruition.

The author wonders if there were points in common between all these projects and if he could find common denominators. He did not always find obvious answers, but each time that he returned from his quests into the past to dive into the world of software development, his own tools and processes appeared differently to him.

And there were three lessons that he drew from these expeditions:

1. Project management is not a holy art. All modern engineering work of making things happen is a new foray into history and things already realized. Technology and skills might change, but the central challenges remain the same. Everything is both unique and derived from something else. To be able to re-use past knowledge, you must be open to both.
2. The simpler your vision of what needs to be done, the greater your power of concentration to accomplish it. If we keep a simple vision for our work, we can find useful comparisons with other ways of doing things all around us. It’s a similar concept to what the Japanese call shoshin, or keeping a beginner’s mind – an open mind – which is an essential element in martial arts. Staying open and curious is what makes growth possible. To continue learning, we must resist the temptation to succumb to the safe and narrow visions concerning what we are doing.
3. Simple doesn’t mean easy. The best writers, athletes, programmers, and managers tend to be people who see what they do as simple by nature and difficult at the same time. For example, it is simple to run a marathon. You begin running and you don’t stop until you have completed 40 kilometers (26 miles). What could be simpler than that? The fact is that the difficulty of it does not reduce its simplicity. Leadership and management are also difficult, but their nature – making it so that things happen in a specific way towards a specific objective – is simple.

Additionally:

• Project management might be a job, a role, or an activity.
• Leadership and management require understanding and intuitive knowledge of numerous common paradoxes, such as:
  • Ego/No-ego: The ego can be a driver for managers, who often derive great personal satisfaction from their work. However, managers must avoid placing their own interests above those of the project and must delegate important and fun tasks, and share the rewards.
  • Autocrat/Delegator: In certain situations, the most important things are a strong and clear authority, and a quick response time. The manager must have the necessary confidence and the will to take control and force certain actions. However, the general objective must be to avoid these situations.
  • Oral/Written: Even though many organizations today are email-centric – notably software development companies – oral communication is still important, there are always meetings, negotiations, hallway discussions, and brainstorming sessions. In general, the larger the organization or project, the more writing skills are important. But a good manager must recognize when written or oral communication will be more efficient.
  • Courage/Fear: One of the biggest misconceptions of our culture is that brave people don’t experience fear. That’s a lie. A brave person is one who feels fear but chooses to act anyway.
• If you are a dedicated manager, find ways to capitalize on your unique perspective of the team and the project.

In the end, making things happen means all projects use similar processes; they all allow time to plan, implement and refine.

Part 1: Plans

Chapter 2: The Truth About Schedules

People tend to be late. It might only be a few minutes, or from time to time during the week, but people often fall behind on their daily schedule (however, because denial is a great skill we humans have, I will understand if you refuse to admit that it applies to you). For many of us, being on time doesn’t mean at an exact moment but over a span of time. For some, it is larger than for others.

So it shouldn’t come as a surprise that so many projects end up being behind schedule. We tend to base our estimates on weak assumptions, to predict results by banking on the best possible circumstances, and – basing ourselves on our previous experiences – we simultaneously avoid putting our trust in the forecasts that we see or create.

In this case, if schedules are not reliable, why use them? Because they primarily serve three purposes:

1. They allow the team to engage.
2. They encourage everyone to see their work as a contribution to the whole.
3. They allow us to measure progress.

Thus even if schedules go awry, they still have value.

Additionally:

• Big schedules must be divided into small plans to minimize risks and increase the frequency of adjustments.
• All estimates are probabilities. Because schedules are collections of estimations, they are also probabilities. This works against scheduling precision because probabilities are cumulative (80% x 80% = 64%).
• The more estimates you make, the less precise they are. However, rough estimates are the only way to create a point of departure for having better ones.
• Schedules must be made with skepticism, not with optimism. Invest time in the design phase to highlight the assumptions made and the confidence that has been placed in them.

Exercise:

If you use a calendar, take a look at yesterday’s schedule. How many events happened on time. For those that fell behind schedule, how many were your fault?

Chapter 3: How to figure out what to do

Few people agree on how to plan projects. Often, most of the time spent during the planning stage is wasted on getting people to agree on how the plan should be done. It is therefore not surprising that many books about project planning do not agree with each other. Some focus on the commercial strategy, others on engineering, and some on understanding the customer’s needs. What is most distressing is not the different points of view; it is the fact that very often they’re written as if the other points of view didn’t exist. It’s strange since none of the perspectives – business, technology, customer – can exist without the others. Moreover, in general, project planning success is arrived at in the intersection between the different points of view.

Because of this, each project needs to ask these questions:

• Who has responsibility for requirements definition? Someone needs to define the requirements to which the project is responding, and get them approved by all interested parties.
• Who has responsibility for the design? The design is different from the requirements definition because there are always several possible designs when responding to a requirement.
• Who has technical responsibility? Whoever chooses which engineering approach to use, which includes tools and architecture approach.
• Who has budget responsibility? The ability to add or remove project resources might be independent of other types of responsibility, particularly when it is a project being implemented for a customer.
• How frequently are requirements and designs reviewed, and how will adjustments be decided?  The response depends in large part on the preceding questions. What’s more, there are parties involved who each have different responsibilities, so there must be effort put into keeping everyone synchronized during the project.

Additionally:

• Different projects require different planning approaches.
• How planning is done is often determined by who has the responsibility.
• There are some common deliverables for project planning:
  • Documents on marketing requirements
  • Documents on the vision and overall approach
  • Specifications
  • Structure for breaking up the project
• The most powerful project planning method involves using the three perspectives equally: business, technology, and customer. The customer perspective is often the most misunderstood and badly used.
• Asking questions forces you to think well and focus your energy efficiently.
• The requirements definition process is difficult, but there are some good reference books on how to do it.
• Researching problems and scenarios are the simplest way to define and communicate requirements. They are easily converted into design ideas without losing what is important and what is not about them.

Exercise:

Imagine that you are the manager of a project where the engineers and marketing staff don’t like each other, and they are fighting about basic decisions. What actions could you take to improve their relationship? (Hint: What questions have not been asked? What points of view have not been represented?)

Chapter 4: Writing the good vision

One of the challenges for a project leader is keeping people focused on the same objectives for long periods of time. Therefore the challenge in project management is not just getting things started in the right direction, but also getting things to stay on track.

To do this, a document explaining the project vision is essential. Actually, writing is undoubtedly the greatest technology man has ever invented because it decouples the abilities of our brain, of which memory is notoriously unreliable, especially when it comes to retaining complex things. Putting things on paper allows us to free our mind up which in turn can dedicate all its energy to the tasks that we have outlined (the effectiveness of GTD comes therefore directly from the entrusting all our tasks to a reliable written system.

It is not useful to write volumes. The  Declaration of the rights of man is only a page or two long. The first Constitution of the United States is only one page long. If a government has been able to define the vision for its country’s system in such a small amount of space, you can do the same thing to describe your project’s vision. Typically, the vision statement is no longer than six pages.

Additionally:

• Vision statements distill planning artifacts into a single high-level plan.
• Writing things down serves both the writer and the team. It provides a basis for discussion and a point of reference that does not depend on people’s fallible memory.
• The amount of detail of a vision statement varies with the nature of the team and the project.
• Team objectives must be derived from the objectives defined in the vision. Individual objectives must be derived from team objectives.
• Good visions are simple, goal-oriented, consolidated, inspiring, and memorable.
• Quantity does not mean quality. It takes more effort to be concise than the other way around.
• Keep the vision alive by asking questions about the usefulness of the vision and about the daily decisions of the project.

Exercise:

What will happen if someone’s individual objectives conflict with those of the team or the project? Who does the responsibility fall upon to correct that? What actions should he or she take?

Chapter 5: Where ideas come from

The not very surprising truth about the origin of ideas is that they come from people. That is to say, there is nothing magic about ideas. We are all capable of having them – even though some of us are better than others. Never forget that it is fundamental to human nature to use our creative powers to resolve the problems that humans encounter in the world. Despite the poor education that we have in the modern world to use our talents well, they are there.

Whatever the project is, the ability to find good ideas is important from the first day to the last day. The outcome of these ideas can vary (some impact the whole project while others a single line of code), but the process for discovering and selecting them is the same. This process serves to fill the void between requirements and solutions. Just as the fact that we know where we are going does not help us find the best path when we come to an unknown fork in the road, knowing our requirements does not tell us anything about what decisions to make when we must choose between several solutions. Intelligent travelers find ways to minimize their chances of straying down a cul-de-sac, perhaps by walking a short distance along each path and trying to find another point of view (a hill, a mountain, a geostationary spy satellite controlled from a distance) which gives them more information. The further they need to go on their journey, the more they will probably need to find time to explore.

There are two simple ways to fill the void between requirements and solutions; a high-quality requirements definition, and design exploration. These two ideas are tightly coupled.

The requirements definition basically communicates the customer’s needs and/or the project objectives, with sufficient clarity to allow them to be converted into actions by those doing the work. A good requirements definition does not simply define how to solve a problem; instead, it identifies the problem clearly enough that someone with good expertise can work with confidence to accomplish it. The requirements definition is critical. It serves as a point of departure to generate ideas and potential solutions. If the requirement states “there shall be a door and it shall be green,” everyone who is going to conceive how to complete the project is going to think of different kinds of green doors.

Once the requirements definition is in place, people can explore the territory encompassed in the requirements. There is a large space, called the problem space, the potential means for resolving any problem. As far as requirements, this space might be large, for example, there is an infinite variety of ways to create a house, a meal, a website, or anything you are paid to do.

Additionally:

• Many teams do not manage their time well between requirements and specifications.
• A high-quality requirements definition and an exploration of the concept are the best use that you can make of your time.
• Ideas are good or bad only with the objectives or other ideas.
• Constraints are useful for finding ideas, but thinking outside the box is not necessarily the answer. Sometimes the best solution is to find a better way of working with the constraints.
• Questions, perspectives, and improvisation games are tools for finding new ideas.
• The best place to being with design ideas is the customer’s experience.
• Ideas morph into designs via conversations between different people with different types of expertise.

Exercise:

Find someone who you think is more creative than you. Ask him where he gets his ideas, and what habits he has that cultivate his creativity. Take one of the habits he uses and try it for a week (if you can’t think of anyone, take Picasso, Einstein, or any person famous for his creativity in your field).

Chapter 6: What to do with ideas once you have them

As hard as it is to find good ideas, it is even more difficult to manage them. Even if good design ideas are investigated, and even if people are excited about the work they are doing, the challenge of converging on the specifications remains intact. If moving faster does not result in definitive design decisions promptly and things are not well managed, disaster hits you in the face. For many reasons, that is where project failure begins.

The solution is to manage the field of possible ideas cautiously in making things happen. Someone must plan and guide each step of the specification exploration.

Additionally:

• Ideas have their own inertia. It will take longer to dominate the creative process than you think.
• Create checkpoints for creative work so that you can follow it and manage it. Common checkpoints include feasibility studies, regrouping of ideas, three alternatives, two alternatives, and one design.
• Use affinity diagrams to consolidate ideas.
• Prototypes allow a project to confront problems early and learn about errors without significant risk.
• Use iterations, or the progressive refinement of a prototype, to ask questions, evaluate progress, and decide the next steps.
• Create a list of open problems to follow up with the questions that need resolution before the specifications are completed.

Exercise:

In making things happen, should ideas be managed openly or privately? Who on your team should have access to a) view b) modify c) add or delete ideas?

Part 2: Skills

Chapter 7: Writing good specifications

Many experienced people fall into the trap of thinking that there is only one good way to write specifications, which tends in general to be the last thing they did. They assume that because projects were not a complete disaster, that the way they wrote (or didn’t write) specifications contributed in a positive way to the result – a claim which, without investigation, may or may not be true. Even worse, if good questions about how and why the specifications were written were never asked, no-one on the team can truly understand what is a good or bad process for writing specifications, or up to what point they contributed or did not contribute to the team’s performance.

There are therefore many ways to write specifications, which could each be better tailored to the situation. But they should all do three things for the project:

• Ensure something good gets built.
• Provide a schedule of milestones that concludes the planning phase of the project.
• Allow an in-depth review and feedback from different individuals during the course of the project.

Additionally:

• Specifications only resolve certain problems. Team leads should be clear about which problems they are trying to solve with the specifications, and which problems should be solved by other means.
• Good specifications simplify. They are primarily a good form of communication.
• Specifying is very different from designing.
• The person who has control over writing the specifications should have clear authority.
• A review process is the simplest way to define and control the quality of the specifications.

Exercise:

Tale a big bucket of LEGOs and find another project manager. Divide the LEGOs into two piles, putting the same number and the same types of pieces into each pile. Sit down with your back to the other manager, until one of you creates something with the LEGOs (it doesn’t matter what it is). Once that’s done, the one who did it tells the other one, using only words, how to build the same thing. Compare results. Then repeat the exercise, changing roles.

Chapter 8: How to make good decisions

A dozen project managers were interviewed while this book, Making Things Happen, was being written. One of the questions that Scott Berkun asked is how they make good decisions. Most of their responses included weighing options, defining criteria, and finding different ways to resolve problems. But when the author asked how many decisions they made in a day, and how frequently they used these techniques, they often realized that something was wrong. Many then admitted (after looking over their shoulder to be sure no-one was listening) that it’s impossible to always follow a formal process for decision making, given the limited time that they have available and the number of things that they need to do.

Instead, they agreed that they often make decisions based on their intuition, on reasonable assumptions, and a quick assessment of the immediate problem about the overall project objectives.

Bad decisions are very often not the result of a weak or inexperienced mind, but simply a bad division of energy and time available between the decisions needed in making things happen. There is a meta-process for deciding what decisions to invest time and energy on. It’s this ability which explains why some people can manage five times the amount of work than others; they instinctively divide their work into smaller pieces, finding the decisions and actions with the most leverage – 20% which makeup 80% of the results – one and invest most of their energy making these decisions and actions the best possible.

Additionally:

• Analyze decisions rather than spending too much time on them.
• Look at the indifferent zone and opportunities to use an assessment efficiently.
• Use comparative analysis for decisions that are worth the effort.
• All decisions have an emotional component, whether we admit it or not.
• Lists for and against are the most flexible method of comparative analysis. They allow us to involve others and get fresh perspectives on decisions.
• Information and facts can’t make decisions for you and cannot help you in making things happen.
• You will improve your decision-making skills by reviewing past decisions made and exploring them to find lessons and opportunities for better tactics in the process of making things happen.

Exercise :

Think about what you are going to do this weekend. Make a list for/against each of your options. Include a choice to do nothing and at least one hybrid choice (including a part with several options).

The rest in the next episode of Making Things Happen. 🙂

Making Things Happen Book Review is translated by www.DeansResource.com

Visit Amazon to read more reviews about Making Things Happen

Buy “Making Things Happen” on Amazon: