By Scott Berkun
Book Price: $39.99 USD
£24.99 GBP
PDF Price: $27.99

Cover | Table of Contents

Table of Contents

Chapter 1: A brief history of project management (and why you should care)

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In many organizations, the person leading a project doesn't have the job title project manager. That's OK. Everyone manages projects in their daily work, whether they are working alone or leading a team. For the moment, these distinctions are not important. My intent is to capture what makes projects successful, and how the people who lead successful projects do it. These strategies don't require specific hierarchies, job titles, or methods. So, if you work on a project and have at least some responsibility for its outcome, what follows will apply to you. And should your business card happen to say project manager on it, all the better.

This book is useful in three ways: as a collection of individual topic-focused essays, as a single extended narrative, and as a reference for common situations. Each chapter takes on a different high-level task, provides a basic framework, and offers tactics for successfully completing the task. However, in this opening chapter, I need to take a different approach: there are three broader topics that will make the rest of the book easier to follow, and I will present them now.

The first is a short history of projects and why we should learn from what others have done. The second is some background on the different flavors of project management, including some notes from my experience working at Microsoft. And the third is a look at the underlying challenges involved in project management and how they can be overcome. Although these points will be useful later on, they are not required to understand the following chapters. So, if you find the approach in this first chapter too wide for your liking, feel free to move on to and the core of this book.

Project management, as an idea, goes back a very long way. If you think about all of the things that have been built in the history of civilization, we have thousands of years of project experience to learn from. A dotted line can be drawn from the software developers of today back through time to the builders of the Egyptian pyramids or the architects of the Roman aqueducts. For their respective eras, project managers have played similar roles, applying technology to the relevant problems of the times. Yet today, when most people try to improve how their web and software development projects are managed, it's rare that they pay attention to lessons learned from the past. The timeline we use as the scope for useful knowledge is much closer to present day than it should be.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Using history

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Project management, as an idea, goes back a very long way. If you think about all of the things that have been built in the history of civilization, we have thousands of years of project experience to learn from. A dotted line can be drawn from the software developers of today back through time to the builders of the Egyptian pyramids or the architects of the Roman aqueducts. For their respective eras, project managers have played similar roles, applying technology to the relevant problems of the times. Yet today, when most people try to improve how their web and software development projects are managed, it's rare that they pay attention to lessons learned from the past. The timeline we use as the scope for useful knowledge is much closer to present day than it should be.

The history of engineering projects reveals that most projects have strong similarities. They have requirements, designs, and constraints. They depend on communication, decision making, and combinations of creative and logical thought. Projects usually involve a schedule, a budget, and a customer. Most importantly, the central task of projects is to combine the works of different people into a singular, coherent whole that will be useful to people or customers. Whether a project is built out of HTML, C++, or cement and steel, there's an undeniable core set of concepts that most projects share.

Curious about better ways to lead web and software development efforts, I've taken a serious interest in that core. I studied other fields to see how they solved the central challenges to their projects. I wondered how projects like the Hubble Space Telescope and the Boeing 777 were designed and constructed. Could I reuse anything from their complex specifications and planning processes? Or when the Chrysler Building was built in New York City and the Parthenon in Athens, did the project leaders plan and estimate their construction in the same way my programmers did? What were the interesting differences, and what can be gained by examining those differences?

How about newspaper editors, who organize and plan for daily production of information? They were doing multimedia (pictures and words) long before the first dreams of web publishing. What about feature film production? The

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Web development, kitchens, and emergency rooms

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One problem with history is that it's not always relatable. It can be hard to apply lessons across decades and sustain empathy for things that seem so different from how work is done today. One alternative is to make comparisons with interesting kinds of modern projects. While this doesn't have the gravitas of engineering history, it does allow for first-person experiences and observations. Often, seeing things firsthand is the only way to give people enough information to make connections among diverse ideas.

As an example, I know a web developer who believes that his work is unlike anything else in the history of the universe. He feels that because web development requires him to make complex engineering decisions—designing and coordinating as he goes, verifying changes in a matter of hours or even minutes, and then publishing it all to the world—his project and task management is unlike anything ever seen before. He is proud to rattle off CSS, XHTML, Flash, Ajax, and other technologies he has mastered, claiming that they would have baffled the greatest minds 50 years ago. I'm sure that in your experience, you've met people like him. 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.

I suggested to this developer friend that he wander into the back of his favorite lunch establishment on a busy day. For a variety of reasons, it's interesting to step foot into kitchens (see Anthony Bourdain's excellent book, Kitchen Confidential, Ecco, 2001), but my specific point was about productivity. The first time anyone sees the quick task management and coordination that occur in a busy professional kitchen, he's likely to reconsider how difficult his own job is. Cooks are often juggling frying pans with different orders at different states of completion, and scrambling between multiple sets of burners in opposite corners of the kitchen, while waiters run in and out, delivering news of new adjustments and problems from customers.

All of this happens in small, cramped rooms, well over 90 degrees, with bright fluorescent lights glaring above. And despite how many orders go out every few seconds, new ones come in just as fast. Sometimes orders get sent back, or, much like software projects, require custom and last-minute modifications (table 1 is lactose intolerant; table 2 needs the sauce on the side, etc.). Large, busy kitchens are amazing to watch. As chaotic as they may seem at first, great kitchens run with a level of intensity and precision that blows most development teams away.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The role of project management

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Project management can be a profession, a job, a role, or an activity. Some companies have project managers whose job is to oversee entire 200-person projects. Others use the title for line-level junior managers, each responsible for a small area of a large project. Depending on how an organization is structured, what its culture is, and what the goals of the project are, project management can be an informal role ("it's done by whomever, whenever necessary") or highly defined ("Vincent, Claude, and Raphael are full-time project managers").

In this book, I'll primarily use the phrase project manager, or PM, to refer to whoever is involved in project leadership and management activity. By project management activity I mean leading the team in figuring out what the project is (planning, scheduling, and requirements gathering), shepherding the project through design and development work (communication, decision making, and mid-game strategy), and driving the project through to completion (leadership, crisis management, and end-game strategy).

If this sort of work is structured less formally in your world, just translate project manager or PM to mean "person doing project management tasks, even though it's not her primary job" or "person thinking about the project at large." I've encountered many different ways for these activities to be distributed across teams, and the advice in this book is largely indifferent to them. This book is less about job titles and formalizations, and more about how to get things done and make things happen. But to keep my writing as simple as possible, I'll rely on the phrase project manager, or PM.

Sometimes the absence of a dedicated project manager works fine. Programmers and their bosses maintain schedules and engineering plans (if any), and a business analyst or marketing person does the planning or requirements work. Anything else that might qualify as project management simply gets distributed across the team. Perhaps people on the team have been hired for their interest beyond writing code. They might not mind early planning, user interface design, or business strategy. There can be significant optimizations in working this way. As long as everyone is willing to pay the tax of responsibility for keeping things together, and distributing the burden that a dedicated project manager would carry for the team, there's one less employee that the team needs. Efficiency and simplicity are good things.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Program and project management at Microsoft

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Microsoft had a problem in the late 1980s regarding how to coordinate engineering efforts with the marketing and business side of each division (some might say this is still a problem for Microsoft and many other companies). A wise man named Jabe Blumenthal realized that there could be a special job where an individual would be involved with these two functions, playing a role of both leadership and coordination. He'd be involved in the project from day one of planning, all the way through the last day of testing. It had to be someone who was at least technical enough to work with and earn the respect of programmers, but also someone who had talents and interests for broader participation in how products were made.

For this role to work, he'd have to enjoy spending his days performing tasks as varied as writing specifications, reviewing marketing plans, generating project schedules, leading teams, doing strategic planning, running bug/defect triage, cultivating team morale, and doing anything else that needed to be done that no one else was doing (well). This new role at Microsoft was called program manager. Not everyone on the team would report directly to him, but the program manager would be granted significant authority to lead and drive the project. (In management theory, this is roughly the idea of a matrix organization, where there are two lines of reporting structure for individuals: one based on function and the other based on project. So, an individual programmer or tester might have two reporting relationships—a primary one for her functional role and a secondary, but strong, one for the project she works on.)

Jabe played this role on a product called Multiplan (later to become Microsoft Excel), and it worked. The engineering and development process improved along with the quality of coordination with the business team, and throughout the hallways at Microsoft there was much rejoicing. After many memos and meetings, most teams within the company slowly adopted the role. Say what you will, good or bad, about the resulting products, but the idea makes sense. By defining a role for a line-level generalist who was not a gofer or a lackey, but a leader and a driver, the dynamics of how development teams worked at Microsoft changed forever. This role of program manager was what I did through most of my career at Microsoft, and I worked on product teams that included Internet Explorer, MSN, and Windows. Eventually, I even managed teams of people who played this role.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The balancing act of project management

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

It is hard to find good project managers because they need to maintain a balance of attitudes. In his essay "Pursuing the Perfect Project Manager," 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:

• Ego/no-ego. Because of how much responsibility project managers have, they often derive great personal satisfaction from their work. It's understandable that they'd have a high emotional investment in what they're doing, and for many, this emotional connection is what enables them to maintain the intensity needed to be effective. But at the same time, project managers must avoid placing their own interests ahead of the project. They must be willing to delegate important or fun tasks and share rewards with the entire team. As much as ego can be a fuel, a good project manager has to recognize when his ego is getting in the way.
• Autocrat/delegator. In some situations, the most important things are a clear line of authority and a quick response time. A project manager has to be confident and willful enough to take control and force certain actions onto a team. However, the general goal should be to avoid the need for these extreme situations. A well-managed project should create an environment where work can be delegated and collaborated on effectively.
• Tolerate ambiguity/pursue perfection. The early phases of any project are highly open and fluid experiences where the unknown heavily outweighs the known. As we'll discuss in and , 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. (See the section "" in Chapter 8.)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Pressure and distraction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One fear of those new to project management is that success requires change. New projects are created with the intent to change the state of the world by modifying, building, or destroying something. Maintaining the status quo—unless that's the explicit goal, for some strange reason—is not a successful outcome. The world is changing all the time and if a project is not as good today as it was last year, it means that it's fallen behind because the goals were misguided or the execution of the project failed in some way.

It's hard to ignore the underlying pressure this implies for project managers, but it comes with the territory. Don't just sit there—make it better. There is always a new way to think, a new topic to learn and apply, or a new process that makes work more fun or more effective. Perhaps this is a responsibility more akin to leadership than to management, but the distinction between the two is subtle. No matter how much you try to separate them, managing well requires leadership skills, and leading well requires management skills. Anyone involved in project management will be responsible for some of both, no matter what his job description says.

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.

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 as the gap between the PM and the project grows, the amount of unnecessary attention paid to charts, tables, checklists, and reports increases. It's possible that at some point the PMs begin to believe that the data and the process

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The right kind of involvement

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

All managers—from Fortune 500 executives to coaches of sports teams—are vulnerable to over-involving themselves. They know that they are potential overhead, and compulsive involvement is one convenient (though negative) way to try and compensate for it. This partially explains the endless supply of micromanagers; the easiest move for a weak manager is to abuse her power over her subordinates (and in extreme cases, simultaneously blame the subordinates for being incompetent enough to need so much attention). The insecurities managers have stem from the fact that, in industrial revolution terms, managers are not in the line of production. They don't make things with their hands, and they are not the same kind of asset as those who do.

Managers are not hired to contribute a linear amount of work like a worker or programmer is expected to do. Instead, leaders and managers are hired to amplify the value of everyone around them. The methods for adding this kind of value are different from working on the line. But because many managers are former programmers and were promoted into management from the line, odds are good that they have more confidence and skills at writing code than they do leading and managing people who are writing code.

Like a coach for a baseball team, the presence of a manager is supposed to contribute something different in nature from adding another individual contributor. Sometimes this is done by settling arguments or shielding the team from politics. Other times, it's providing good, high-level plans or finding clever workarounds for unexpected situations. Because these contributions are harder to measure, many PMs struggle with the ambiguity of their role. As managers, they are easy targets for blame and have few places to hide. It takes a combination of conviction, confidence, and awareness to be effective and happy as a leader of a team.

The best way to find the points of leverage is to make use of the difference in psychology gained from being off the line. A PM will, in the course of his duties, naturally spend more time working with different people on the team than others do, thereby gaining more sources of information and a wider perspective of the project. The PM will understand the business view of the project as well as the technical view, and he'll help the team translate between them when necessary. That wider perspective makes it possible to deliver critical nuggets of information to the right people at the right time. Though this power can have broad effects, what follows is a simple story that helps illustrate this point in a comprehensive way.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Summary

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Each chapter in this book will end with a short summary of key points to help you review later:

• Project management is everywhere, and it's been around for a long time.
• If you keep a beginner's mind, you'll have more opportunities to learn.
• Project management can be a job, a role, or an activity (the advice in this book applies well no matter how you define it).
• Program management is Microsoft's strongly defined project management role. It is derived from the idea of a matrix organization.
• Leadership and management require an understanding of, and intuition for, several common paradoxes. These include ego/no-ego, autocracy/delegation, and courage/fear.
• Watch out for pretension and over-involvement in your management activity. The process should support the team, not the other way around.
• If you are a dedicated manager, look for ways to capitalize on your unique perspective of the team and project.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Exercises

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

1. Pick your favorite friend who works in or studies a field other than yours. How does he manage his projects? Is there a special job for the project leader, or is the work of project management distributed across different people?
2. If being a good PM requires a balancing act of attitudes, how can a PM make sure she is not going too far in one direction or another? How can a PM enlist the help of people she works with to keep her in balance?
3. Make up a reason and throw a party. (You survived , isn't that reason enough?) After you've recovered from your hangover, and bailed your friends out of jail, consider the following: how is a party different from a project? Compare the challenges and rewards of being a party organizer to being a project manager on a work-related project. What's different and what's the same?
4. 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 from the experience.
5. Can you think of a kind of work that doesn't involve project management? If so, how do those in that field organize and plan how the work gets done? What limitations does a lack of organization create? What opportunities does it create?
6. Can you create leadership moments, or are they events that happen for reasons out of your control? If you wanted to increase the number of possibilities to demonstrate leadership, what could you do?
7. Imagine a team where people are rewarded exclusively for how well they follow processes and rules, instead of for reaching goals. What would happen to the quality of work? What would the role of project manager be like? What does this say about the potential dangers project managers can create?
8. Middle managers, or people who manage managers, are particularly prone to over-involving themselves, and creating unnecessary processes, because they are in the middle of the organization. How can a smart middle manager avoid the temptation to micromanage and create too many rules?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: The truth about schedules

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

People tend to be late. It might be only a few minutes, or just a couple of times a week, but people are often behind on their daily schedules. (However, because denial is another great skill humans have, I'll understand if you refuse to admit this applies to you.) High school students are late for class, adults are late for meetings at work, and friends arrive 10 minutes late at the bar for drinks. 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. Restaurant hosts are an interesting example. They claim a table will be ready soon, but often we're made to wait much longer than they said it would be. It's these experiences of delayed schedules, being put on hold on the telephone, or waiting in the doctor's office, that have made us cynical about schedules—we have so much experience with life not happening on time.

It shouldn't be a surprise then that so many projects come in late. Most of us arrive at the task of scheduling projects with a poor track record for delivering or receiving things on time. We tend to estimate based on weak assumptions, predict outcomes based on the best possible circumstances, and—given our prior experiences—simultaneously avoid placing confidence in schedules we see or create. Why we do this, how it impacts project schedules, and what can be done to avoid these problems is the subject of this chapter.

But before we can figure out how to make better schedules, we first have to understand what problems schedules solve. If they are so unreliable, why bother with them at all? Schedules serve several different purposes—only some of which are focused on measuring the use of time.

All schedules, whether for planning a party or updating a web site, serve three purposes. The first is to make commitments about when things will be done. The schedule provides a contract between every person involved, confirming what each person is going to deliver over a particular period of time. Generally, when people think about project schedules, it's this first purpose that they're thinking about. Schedules are often focused externally, outside the project team rather than within, because they are used to help close a deal or comply with a customer's timeline. Often, the customer is explicitly paying for the timeline as well as for the service provided (think UPS or FedEx). In order to allow customers or partners to make plans based on a given project, a time has to be agreed upon for when specific things will happen.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Schedules have three purposes

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

All schedules, whether for planning a party or updating a web site, serve three purposes. The first is to make commitments about when things will be done. The schedule provides a contract between every person involved, confirming what each person is going to deliver over a particular period of time. Generally, when people think about project schedules, it's this first purpose that they're thinking about. Schedules are often focused externally, outside the project team rather than within, because they are used to help close a deal or comply with a customer's timeline. Often, the customer is explicitly paying for the timeline as well as for the service provided (think UPS or FedEx). In order to allow customers or partners to make plans based on a given project, a time has to be agreed upon for when specific things will happen.

The second purpose of a schedule is to encourage everyone to see her efforts as part of a whole, and to invest in making her pieces work with the others. Until there is a draft schedule suggesting specific dates and times for when things have to be ready, it's unlikely that connections and dependencies will be noticed. Without a schedule, everyone will focus on her own tasks and not think about how her work will impact others.

It's only when the details are written down, with people's names next to them, that real 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. And specific to PMs: with a draft schedule in place, questions about how realistic certain things are can be raised, and comparisons can be made between what the project is being asked to do and what is even possible.

This psychological shift is called a forcing function. A forcing function is anything that—when put in place—naturally forces a change in perspective, attitude, or behavior. So, schedules are important forcing functions for projects. If used properly by a PM, schedules force everyone to carefully think through the work they need to do. This forcing function is a critical step toward realizing the project's potential. Even if the schedule slips, is doubled, or is halved, the commitments and connections everyone has made as a result of drafting the schedule can be maintained. So, this second purpose of a schedule can be achieved and can be entirely worthwhile even if the schedule itself turns out to be seriously inaccurate. For example, if the project comes in very late, the existence of a schedule will still enable the project to be completed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Silver bullets and methodologies

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are many different systems for how to plan and manage the development of software. These systems are often called methodologies, which means a body of practices aimed at achieving a certain kind of result. Common software methods include the waterfall model, spiral model, Rapid Applications development, Extreme Programming, and Feature-driven development. All of these methods attempt to solve similar organization and project management problems. They each have strengths and weaknesses, and it takes knowledge and experience to decide which one is right for what kind of project.

But my goal in this chapter, and in this book, isn't to compare different methodologies. Instead, I believe there are concepts that underlie them all that need to be mastered in order to succeed with any methodology. 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. So, if you can follow the underlying ideas in this chapter and book, your odds of being effective will increase, independent of which methodology you're using. I'll explain aspects of certain methods as needed to clarify points, but you'll have to look elsewhere if you're methodology shopping.

Although methods for software development are important, they are not silver bullets. The worst thing is to blindly follow a set of rules that are clearly not working, simply because they show up in some famous book or are promoted by a well-respected guru. Often, obsessing over the process is a warning sign of leadership trouble: it can be an attempt to offload the natural challenges and responsibilities managers face in bureaucratic procedures that cloud the need for real leadership action. Perhaps more devastating to a team is that methodology fixation can signal what is truly important to the organization. As Tom DeMarco writes in Peopleware (Dorset House, 1999):

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What schedules look like

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There is one basic rule for all schedules: the rule of thirds. It's a rough estimation and back-of-the-envelope thing, but it's the simplest way to understand schedules. If you are experienced with scheduling, prepare to cringe—I'm oversimplifying the entire process. I'm doing this to provide the simplest footing to explain what tends to go wrong, why it happens, and what can be done about it.

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. Depending on the methodologies you use, these kinds of work will be called different things, but all methodologies have time dedicated to these three activities. On any given day, or any given hour, you're figuring out what should be done (designing), actually doing it (implementing production code), or verifying, analyzing, and refining what's been done (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 ). 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 the total amount of time isn't roughly divided into the three kinds of work, there should be well-understood reasons why the project demands an uneven distribution of effort. Imbalances in the rule of thirds—say, 20% more time dedicated to testing than implementation—are fine as long as they are deliberate.

Figure : The plain-vanilla rule-of-thirds project schedule.

Consider a hypothetical web development project: if you're given six weeks to launch it, the first step should be to divide that time roughly into thirds, and, using those divisions, make calculations about when work can be completed. If this doesn't provide enough time to do the work expected at a high level, something is fundamentally wrong. Either the schedule needs to change, or the amount of work expected to be completed needs to be reduced (or any expectations of quality need to be lowered). Trimming from the testing time will only increase the odds that the time spent actually writing code will be misguided or will result in code that is harder to manage and maintain. 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Why schedules fail

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Project schedules are the easy scapegoats for everything that can possibly go wrong. If someone fudges an estimate, misses a requirement, or gets hit by a bus, it's the schedule (and the person responsible for it) that catches the blame. If the nation's power supply were to go out for 10 days, or the team's best programmers were to catch the plague, invariably someone would say, "See, I told you the schedule would slip" and wag her finger in the schedule master's face. It's completely unfair, but it happens all the time. As much as people loathe schedules, they still hold them up to an unachievable standard. Even the best schedulers in the world, with the smartest minds and best tools at their disposal, are still attempting to predict the future—something our species rarely does well.

But if a team starts a project fully aware of the likely reasons schedules fall apart and takes some action to minimize those risks, the schedule can become a more useful and accurate tool in the development process.

If a schedule is created during initial planning, hundreds of decisions that may impact the schedule have yet to be made. There will be issues and challenges, which no one can foresee, and there is no way an early speculative plan can possibly account for them. Until requirements are understood and high-level design is well underway, a project manager has too little information to make realistic predictions. Yet, often a rough-cut schedule is created with made-up numbers and wild speculations, and this straw man is handed to the team under the guise of a believable project plan. Often, people fall victim to the precision versus accuracy trap: an impressive-looking schedule with specific dates and times (precision) isn't necessarily close to reflecting reality (accuracy). Precision is easy, but accuracy is very difficult.

However, it is true that all projects and schedules have to start somewhere. A shot in the dark can be used to energize a team and put some boundaries in place. It can begin a process of investigation to flesh out schedules and raise and answer important questions. But if an unverified and unexamined sweeping speculation is used as the basis for a schedule—without further refinement—great risks await. There is strong evidence that it is difficult for anyone to estimate the amount of time required early on in a project.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What must happen for schedules to work

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that we understand why schedules are so difficult to maintain, I can offer advice on how to minimize the risks and maximize the benefits of any project schedule. These approaches and behaviors cut across traditional roles or backgrounds, which I think reflects the true nature of scheduling. Because the schedule represents the totality of the project, the only way to use schedules effectively is to understand something about all of the things that must happen in order to make the project successful. It's an interdisciplinary task, not just an engineering or management activity.

• Milestone length should match project volatility. The more change that is expected, the shorter the milestones should be. Small milestones set the team up for easier mid-game adjustments. This gives management shorter intervals between reviews, and it reduces the risks of making changes. The team can be prepped to expect change at milestone crossovers, so they will expect change instead of resist it.
• Be optimistic in the vision and skeptical in the schedule. A major psychological challenge for scheduling is to make use of proper skepticism, without deflating the passion and motivation of the team. Unlike the creation of a vision document, where optimism about the future must reign, a schedule has to come from the opposite perspective. The numbers that are written down to estimate how long things should take require a brutal and honest respect for Murphy's Law ("What can go wrong will go wrong"). Schedules should not reflect what might happen under optimal conditions. Instead, a good schedule declares what will happen—despite several important things not going as expected. It's important to have the test/QA team involved in scheduling because they lend a naturally skeptical and critical eye to engineering work.
• Bet on design. The process of design is the best insurance against ignorance and unexpected challenges. Better design practices are the only way to improve the ride of thetion and other phases. Design skills are not the same as implementation skills, and the strongest or fastest coder won't necessarily be the best design thinker or problem solver. Good design process isn't taught in many computer science programs, despite how essential it is to thinking about and approaching engineering projects. See and for more on this topic.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Summary

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

• Schedules serve three functions: allowing for commitments to be made, encouraging everyone to see her work as a contribution to a whole, and enabling the tracking of progress. Even when schedules slip, they still have value.
• Big schedules should be divided into small schedules to minimize risks and increase the frequency of adjustments.
• All estimates are probabilities. Because schedules are a collection of estimates, they are also probabilities. This works against schedule accuracy because probabilities accumulate (80%×80% = 64%).
• The earlier that estimates are made, the less accurate they are. However, rough estimates are the only way to provide a starting point for better ones.
• Schedules should be made with skepticism, not optimism. Invest in design to shed light on assumptions and generate reliable confidence.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Exercises

Content preview·

Return to Making Things Happen