Making Things Happen by Scott Berkun

The simpler your view of what you do, the more power and focus you will have in doing

The trick then is to learn as much as possible from other people’s failures . We should

Even on our own projects, we need to avoid the habit of running away and hiding from

Perhaps this is why The Boeing Company, one of the largest airplane design and engineering firms in the world, keeps a black book of lessons it has learned from design and engineering failures . [

Often, seeing things firsthand is the only way to give people enough information to make connections among diverse ideas .

Or perhaps you have worked in situations where it seemed improbable that anyone else in the universe ever managed anything as complex as what you were doing .

As chaotic as they may seem at first, great kitchens run with a level of intensity and precision that blows most development teams away .

The Mythical Man-Month ( Addison-Wesley Professional, 1995 ) , makes similar comparisons between teams of surgeons and teams of programmers . Even

maintain a balance of attitudes . In his essay “Pursuing the Perfect Project Manager,” [ 6 ] Tom Peters calls these conflicting attitudes paradoxes or dilemmas . This name is appropriate because different situations require different behavior . This means that a project manager needs not only to be aware of these traits, but also to develop instincts for which ones are appropriate at which times . This contributes to the idea of project management as an art: it requires intuition, judgment, and experience to use these forces effectively . The following list of traits is roughly derived from Peters’ essay:

Some PMs in this situation resort to quantifying things that don’t need to be quantified . Unsure of what else to do, or afraid to do what most needs to be done, they occupy their time with secondary things . And

It’s possible that at some point the PMs begin to believe that the data and the process are the project . They focus on the less-important things that are easy to work with ( spreadsheets or reports ) ,

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 .

That is, until he saw me spending more time with my checklists and processes than I did with my team — a big red flag ( warning sign ) . He

“Scott, this stuff is nice, but your project is your team . Manage the team, not the checklists . If the checklists help you manage the team, great . But the way you’re going, soon you’ll be using your team to help you manage your checklists . ”

I’m confident that as long as the PM is paying attention and has earned the team’s trust, any missing tasks, processes, reports, checklists, or other needed project management machinery will become clear before the problems they might solve become serious .

The Mythical Man-Month .

When processes are required to manage processes, it’s hard to know where the actual work is being done .

over-involving themselves .

Instead, leaders and managers are hired to amplify the value of everyone around them .

Good project managers make it their business to know all kinds of useful things about the state of the team — and the state of the world

The PM should be able to perform feats of thinking, strategy, and leadership that positively impact the team in ways few others can . Often this involves finding shortcuts and clever optimizations in the daily workflow,

“Make good stuff happen . ”

“Making good stuff happen . ”

Think of a project you worked on that failed . What did you learn and how did you learn it? List the mistakes you made and what you can do differently next time to prevent them from happening again . The process of writing about it will force you to think more carefully and gain more insight


We believe that being on time isn’t about targeting a specific moment but instead is about being within a range of moments . And for some that range is wider than for others .

team rather than within, because they are used to help close a deal or comply with a customer’s timeline .

calculations can be made and assumptions examined . This is true even for small teams or for individuals working alone . There is psychological power in a schedule because it publicizes the commitments being made . It is not as easy to forget or ignore something when it’s posted on a whiteboard in the hallway, reminding the team of what needs to be done .

forcing function

In all cases, methodologies need to be adjusted and adapted to fit the specifics of a team and a project, which is only possible with knowledge that is deeper than the methodologies themselves .

The worst thing is to blindly follow a set of rules that are clearly not working,

The obsession with methodologies in the workplace is another instance of the high-tech illusion . It stems from the belief that what really matters is the technology . . . . Whatever the technological advantage may be, it may come only at the price of a significant worsening of the team’s sociology .

So, be very careful of how you apply whatever methodology you use: it shouldn’t be something inflicted on the team . [

There is one basic rule for all schedules: the rule of thirds .

one for design, one for implementation, and one for testing .

As the rule goes, for every day you expect to write production code, a day should be spent planning and designing the work, and a day should be planned to test and refine that work ( see Figure 2-1 ) . It’s the simplest thing in the world, and it’s an easy way to examine any existing schedule or to start a new one from scratch . If

there should be well-understood reasons why the project demands an uneven distribution of effort . Imbalances in the rule of thirds

It’s worth considering the simplest case possible: there is no project .

passed out or became ill during this section . Now that it’s over, I promise that this lightweight and simple view of scheduling is almost all you’ll need in order to understand the concepts

Until requirements are understood and high-level design is well underway, a project manager has too little information to make realistic predictions .

schedule errors scale in relation to how early in the project schedule estimation is done

It’s only when the project is in implementation that the range of schedule estimation becomes reasonable,

Schedules demand that attention is paid to them as progress is made, and that adjustments are made as the project moves forward .

So, if everyone on the team can agree that the schedule is a set of probabilities, the problem isn’t in the schedule itself — it’s in how the schedule is used .

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 .

By the simplest definition, good work estimates have a high probability of being accurate, and bad work estimates have a low probability .

The primary difference is in how much time they are given to generate estimates and how disciplined they are in the use of that time ( Chapter 5 and Chapter 6 will discuss this in detail ) .

good estimates is that they only come from credible designs and requirements .

There’s nothing wrong with low-quality estimates, provided no one is confusing them with high-quality ones .

( the canonical need for this is a programmer who gives high estimates for things she doesn’t like, and low ones for things she does ) .

Estimates depend on the programmer’s understanding of the project goals .

Estimates should be based on previous performance . It’s a good habit for programmers to track their estimates over projects . It should be part of their discussions with their manager, who should be interested in understanding who on their team

Specification or design quality should be to whatever point engineering needs to make good estimates . This is a negotiation between project management and programmers . The

the real schedule risks are the things not written down .

Here’s my pet list of questions that have helped me to catch potential schedule problems early on .

The more change that is expected, the shorter the milestones should be . Small milestones set the team up for easier mid-game

Good design process isn’t taught in many computer science programs, despite how essential it is to thinking about and approaching engineering projects . See Chapter 5 and Chapter 6 for more on this topic .

If you know that Sally has the most complex component, deal with those challenges up front in the schedule . The bigger the risk, the more time you’ll want on your side in dealing with it . If you don’t address risks until later on in the schedule, you’ll have fewer degrees of freedom in responding to them . The same goes for political, organizational, or resource-related risks .

Spend a day where you start and finish everything exactly on time . Afterward, ask if it was worth the effort . Why or why not?

Chapter 3 .  How to figure out what to do

Few agree on how to plan projects . Often, much time during planning is wasted getting people to agree on how planning should be done . I think people obsess about planning because it’s the point

“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 . ” — Fred Brooks

This is odd because none of these perspectives — business, technology, customer — can ever exist without the others . More so, I’m convinced that success in project planning occurs at the intersections in these different points of view . Any manager who can see those intersections has a large advantage over those who

Plans act as a forcing function against all kinds of stupidity because they demand that important issues be resolved while there is time to consider other options .

involves answering two questions . Answering the first question, “What do we need to do?” is generally called requirements gathering . Answering the second question, “How will we do it?” is called designing or specifying ( see Figure 3-1 ) . A requirement is a carefully written description

To communicate requirements, someone has to write them down .

which may involve modifying/improving the requirements . Specs are complete when they provide a workable plan that engineering can use to fulfill requirements ( how

( WBS ) . While a specification details the work to be done, a WBS defines how a team of engineers will go about doing it . What work will be done first? Who will do it? What are all of the individual pieces of

competitors . It also gives you stronger arguments for any decision you choose to make . Instead of only claiming that a specific design will be easier to build, you can also say why marketing will find more opportunities to sell that design ( provided, of course, that you’re not just making up these claims ) . Sometimes, this will require you to make sacrifices . When you’re looking for the best solutions, they won’t always correspond to what you’re good at doing, or which ideas you personally prefer . But if you’re able to make those sacrifices, you gain the conviction and sincerity required to get others to do the same . You can then call others on favoring pet ideas over what’s best for the project . People will get behind decisions they don’t completely agree with if they see that an open mind, working in the interests of the project, is at work making those decisions .

simplest way to frame planning work is to focus on questions that the planning work should answer . They should be pulled from the three perspectives and rolled together into a single

for proper investigation, ask these questions anyway .

Even though in the last decade much progress has been made in refining methods for researching and understanding customers, most of it has not penetrated through to management- or engineering-centric organizations .

It’s still uncommon for project teams to have an expert in customer research, interface design, or usability available to decision makers .

One challenge in leading teams is keeping people focused on the same goals for long periods of time . All leaders fear that decisions they make won’t be remembered .

visions . However, a vision document is the only way to simultaneously address many of them . Even if working alone ( solo-superman ) , writing down an informal vision document ( e . g . , a list of goals ) for the week, month, and year goes a long way toward concluding those periods of time with something to be proud of . Once things are written down, it’s easier to hold people accountable for them, even if you’re only being accountable to yourself .

Many of the worst vision documents I’ve seen were generated by committees . Small

Visions earned their name for a reason: they are supposed to appeal to our capacity to imagine and visualize a specific kind of outcome . By looking at a picture,

source . It follows then that on projects, it’s individuals — and not processes, methodologies, or committees — who come up with ideas and find ways to use them .

Recognize that persistence contributes to creativity .

the diagram I was looking at, and understood immediately . He said, “Hey, feel the love ! ”, which became our sarcastic rallying cry for the rest of the project .

But until you take that step forward and make a decision ( “Let’s run with design B ! ” ) , you won’t see all of the problems and issues .

If you plan correctly, you will be wrong many times during the design process, but through doing so, you will dramatically improve your chances of success .

But many experienced people I know have fallen into the trap of believing there is only one way to do specifications

ensure that the right thing gets built, provide a schedule milestone that concludes a planning phase of a project, and enable deep review and feedback from different individuals on the course the project will take .

There are four basic kinds of information that end up in specifications, and the easiest way to discuss them is to assume they end up in four different documents . But how these things get divided up isn’t important ( although some people get religious about it ) . What

requirements, feature, technical, and work items . Like many

The creation of a specification should, as much as possible, be focused on expressing an existing plan or set of decisions

When they sit down to write the specification, they must, for the moment, stop exploring and creating and focus on expressing and explaining . Or, at least they must plan to come back and heavily

it’s important to remember that the way that we figured something out is not always the best way to explain it to someone else .

feature and technical specifications into one document, most of the time they need to be clearly separated sections .

assume she needs them at the same time or on the same page . Often, it’s easier to write and read at a single level of thought, and deal with the story one level at a time, than it is to combine them together . Good specifications often describe the design in layers: first, what the customer experiences described in customer language; second, a high-level overview of basic objects and architecture; and third, coverage of complex and detailed engineering design issues .

I learned that the best teachers knew when to skip over nonessential, although still important, things and how to return back to them when the student ( or reader ) was ready for them .

More often, complexity is a cop-out that hides poor writing or mediocre thinking .

it . In the worst possible case, it would take someone more time to comprehend the specification than it would for her to design the thing herself .

Maintain platonic relationships with all tools . Usually,

Once she gets it, ask her if there’s a better way you could have explained it in the spec .

approach . As the spec author, remember that good feedback comes more easily if you ask for it than if you wait for it .

acknowledged . Note Face to face is the best way to tell people you appreciate their work . Don’t depend on an email to the entire team to mean much to anyone . Go door-to-door or call them on the phone . A short conversation carries more emotional weight than any email .

Why isn’t a simpler design better? Do we really need this much complexity or functionality? What evidence do we have or what sound argument can be made not to make this simpler?

Instead, they conceded that they often work on intuition, reasonable assumption, and a quick projection of the immediate issue against the larger goals of the project .

It’s the ability to make effective decisions that explains how some people can manage five times as much work ( or people ) as others: they instinctively divide work into meaningful pieces, find the decisions and actions that have the most leverage, and invest their

They are teaching methods people seldom use . ” Klein goes on to explain the many different ways that skilled airline pilots, firefighters, and trauma nurses make decisions, and how rare it is that formalized methods found in textbooks are used to get things done .

experience, intuition, training, and each other .

Sources of Power: How People Make Decisions,

comparative evaluation requires seeking alternatives before deciding .

Klein describes these situations as being in the zone of indifference because the decision maker is indifferent to major aspects of the outcome as long as a basic criterion

“There is no such thing as a non-emotional moment . ”

Comparative evaluation can happen only if you’ve clarified the problem or issue to be decided . You also need a sense for desirable outcomes ( ship sooner, improve quality, make the VP happy, etc . ) .

Reflection is highly underrated as a decision-making tool . To reflect means to step back and allow all of the information you’ve been working with to sink

You will always find more people willing to criticize and ridicule you for your decisions than people willing to take on the responsibility and pressure to make the decision themselves .

Instead, the problem has become the quality and effectiveness of communication .

Second, communication isn’t enough for complex work: there need to be effective relationships between the people who are working together . Unlike

found that the more I demanded things from people ( “You need to code it this way, OK?” ) , the lower the probability was that I’d get their best work .

I learned dialogs are better than monologs .

“Good communication centers around highly developed individual awareness and differentiation . A good communicator is aware of both internal processes in themselves, and external processes in others . ” — John Bradshaw

Good communicators habitually clarify assumptions

There is no law in the universe claiming others will understand what you’re saying simply because you understand it yourself .

programmers, testers, marketers, clients, or even executives . Sit down with one person you work with and make three lists on the whiteboard . The first list is things you are primarily responsible for . The second list

Something I’ve seen in weaker managers and leaders is the over-reliance on one approach or method to try to get the best work out of people .

Next time you are in an argument with a friend, significant other, or coworker, think about the five-step model of communication every time you open your mouth .

real leadership is about very simple, practical things .

The worst thing in the world, especially during a crisis, is for a manager or leader to reprimand someone while the issue is still unresolved .

recommend the essay “Self-Reliance” by Ralph Waldo Emerson . It’s available in most editions of his collected works, or it can be found online

Priorities make things happen

Much of my time as a PM was spent making ordered lists . An ordered list is just a column of things, put in order of importance . I’m convinced that despite all the knowledge I was expected to have, in total, all I really did was make ordered lists . I collected things that had to be done — requirements, features,

No tough choices means no progress .

Clarity is how you make things happen on projects .

Knowing this, I encouraged programmers to seek me out if they ever faced a decision where

“How do you know what you know?”

Check your sanity For project managers, the most effective way to fly in front of the plane is having a daily sanity check . Programmers use the term sanity checking to ensure that certain important things are true in their code ( in C terminology, think assert ( ) ) . This is a very good idea because assumptions are very dangerous

My approach to this was as follows: I’d lock into my schedule a half-hour weekly meeting with myself ( if I don’t protect my time, who will? ) . I’d close my door, put on some tunes, and run through my question list . Often it only took a few minutes . I’d then be able to reprioritize my day, or my team, accordingly . On some teams, I’ve pushed to make this kind of questioning part of the team culture, and I did smaller versions of this type of questioning and answering during team meetings .

Don’t hesitate to get help from peers or supervisors . This may be the only way to recover and get back out in front . Use their help in prioritizing your time and the team’s time, picking up some of your work, or just to listen to you blow off steam . Take someone’s

Web Project Management: Delivering Successful Commercial Web Sites ( Morgan Kaufmann, 2001 ) , author Ashley Friedlein calls this process briefing the team,

“No battle was ever won according to plan, but no battle was ever won without

The trick in using plans where targets are expected to move is to never allow long periods of time to go by without updating the plan .

The crunch time for designers, planners, PMs, testers, and programmers often occurs at different times of the project . If the work is distributed properly, the entire team is never equally crunched,

remaining space makes the approach unstable . Projects, much like airplanes, don’t control very well when their downward velocity is high . There are too many things that

All things being equal, people will tend to avoid doing things they don’t want