4HE!RTOF 0ROJECT -ANAGEMENT Ņ|ìÇđĹşŅċŅ0ĹʼnñÇŅ 3 COTT"ERKU N This is the Title of the Book, eMatter Edition Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved. Chapter 3 CHAPTER THREE C HAPTER 3 How to figure out what to do ,ch03.29180 Page 51 Thursday, April 21, 2005 2:38 PM This is the Title of the Book, eMatter Edition Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved. 52 CHAPTER THREE ew people agree on how to plan projects. Often, much of the time spent during planning is getting people to agree on how the planning should be done. I think people obsess about plan- ning because it’s the point of contact for many different roles in any organization. When major decisions are at stake that will affect people for months or years, everyone has the motivation to get involved. There is excitement and new energy but also the fear that if action isn’t taken, opportunities will be lost. This combination makes it all too easy for people to assume that their own view of the world is the most useful. Or worse, that it is the only view of the world worth considering and using in the project-planning process. “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 It’s not surprising then that the planning-related books in the corner of my office disagree heavily with each other. Some focus on business strategy, others on engineering and scheduling processes (the traditional focus of project planning), and a few on understanding and designing for customers. But more distressing than their disagreements is that these books fail to acknowledge that other approaches even exist. 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 can’t. So, this chapter is about approaching the planning process and obtaining a view of planning that has the highest odds of leading to success. First I need to clarify some vocabulary and F ,ch03.29180 Page 52 Thursday, April 21, 2005 2:38 PM This is the Title of the Book, eMatter Edition Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved. HOW TO FIGURE OUT WHAT TO DO 53 concepts that different planning strategies use (it’s dry stuff, but we’ll need it for the fun chapters that follow). When that is out of the way, I’ll define and integrate these three different views, explore the questions good planning processes answer, and discuss how to approach the daily work to make planning happen. The following chapters will go into more detail on specific deliverables, such as vision documents (Chapter 4) and specifications (Chapter 7). Software planning demystified A small, one-man project for an internal web site doesn’t require the same planning process as a 300-person, $10 million project for a fault-tolerant operating system. Generally, the more people and complexity you’re dealing with, the more planning structure you need. However, even simple, one-man projects benefit from plans. They provide an opportunity to review decisions, expose assumptions, and clarify agreements between people and organizations. 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. As Abraham Lincoln said, “If I had six hours to cut down a tree, I’d spend four hours sharpening the axe,” which I take to mean that smart preparation minimizes work. Project planning 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 of a criterion that the work is expected to satisfy. (For example, a requirement for cooking a meal might be to make inexpensive food that is tasty and nutritious.) Good requirements are easy to understand and hard to misinterpret. There may be different ways to design something to fulfill a requirement, but it should be easy to recognize whether the requirement has been met when looking at a finished piece of work. A specification is simply a plan for building something that will satisfy the requirements. ,ch03.29180 Page 53 Thursday, April 21, 2005 2:38 PM This is the Title of the Book, eMatter Edition Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved. 54 CHAPTER THREE These three activities—requirements gathering, designing/ specifying, and implementing—are deep subjects and worthy of their own books (see the Annotated Bibliography). I’ll cover the first two from a project-level perspective in the next few chapters, and implementation will be the focus later on in the book (Chapters 14 and 15). Different types of projects Several criteria change the nature of how requirements and design work are done. I’ll use three simple and diverse project examples to illustrate these criteria: 1 • Solo-superman. In the simplest project, only one person is involved. From writing code to marketing to business plan- ning to making his own lunch, he does everything himself and is his own source of funding. • Small contract team. A firm of 5 or 10 programmers and 1 manager is hired by a client to build a web site or software application. They draft a contract that defines their commit- ments to each other. When the contract ends, the relation- ship ends, unless a new contract/project is started. • Big staff team. A 100-person team employed by a corpora- tion begins work on a new version of something. It might be a product sold to the public (a.k.a. shrink-wrap) or some- thing used internally (internalware). These three project types differ in team size, organizational structure, and authority relationships, and the differences among them establish important distinctions for how they should be managed. So, while your project might not exactly match these examples, they will be useful reference points in the following sections. FIGURE 3-1. An insanely simple but handy view of planning. If you don’t know what you need to do, it’s too early to figure out how to do it. ,ch03.29180 Page 54 Thursday, April 21, 2005 2:38 PM This is the Title of the Book, eMatter Edition Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved. HOW TO FIGURE OUT WHAT TO DO 55 How organizations impact planning With the three project types in mind, we can examine the basic criteria for project planning. At any time in a project, there are basic questions that everyone should know the answers to. You might not always like the answers, but you and your team should know what they are. Most planning frustrations occur when there’s disagreement or ignorance about these issues. • Who has requirements authority? Someone has to define the requirements and get them approved by the necessary par- ties (client or VP). In the solo-superman case, this is easy: superman will have all of the authority he wants. On a con- tract team, there will be a client who wants strong control over the requirements and possibly the design. Lastly, a big staff team may have committees or other divisions in the cor- poration who will need to be served by the work (and whose approval in some way is required). There may be different people with high-level requirements authority (“It will be a sports truck”) and low-level requirements authority (“It will get 20 mpg and have 4-wheel drive”). • Who has design authority? Similar to requirements, some- one has to define the design of the work itself. The design is different from the requirements because there are always many different possible designs to fulfill a set of require- ments. Designs, also like requirements, are often negotiated between two or more parties. One person or team might be responsible for driving the design process and developing ideas (designer), and another team provides guidance and feedback on the first party’s work (VP). Note that because design skill is distributed in the universe independent of political power, people granted design authority might not be people with much design talent. • Who has technical authority? Technical authority is defined by who gets to choose which engineering approaches are used, including programming languages, development tools, and technical architecture. Many of these decisions can impact requirements, design, and budget. The difference between technical decisions and design decisions is subtle: how something behaves and looks often has a lot to do with ,ch03.29180 Page 55 Thursday, April 21, 2005 2:38 PM This is the Title of the Book, eMatter Edition Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved. 56 CHAPTER THREE how it’s constructed. In some organizations, technical author- ity supercedes requirements and design authority. In others, it is subservient to them. In the best organizations, there is a collaborative relationship between all the different kinds of authority. • Who has budget authority? The ability to add or remove resources to a project can be independent from other kinds of authority. For example, in the contract team situation, the team might have the power to define the requirements and design, but they might need to return to the client each time they want more money or time. • How often will requirements and designs be reviewed, and how will adjustments be decided? The answer depends heavily on previous questions. The more parties involved in requirements, design, and budgets, the more effort will need to be spent keeping them in sync during the project. As a rule of thumb: the less authority you have, the more diligent you need to be about reviewing and confirming decisions, as well as leading the way for adjustments. Although I’ve identified different kinds of authority, it’s possible for one person to possess several or all of them. However, most of the time, authority is distributed across team leaders. The more complex the distribution of authority is, the more planning effort you’ll need to be effective. In Chapter 16, I’ll cover how to deal with situations where you need more authority than you have. For now, it’s enough to recognize that planning involves these different kinds of power. 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. If the way you document requirements does all this for you, great. If it doesn’t, then look for a new method with these criteria in mind. ,ch03.29180 Page 56 Thursday, April 21, 2005 2:38 PM This is the Title of the Book, eMatter Edition Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved. HOW TO FIGURE OUT WHAT TO DO 57 For reference purposes, I’ll mention some of the common ways to document requirements and planning information. If nothing else, knowing the common lingo helps translate between the various methods used by different organizations. You’ll find some teams document the requirements informally: “Oh, requirements…just go talk to Fred.” Others have elaborate templates and review procedures that break these documents into insanely small (and possibly overlapping) pieces owned by different people. • Marketing requirements document (MRD). This is the busi- ness or marketing team’s analysis of the world. The goal is to explain what business opportunities exist and how a project can exploit those opportunities. In some organizations, this is a reference document to help decision makers in their think- ing. In other organizations, it is the core of project definition and everything that follows derives strongly from it. MRDs help to define the “what” of a project. • Vision/scope document. A vision document encapsulates all available thinking about what a project might be into a sin- gle composition. If an MRD exists, a vision document should inherit and refer heavily to it. 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 Chapters 5 and 6), which may involve modifying/improving the requirements. Specs are complete when they provide a workable plan that engi- neering can use to fulfill requirements (how much detail they must have is entirely negotiable with engineering). Specifica- tions should inherit heavily in spirit from vision documents. Specifications define the “how” of a project from a design and engineering perspective. ,ch03.29180 Page 57 Thursday, April 21, 2005 2:38 PM This is the Title of the Book, eMatter Edition Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved. 58 CHAPTER THREE • Work breakdown structure (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 work and how can we track them? A WBS can be very sim- ple (a spreadsheet) or very complex (charts and tools), depending on the needs of the project. Chapters 7 and 13 will touch on WBS-type activities. WBS defines the “how” of a project from a team perspective. Approaching plans: the three perspectives You may have noticed how each of the deliverables mentioned earlier represents one of two perspectives on the project: business or engineering. On many projects, these two views compete with each other. This is a fundamental planning mistake. Planning should rarely be a binary, or either/or, experience. Instead, it should be an integration and synthesis of what everyone can contribute. To make this happen, a project manager must recognize that each perspective contributes something unique that cannot be replaced by more of something else (i.e., no amount of marketing strategy will improve engineering proficiency, and vice versa). For good results, everyone involved in project planning must have a basic understanding of each perspective. WARNING The following coverage of planning is industrial strength. If you see questions or situations that don’t apply because of the size of your team or scope of your project, feel free to skim or skip them. I don’t expect that everything I cover here applies to any single project. However, I’m trying to provide value to you for not only this project, but also the next one and the one after that. There are many angles and questions here that will prove useful to you in the long run, even if some of it doesn’t apply to what you’re working on today. ,ch03.29180 Page 58 Thursday, April 21, 2005 2:38 PM This is the Title of the Book, eMatter Edition Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved. HOW TO FIGURE OUT WHAT TO DO 59 The business perspective The business view focuses on things that impact the profit and loss (P&L) accounting of an organization. This includes sales, profit, expenses, competition, and costs. Everyone should understand their P&L: it’s what pays their salaries or their contracts. When engineering teams are unaware of how their business works, many decisions made by management will appear illogical or stupid. Thus, it’s in the interest of whoever’s responsible for business planning to help others understand their reasoning. In the tech sector, people with job titles like business analyst, marketing, business development, product planner, or senior manager represent the business perspective. Some projects have multiple business perspectives. If you work for a firm contracted to build a database server, you have your firm’s business interests to consider, as well as the business interests of the client you are serving (hopefully they are in line with each other). The intersection of these perspectives can get complicated; I’m going to keep it simple here and assume projects are of the big-staff variety. However, it should be easy to extrapolate the following questions to more complex situations. A good business perspective means that the team has answers for the following questions: • What unmet needs or desires do our customers have? • What features or services might we provide that will meet those desires and needs? • On what basis will customers purchase this product or ser- vice? What will motivate them to do so? • What will it cost (people/resources)? Over what time period? • What potential for revenue (or reduced organizational oper- ating costs) does it have? Over what time period? • What won’t we build so that we can build this? • Will it contribute to our long-term business strategy or pro- tect other revenue-generating assets? (Even nonprofits or IT organizations have a business strategy: there are always bills to pay, revenue to obtain, or revenue-generating groups to support.) ,ch03.29180 Page 59 Thursday, April 21, 2005 2:38 PM [...]... What do we think their strategies are, and how might we compete with them? Answering the right questions It can take hours or weeks to answer these questions, depending on the depth and quality of the answers needed, which is defined by the project manager or group leader As a rule of thumb, the more strategic the project is expected to be, the more important the quality of this kind of definition and... yourself about the kinds of people likely to spend lots of time taking surveys Experts at customer research do two things: they choose the method based on the questions the project team needs to answer, and they make use of multiple methods to counteract the limitations and biases of individual approaches Table 3-2 outlines some of the major research methods and their highlevel tradeoffs 76 CHAPTER... are the market time windows that we should target for this project? Those responsible for the business perspective take bold views of the importance of these questions They believe that the answers represent the bottom line for the organization and should strongly influence project decisions However, the business view doesn’t mean that all projects must be slaves to revenue Instead, it evaluates projects... impossible) for changes to propagate back up the planning structure makes a big difference Be as simple and direct as possible The leader sets the tone by starting the conversations, asking the important questions, and making sure the right people are in the room at the right time However, there are three things to keep in mind: • The most important part of the process is the roles that people are expected to... 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 The balance of power If you work in a large organization,... Addison Wesley, 2000), but there are many others Each scenario is a short description of something a customer will be able to do as a result of the project, or the tasks they will no longer have to do because the project automates those tasks for them The idea is to describe these things from the customer or user’s perspective and to avoid any description of how these benefits will be achieved—that comes... Instead, project- planning meetings become battlefields for attacking and defending opinions based on these perspective lines (and not on the true merits of the ideas themselves) Often when I’ve consulted with project teams, the problem I was asked to help with had nothing to do with their ability to plan a project Instead, there was an unresolved, or even unspoken, conflict of opinion about why one department—engineering... factor to balance the view of a project I call this factor the power ratio How is power on the project distributed across people who represent these three views? For example, if engineers outnumber business analysts by 3:1, the engineering view will tend to dominate decisions The power ratio is simply the ratio of the number of people prone to a given view To have a balanced perspective, the ratio should... because there are valid questions about it Instead, the team should try to look past the flaws to find the valuable parts that can be used to influence discussions and give a better perspective on what the reality of the customer’s experience is like No form of data is perfect: there are always biases, caveats, margins of error, and hidden details The project manager has to be able to see past the biases... important than the other Their singular perspectives not only caused the problem but also made it impossible to see the cause of the problem Years ago, I was involved in one of these silly wars myself I was the program manager for web-search features on Internet Explorer 4.0 Two business development people were assigned to us, and they were negotiating deals with the major search engines of the time (Excite, . 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. 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