Section 2.1. Understand the Project Needs

2.1. Understand the Project Needs

When a stakeholder does not feel that his needs are being met, he usually puts pressure on the project manager to provide an early version of the software, so that he can personally verify that the team really understands why the software is being built. This is a big source of communication failure between the people who need the software and the team members who are building it. When the stakeholder asks for an early version or a prototype of the software, he is usually asking for evidence that his needs are understood and being addressed. When programmers hear this request, however, they interpret it to mean that the person is interested in the details of what they are doing, and that he wants to be given a tour of the solution as it is being developed.

This may sound funny to some seasoned software engineers. Such a basic lack of communication couldn't really be that widespread...right? But most software professionals have had to sit through uncomfortable meetings where a designer or programmer gives a demo or walkthrough of all of the great work he did, only to be surprised that nobody seems to care.

The reason nontechnical people seem so bored in demos and walkthroughs is because they came to see confirmation that the technology team understands their needs. Instead, they got a lecture in software design, which they did not want. This situation can be frustrating for everyone involved: the software engineers feel unappreciated and condescended to, while the stakeholders feel like their needs are not being taken seriously.

A project that starts out like this is likely to experience scope creep, delays, and even outright failure. What's worse, nobody in the organization will really even understand why the project had so many problems. All they will see is a team that built software that didn't work properly and had to be repaired or even rewritten. This is a very bad situation for a software engineering team to end up in. Even when a team is technically proficient and capable of delivering high-quality, well-written software, when faced with a problematic project, most managers will intuitively feel that the team is incapable of delivering software without major quality problems.

What usually stalls a project is a lack of good project management. To prevent problems, the project manager must identify the people who are making decisions that affect the project and understand why they need the software built. By talking to them and writing down their needs, the project manager can set the project on its proper courseand give the stakeholders the feeling from the very beginning that the team is taking their needs seriously.

2.1.1. Drive the Scope of the Project

When the project begins, the project manager has a unique role to play. The start of the project is the time when the scope of the project is defined; only the project manager is equipped to make sure that it's defined properly. Everyone else has a role to play later on: users and stakeholders will provide expertise, requirements analysts will write specifications, programmers will build the code, etc. Everyone involved in the project has some input into the scope, but only the project manager is solely dedicated to it.

Defining the scope is the most productive thing a project manager can do to get the project underway. It is usually counterproductive to do any other project activity before everybody agrees on the scope, because that activity could fall outside of the scope without anyone realizing it. For example, many programmers will immediately begin coding proof-of-concept prototypes before even talking to the users or stakeholders; many stakeholders will encourage this because they intuitively feel that they cannot make decisions without seeing something in front of them. But building a working model is a very time-consuming way to figure out that a feature is not needed. If time is a concern, this is definitely not an efficient way to build software.

By focusing on discussing the scope and writing a vision and scope document, the project manager can ensure that the team starts out moving in the right direction. This should not be hardwhen the project begins, everyone is highly suggestible. Nobody is really in her area of expertise yet: the code is not ready to be built, requirements are not known well enough to be gathered, and designs and test plans cannot even be approached yet.

Instead, there is a great deal of knowledge floating around in peoples' heads. To make sure that knowledge is captured, there must be a single person responsible for gathering it. This is the main role for the project manager at the start of the project. Once he starts talking to individual people about what they expect to see in the project and writing down their thoughts, the scope will start to coalesce and people will start feeling comfortable with the direction in which it is going. This can happen very quickly once the project manager starts asking questions and writing down the answers.

This is why the project manager is the driving force at the start of the project. It may not always feel like it, but the most important project decisions are made at the project's outset. This is when the broad strokes are laid down, when the major features of the software are defined. If there is a misunderstanding at this point, the team can be sent down an entirely wrong path, which can cause them to lose all of their momentum.

When a project team is first assembled, there is almost always a sense of anticipation and excitement among the project team and the stakeholders. The project manager can take advantage of this energy to drive the project in the right direction.

2.1.2. Talk to the Main Stakeholder

The project manager's first task in any software project is to talk to the main stakeholder . Unfortunately, it's not always immediately obvious who that stakeholder is. The project manager should find the person who will be most impacted by the project, either because he plans on using it or because he is somehow responsible for it being developed. In other words, the project manager needs to find the person who will be in trouble if the software is not developed. (There are often several people who are in this situation. The project manager should talk to each one, starting with the person who he feels will provide the most useful information.)

When a project first starts, a project manager's job is not unlike that of a tailor fitting someone for a custom suit or dress. The tailor's customers will pay a premium for tailored clothes, rather than paying less for an outfit off the rack. But this customization also means that they will need to spend time with the tailor choosing the patterns, going through fabric swatches, taking measurements, and giving some of the precise instructions necessary to customize the clothing. The customer does not see this as a chore, but rather as a perk. By giving exact specifications, the customer can get exactly what he wants. The project manager should try to form the same sort of relationship with each stakeholder that the tailor does with his customers. He can do this by working to understand exactly what it is that the stakeholder will need from the software, and then by helping the project team to deliver software that is tailored to those needs.

Unfortunately for most project managers, the typical relationship with the stakeholder is more like the relationship between a car mechanic and his customer. The customer does not see that the mechanic is using specialized skills to fix a potentially difficult problem. He just can't use his car until the mechanic says it's fixed. He wants the fix to be as fast and cheap as possible, and he doesn't fully understand why it costs so much. What's more, he's always a little suspicious that the mechanic is doing more work than necessary or ordering a part that's too expensive. The customer never knows what's wrong until the mechanic examines the car, and the cost is always an unpleasant surprise. As far as the customer is concerned, the mechanic is simply removing an annoyance, and the customer resents having to pay any money at all for it. This is exactly how many stakeholders think about their software projects and the teams that build them.

For this reason, it's important for the project manager to take responsibility for the delivery of the project from its very beginning. Each stakeholder should feel like the project manager is his main point of contact for any problem or issue with the project. He should feel that the project manager understands his needs, and that he will work to make sure that those needs are addressed in the software. He should be comfortable going to the project manager with any problems or changes at any point during the project's duration.

This sort of goodwill from a stakeholder can often be established in a single conversation or an initial meeting at the beginning of the project. The project manager can do this by blocking out time to meet with the stakeholder, leading him through a conversation about his specific needs, and then showing that he really understood those needs. The way the project manager shows the stakeholder that his needs are understood is by writing a vision and scope document , and then having the stakeholder review it.

2.1.3. Write the Vision and Scope Document

The vision and scope document is one of the most important tools that a project manager has; it is also one of the easiest to implement. A good vision and scope document will help a project avoid some of the costliest problems that a project can face. By writing the document and circulating it among everyone involved in the project, the project manager can ensure that each of the stakeholders and engineers shares a common understanding of the needs being addressedand that the software must address them.

Some of the most common (and expensive) problems that a project can experience are caused by miscommunication about the basic goals of the project and about the scope of the work to be done. (The scope of a project usually refers to the features that will be developed and the work that will be done to implement those features. It often also includes an understanding of the features that will be excluded from the project.) By controlling the scope, the project manager can make sure that all of the software engineers' activities are directed toward building software that will fulfill the needs of the stakeholders.

The "vision" part of the vision and scope document refers to a description of the goal of the software. All software is built to fulfill needs of certain users and stakeholders. The project manager must identify those needs and write down a vision statement (a general statement describing how those needs will be filled).

Many software engineers will recognize the sinking, pit-of-the-stomach feeling when, upon seeing the software for the first time, a stakeholder or customer says, "But I needed the software to do this other thing, and I don't see that anywhere." The vision and scope document helps project managers avoid that problem by catching misunderstandings early on in the project, before they have a chance to influence the code and send the project down the wrong path.

When a project is initiated, the project manager should take the lead, talking to the stakeholders and creating a vision and scope document before the first line of code has been written. However, sometimes project managers must take over projects on which the programming has already been started. This is never an easy situationsenior managers don't usually change project managers unless the project is already in trouble. But even when a project manager has to take over a project that has already been started, it's still a good idea to go back to the stakeholders and build a new vision and scope document. This is the project manager's best chance at catching scope problems as early as possible. If the project has started to go off track, the best way to repair the damage is to assess the current needs of the stakeholders, and then to create a plan to change the software in order to meet those needs.

Table 2-1 shows a typical outline for a vision and scope document. When talking to each stakeholder, the project manager should direct the conversation so that all of the topics in the vision and scope document are discussed. Typically, stakeholders will be happy to talk about all of this. They know their own needs very well, they understand who will be using the software, and they generally have many opinions about what features should go into it. The project manager should take lots of notes during this conversationenough so that writing the vision and scope document is mostly a matter of transcribing those notes. (Stakeholders will often appreciate lots of note-taking, because it shows that the project manager is listening to them and taking what they say seriously.)

1. Problem Statement

   1. Project background

   2. Stakeholders

   3. Users

   4. Risks

   5. Assumptions

2. Vision of the Solution

   1. Vision statement

   2. List of features

   3. Scope of phased release (optional)

   4. Features that will not be developed

The outline itself provides a good guide for the discussion with each stakeholder. It can be used as an agenda for the meetings that the project manager uses to gather the information about stakeholder needs. It's a common mistake for a project manager to approach the writing of a vision and scope document as little more than a bureaucratic exercise. The project manager's goal should be to learn what each user, stakeholder, and project team member thinks about the software in order to develop a single, unified vision and ensure that everyone shares that vision. He should treat the document as a tool to build consensus among the stakeholders and project team members. In other words, the important Part is the discussion of the vision and scope; the document is simply a record of that discussion.

Project background

This section contains a summary of the problem that the project will solve. It should provide a brief history of the problem and an explanation of how the organization justified the decision to build software to address it. This section should cover the reasons why the problem exists, the organization's history with this problem, any previous projects that were undertaken to try to address it, and the way that the decision to begin this project was reached.

Stakeholders

This is a bulleted list of the stakeholders. Each stakeholder may be referred to by name, title, or role ("support group manager," "CTO," "senior manager"). The needs of each stakeholder are described in a few sentences.

Users

This is a bulleted list of the users. As with the stakeholders, each user can either be referred to by name or role ("support rep," "call quality auditor," "home web site user")however, if there are many users, it is usually inefficient to try to name each one. The needs of each user are described.

Risks

This section lists any potential risks to the project. It should be generated by a project team's brainstorming session. It could include external factors that may impact the project, or issues or problems that could potentially cause project delays or raise issues. (The process for assessing and mitigating risk below can be used to generate the risks for this section.)

Assumptions

This is the list of assumptions that the stakeholders, users, or project team have made. Often, these assumptions are generated during a Wideband Delphi estimation session (see Chapter 3). If Wideband Delphi is being used, the rest of the vision and scope document should be ready before the Delphi meeting and used as the basis for estimation. The assumptions generated during the estimation kickoff meeting should then be reviewed, and any nontechnical assumptions should be copied into this section. (Technical assumptionsmeaning assumptions that affect the design and development but not the scope of the projectshould not be included in this document. The estimate results will still contain a record of these assumptions, but they are not useful for this particular audience.)

If Wideband Delphi is not being used to generate the assumptions, the project manager should hold a brainstorming session with the team to come up with a list of assumptions instead. (See Chapter 3 for more information on assumptions.)

Vision statement

The goal of the vision statement is to describe what the project is expected to accomplish. It should explain what the purpose of the project is. This should be a compelling reason, a solid justification for spending time, money, and resources on the project. The best time to write the vision statement is after talking to the stakeholders and users and writing down their needs; by this time, a concrete understanding of the project should be starting to jell.

List of features

This section contains a list of features. A feature is as a cohesive area of the software that fulfills a specific need by providing a set of services or capabilities. Any software packagein fact, any engineered productcan be broken down into features. The project manager can choose the number of features in the vision and scope document by changing the level of detail or granularity of each feature, and by combining multiple features into a single one. Sometimes those features are small ("screw-top cap," "holds one liter of liquid"); sometimes they are big ("four-wheel drive," "seats seven passengers"). It is useful to describe a product in about 10 features in the vision and scope document , because this usually yields a level of complexity that most people reading it are comfortable with. Adding too many features will overwhelm most readers.

Each feature should be listed in a separate paragraph or bullet point. It should be given a name, followed by a description of the functionality that it provides. This description does not need to be detailed; it can simply be a few sentences that give a general explanation of the feature. However, if there is more information that a stakeholder or project team member feels should be included, it is important to include that information. For example, it is sometimes useful to include a use case (see Chapter 6), as long as it is written in such a way that all of the stakeholders can read and understand it.

Scope of phased release (optional)

Sometimes software projects are released in phases: a version of the software with some subset of the features is released first, and a newer, more complete version is released later. This section describes the plan for a phased release, if that approach is to be taken.

This is useful when there is an important deadline for the software, but developing the entire software project by that deadline would be unrealistic. The most common way to compromise on this release date is to divide the features into two or more releases. In that case, this section should identify specifically when those versions will be released, and which features will be included in each version. It's reasonable to divide one feature up between two releases, as long as it is made clear exactly how that will happen.

If a project manager needs to release a project in phases, it is critical that the project team be consulted. Some features are much more difficult to divide than others, and the engineers might see dependencies between features that are not clear to the stakeholders and project manager. After the phased release plan is written down and agreed upon, the project team should always be asked to re-estimate the effort and a new project plan should be generated (see below). This will ensure that the phased release is feasible and compatible with the organization's priorities.

Features that will not be developed

Features are often left out of a project on purpose. When a feature is explicitly left out of the software, it should be added to this section to tell the reader that a decision was made to exclude it. For example, one way to handle an unrealistic deadline is by removing one or more features from the software, in which case the removed features should be moved into this section. The reason these features should be moved rather than deleted from the document is that otherwise, readers might assume that they were overlooked and bring them up in a review. This is especially important during the review of the document because it allows everyone to agree on the exclusion of the feature (or object to it).

2.1.3.1. Review the vision and scope document

Once the vision and scope document has been written, it should be reviewed by every stakeholder, by the members of the project team, and, ideally, by at least a few people who will actually be using the software (if they are available). Performing this review can be as simple as emailing the document around and asking for comments. The document can also be inspected (see Chapter 5). However the document is reviewed, it is important that the project manager follow up with each individual person and work to understand any issues that the reviewer brings up. The project manager should make sure that everyone agrees that the final document really reflects the needs of the stakeholders and the users, and that if they build the software described in the second half of the document, then all of the needs in the first half will be met. Once the document has been reviewed and everyone agrees that it is complete, the team is unified toward a single goal and the project can be planned.

---

Note: More information on understanding user and stakeholder needs can be found in Managing Software Requirements: A Use Case Approach by Dean Leffingwell and Don Widrig (Addison Wesley, 2003). More information on defining features and creating a vision and scope document can be found in The Art of Project Management by Scott Berkun (O'Reilly, 2005). A more detailed template for a vision and scope document is described in Software Requirements by Karl Wiegers (Microsoft Press, 1999).

---