Book highlights: 'Making Things Happen' by Scott Berkun

Today, I heard that an old teammate has been referring back to these raw book notes that I shared with my team more than a year ago. So I'm slapping the gist into my website in case I need to refer to it again or share it with someone.

Please check out this favorite career-shaping book in its entirety here: Making Things Happen: Mastering Project Management

The balancing act of project management

• The early phases of any project are highly open and fluid experiences where the unknown heavily outweighs the known. As we’ll discuss in Chapter 5 and Chapter 6, controlled ambiguity is essential for good ideas to surface, and a project manager must respect it, if not manage it. But at other moments, particularly in the later phases of a project, discipline and precision are paramount. It requires wisdom to discern when the quest for perfection is worthwhile, versus when a mediocre or quick-and-dirty solution is sufficient

• They must be willing to delegate important or fun tasks and share rewards with the entire team

• The balancing act here is to recognize which view of the project is most useful for the problem or decision at hand, and to comfortably switch between them or keep them both in mind at the same time (without your head exploding

• . A project manager must have a healthy respect for all the things that can go wrong and see them as entirely possible. But a project manager needs to match this respect with the courage necessary to take on big

• . The balancing act is to somehow vigorously ask questions and challenge the assumptions of others without shaking the team’s belief in what they are

Pressure and distraction

• But getting back to the issue of pressure, I’ve seen many managers who shy away from leadership moments (e.g., any moment where the team/project needs someone to take decisive action) and retreat to tracking the efforts of others instead of facilitating or even participating in them. If all someone does is keep score and watch from the sidelines, he might be better suited for the accounting department. When someone in a leadership role consistently responds to pressure by getting out of the fray, he’s not leading—he’s hiding. Ineffective or pressure-adverse PMs tend to fade into the periphery of the project, where they add little value

Confusing process with goals

• To minimize the possibility of confusion, good project managers resist defining strict boundaries around kinds of work they are willing or not willing to do. They avoid bright yellow lines between project

• management tasks and the project itself. Adherence to checklists implies that there is a definitive process that guarantees a particular outcome, which is never the case. In reality, there are always just three things: a goal, a pile of work, and a bunch of people. Well-defined roles (see Chapter 9) might help those people to organize around the work, but the formation of roles is not the goal. A checklist might help those people do the work in a way that meets the goal, but the checklist is not the goal either. Confusing processes with the goals is one of the great sins of management. I should know: I’ve committed it myself.

Project managers create unique value

• So, if the project manager is focused on, committed to, excited about, and capable of succeeding, the odds increase that everyone else will behave the same way.

Schedules have three purposes

• Schedules have three purposes

• The first is to make commitments about when things will be done

• The second purpose of a schedule is to encourage everyone to see her efforts

• The third purpose of schedules is to provide a tool to track progress and break work into manageable chunks

• A schedule cannot remedy bad design or engineering practices, nor can it protect a project from weak leadership, unclear goals, and poor communication

• for as much time as it takes to create schedules, they are still just lists of words and numbers. It’s up to someone to use them as a tool for managing and driving the project

What schedules look like

• Here’s how the rule of thirds works. Break the available time into three parts—one for design, one for implementation, and one for testing

• The rule of thirds is useful in that it forces the zero-sum nature of projects to surface. Adding new features requires more than just a programmer implementing them—there are unavoidable design and testing costs that someone has to pay. When schedules slip, it’s because there were hidden or ignored costs that were never accounted for

Divide and conquer (big schedules = many little schedules)

• The more change and project volatility that is expected, the shorter each milestone should be. This lowers the amount of overall risk in the schedule because the master plan

• has been divided into manageable pieces. Those breaks between chunks of the schedule provide natural opportunities to make adjustments and improve the chances that the next milestone will more accurately direct its work

A schedule is a probability

• . Good schedules come only from a leader or a team that relentlessly pursues and achieves good judgment in many different aspects of software development. You can’t be an expert in one narrow part of the making of things and ever expect to schedule

• The secret here is that a schedule doesn’t have to be perfect (which is a relief, of course, because there are no perfect schedules). Schedules need to be good enough for the team and the leaders to believe in, provide a basis for tracking and making adjustments, and have a probability of success that satisfies the client, the business, or the overall project sponsor

The common oversights

• Here’s my pet list of questions that have helped me to catch potential schedule problems early on. Most of these came from asking questions about what went wrong

• Were sick days and vacation time for all contributors included in some form in the schedule? Were holiday seasons, or other times of year with major distractions, factored in (e.g., from Thanksgiving to Christmas in the U.S., summers in Europe)? Major deadlines are extremely hard to hit during these times. Did individuals have access to the schedule, and were they asked to report regular progress (in a non-annoying way)? Was someone watching the overall schedule on a daily or weekly basis? Did this person have enough authority to ask good questions and make adjustments? Did the team feel ownership and commitment to the schedule? If not, why

• Did the team contribute to the definition of the schedule and the work to be done, or was it handed down to them? Did team leaders add more feature requests than they helped eliminate? Did team leaders ever say no to new work and provide a reasonable philosophy to the team for how to respond to new (late) requests? Were people on the team encouraged to and supported in saying no to new work requests that didn’t fit the goals and the vision? What probabilities were used in making estimates? 90%? 70%? 50%? Was this expressed in the master high-level schedule? Was the client/VP/customer aware of this? Was there discussion of another proposal that took more time but came with a higher probability? Were there periodic moments in the schedule when schedule adjustments and renegotiations could take place by leaders and management? Did the schedule assume fewer working hours over holiday seasons? (In the U.S

• Thanksgiving to Christmas is often a low productivity time.) Are any highly probable disruptive weather events weighed into the schedule (for example, blizzards in Chicago, tornados in Kansas, sun in Seattle)? Were the specifications or design plans good enough for engineering to make good work estimates? Was engineering trained or experienced in making good work estimates

What must happen for schedules to work

• Milestone length should match project volatility

• Be optimistic in the vision and skeptical in the schedule

• Bet on design

• Plan checkpoints for add/cut discussions

• Inform the team about planning philosophy

• Gauge the team’s experience with the problem space

• Gauge the team’s confidence and experience in working together

• Take on risks early

3. How to figure out what to do

• The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult in establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements

How organizations impact planning

• How organizations impact planning

• Who has requirements authority

• Who has design authority

• Who has technical authority

Common planning deliverables

• To communicate requirements, someone has to write them down. There are many ways to do this, and I’m not advocating any particular method. What matters most is that the right information has been captured, the right people can easily discuss it, and good commitments are made for what work should be done

• A vision document defines the goals of a project, why they make sense, and what the high-level features, requirements, or dates for a project will be (see Chapter 4). Vision documents directly define the “what” of a project

• Specifications. These capture what the end result of the work should be for one part of the project. Good specifications are born from a set of requirements. They are then developed through iterative design work (see Chapter 5 and Chapter 6), which may involve modifying/improving the requirements. Specs are complete when they provide a workable plan that engineering can use to fulfill requirements (how much detail they must have is entirely negotiable with engineering

• Specifications define the “how” of a project from a design and engineering perspective

• a specification details the work to be done, a WBS defines how a team of engineers will go about doing

Bringing it all together: requirements

• A requirement by definition is anything the team (and client) agrees will be satisfied when the project is completed

• Problem statements are one- or two-sentence descriptions of specific end user or customer issues. They’re derived from research or specific customer requests. They’re written in a format that identifies a need from the customer perspective (as opposed to the engineering or business perspective). This ensures that the customer viewpoint is maintained and not distorted by other perspectives

The key points to cover

• What are some likely ways for this particular project to fail, and how will they be avoided or minimized? (In early drafts, there might only be risk evaluations, but without plans for managing/avoiding them

It’s hard to be simple

• Good vision documents never shy away from their core ideas. They avoid prefaces, disclaimers, and introductions, and they make no attempt to hide from the key (and perhaps controversial) decisions that will define the project

• Many poor vision documents I’ve read were large volumes that were intimidating not because of the sheer brilliance of thought they expressed, but because of their physical size. The intimidation worked: no one read the document

Visions should be visual

• The best vision documents include visual images. They provide rough drawings, mock-ups, or prototypes of what the final result might look like if the vision is followed

Visualizing nonvisual things

• If this end result cannot be visualized—even as just a sketch, a mock-up, or a chart—then I’d argue that the vision is not clear. If you can’t find any visual representation of the impact of the project on the universe, be afraid that it’s directed toward something the world doesn’t need, or that it isn’t well defined enough for you to be successful

The gap from requirements to solutions

• ”). Smart travelers look for ways to minimize the chances of going down a dead-end path. Perhaps they walk a short distance down each road, or find another point of view (a hill, a mountain, a remote-controlled geocentric orbiting spy satellite) that gives them more information. The further they need to go on their journey, the greater the time investment for exploration probably needs to

• There are two simple ways to fill in the gap. High-quality requirements are one option, and design exploration is the other. Because they are highly related to each other, it’s common for these activities to overlap in time

Focusing questions

• A good focusing question draws the attention of a person or a group to the absence of something important, useful, or even central to the work being done

• Great project managers and creative thinkers are masters of questions. They sense when things are getting off track, recognize the essential elements missing from a discussion or a plan, and inject them back in with a carefully timed and phrased question

Bad ideas lead to good ideas

• Without making mistakes and oversights in many different attempts, it’s often impossible to find the path of ideas that leads to success

Good designs come from many good ideas

• designers proceed through many revisions with the full expectation that it may take dozens of attempts and adjustments to get it all right. Revision and refinement are the name of the game, and part of the

Perspective and improvisation

• To design something really well you have to get it. You have to really grok what it’s all about. It takes a passionate commitment to thoroughly understand something—chew it up, not just quickly swallow it. Most people don’t take the time to do that. Creativity is just connecting things. When you ask a creative person how they did something, they may feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after awhile. That’s because they were able to connect experiences they’ve had and synthesize new things. And the reason they were able to do that was that they’ve had more experiences or have thought more about their experiences than other people have

Managing ideas demands a steady hand

• fantasy, as it goes, runs like this: you show up one day, realize it’s getting late and that there are too many ideas and designs (and not enough decisions), and you say to the team, “OK, we’re done with ideas. Pick a design and let’s start coding! Woohoo!” Even at the off chance that there is a design that is ready for primetime (which there won’t be), this kind of unpredictable behavior will disorient and confuse the entire

• There should be easy and natural reminders to the team as the scope and emphasis change. Like a dimmer switch for lights—the kind with a knob that gives measured control over changes—there should be a gradual shift of focus. It’s the project manager’s job to manage that dimmer switch and make sure it’s controlled with a steady hand

• For the first half or so of the available time, everyone is focused on coming up with ideas and growing the space of alternative designs. For the second half, the emphasis shifts to narrowing the field by refining and improving the best designs. Eventually, a point is reached where enough design decisions have been made to document them all in a specification.

Checkpoints for design phases

• Checkpoints for design phases

• Figure 6-3. Checkpoints for design

• This might mean the design is still alive, and new thinking is being used to improve the design. But it could also mean that unnecessary directions are being explored. The checkpoints force the team to figure out which one it is, and acknowledge when the design space is growing larger than it should be

Where do prototypes start?

• Make a list of the hardest or most important design questions, and make a prototype(s) that will help answer them

• As a general rule, the more sophisticated the prototype is, the more sophisticated the questions it can answer. A sketch on the back of a napkin is fine for very early and very rough kinds of questions, but if you want to know something specific and be confident in the answer, you’ll need something more involved

Prototyping for projects without user interfaces

• Instead of user interface design issues, pick the most difficult or complex technical challenges and prototype them

Prototypes support programmers

• Just like there is no way for a designer to confidently answer complex design questions without a design prototype, there is no way for an engineer to confidently answer complex engineering questions without an engineering prototype (despite what he might say

Questions for iterations

• Here are some questions for early prototype iterations

Take responsibility

• Instead of wondering why some person is so difficult, I find it more useful to ask myself why I am having difficultly with that person. It is, of course, usually far easier to spot the mote in a colleague’s eye than to see the macaroni in your own, but every frustrating encounter with a difficult person is an opportunity to learn more about yourself. Over the long term, you may find yourself meeting fewer and fewer people who are difficult for you to handle.

12. Why leadership is based on trust

• real leadership is about very simple, practical things. Do what you say and say what you mean. Admit when you’re wrong. Enlist the opinions and ideas of others in decisions that impact them. If you can do these things more often than not, you will earn the trust of the people you work with

Building and losing trust

• trust is earned by people who do their jobs well, are committed to the goals of the project, treat people fairly, and behave consistently through tough times

Trust is built through commitment

• Trust is built through commitment

13. Making things happen

• The ability to make things happen is a combination of knowing how to be a catalyst in a variety of different situations and having the courage to do so

Priorities make things happen

• Priorities make things happen

• Making things happen depends on having a clear sense of which things are more important than others and applying that sense to every single interaction that takes place on the team

• These priorities have to be reflected in every email you send, question you ask, and meeting you hold

• Ordered lists provide everyone with a shared framework of logic to inherit their decisions from. If the goals are clear and understood, there is less need for interpretation and fewer chances for wasted effort

Priority 1 versus everything else

• This priority 1 line must be taken very seriously. You should fight hard to make that list as small and tight as possible (this applies to any goal lists in the vision document as well). An item in the priority 1 list means “We will die without this

Be a prioritization machine

• Whenever I talked with programmers or testers and heard about their issues or challenges, I realized that my primary value was in helping them focus. My aim was to eliminate secondary or tertiary things from their plates and to help them see a clear order of work