Chapter 3. Scoping the System: Vision Document and Business Case

We are about to begin the task of building a software system by employing use case modeling. One of our first tasks will be to ask the users what they want in the system, and then ask our software developers to provide an estimate on it. Chances are that this task will be no small feat.

Before we embark on the task, we should ask some important questions. What is the system that we intend to build? Do all of our stakeholders, especially those who will fund and use the product, agree on this? If so, how much is it going to cost? Is it worth building?

Answering these questions is the purpose of two artifacts: the vision document and the business case. These two artifacts are complementary. The vision document qualifies the problem to be solved and the business case justifies the amount of effort involved in its solution. Therefore, the vision document must be developed first so that an assessment of the work involved may be completed in the business case.

Describing the Problem: Vision Document

In the early stages of software development, an idea for a software system is conceptualized. This conceptualization may come from the development of a business process that identifies an opportunity to computer-assist the workers involved in the process or perhaps an opportunity to completely automate several steps. It may have just been somebody’s good idea.

Regardless of the origin of the need to develop a software system, the idea must be captured and elaborated on. This is the purpose of a vision document. This document has been called many other names: a problem statement [IBM 1997], statement of work [Donaldson 1997], system concept, and concept of operation (see the Interesting Issue box on page 37). We call it the vision document to be consistent with the terminology of the Unified Process [Leffingwell 2000]. The document contains an initial “cut” at the problem the software system is intended to solve.

Often the understanding between those who dwell in the problem domain and those who live in the solution domain is imperfect. This is precisely because the groups approach the problem from two different viewpoints. The vision document begins the process of understanding and communicating the needs of the problem formulator to the solution provider. The ensuing activities will investigate and communicate the costs back to the problem formulator. A business case will measure the costs against the benefits of solving the problem. The project will continue if the benefits outweigh the costs.

Tackling the Dark Side

Is creating a vision document as easy as answering the question “What is the problem?” Certainly the world is full of problems just waiting for us to solve. Most IT and software development organizations are not lacking in this area. However, the knowledge that we must next create a business case to show the value of the project to the organization prevents us from selecting just any random problem. We know that finding the project that will truly solve a business problem or make a software product competitive is not easy. So how do we cut through all the noise to find the one project that everyone can agree on and that makes existing customers happier or brings in new customers?

Sorting the “good” projects out from the “bad” projects is usually done politically, not technically [Andriole 1998]. Different groups have their agendas and therefore ideas on what a “good” project should be. Executives generally want the most value for the dollar. Project managers want a project whose expectations align with reality. Software developers want to use the latest software technologies and techniques. And the users? Has anyone asked them what they want? With all these sometimes contradictory viewpoints and the difficulty involved in conceptualization (described in the Introduction), is it any wonder that this task is so arduous?

Several questions should be answered in the vision document. Some of these questions provide a political litmus test [Andriole 1998] by which the initial value of projects can be judged. Others are information required as a basis for future engineering activities.

1. What is the problem we are attempting to solve?

The answer provides a product overview. Additional information might include the version number and some of the features that distinguish this new product or version.

2. Who are the customers of this solution? Who are the other major stakeholders?

Identifying potential users is a very important part of understanding the value of a project.

3. “What is the project’s purpose? If completed, what impact will the new or enhanced system have on organizational performance? On profitability? On product development? On customer retention and customer service?” [Andriole 1998]

The logical next question asks what value the system brings to its users, to the organization, and to its creators. The intangible benefits, such as the developers becoming proficient in a new technology, should be listed along with the tangible ones.

This value of the benefits does not have to be quantified. That is done in the business case. However, the answers to the questions will be used for the quantification.

4. Where would this solution be positioned relative to our business and our other products? What are alternatives or competing products? [Leffingwell 2000]

Understanding how a solution affects the business is critical to building a business case. Since the vision document is an input to the business case, a good description of the business impact in the vision document can often be the difference between a “go” and a “no go.” This is the part of the vision document where a detailed business use case model and activity diagrams from the business use cases play a key role. These documents provide context for the role of the project in a “total” solution.

5. What are the differentiating functional and nonfunctional requirements? What are their priorities? What are the risks? What other systems will this system interact with?

The answer to these questions starts to define the system boundary and should provide the minimum information necessary to cover the needs of all of the stakeholders. More detailed information will be discerned in the various use case models developed later in the project. Thus, the system boundary is refined as future activities such as use case modeling and system interface specifications (see Chapter 4) are performed.

6. What future directions might the product have to take to keep up with trends in the domain? What new technologies might need to be integrated with the project in the future?

Keeping an eye to the future is always prudent when formulating a project. Understanding where change can turn into risk means thoroughly understanding why the system is necessary. The project will take some time to materialize. We must understand that the business or domain will probably change in the time it takes to produce the system.

The many techniques with which to gather the information necessary to answer the questions are beyond the scope of this book. The reader is referred to Gause [1989].

The first thing to do when creating a vision document is to name the project. This may be more difficult than it sounds. The final act involved in creating the vision document is to ensure that it is agreed on (and sometimes signed) by the major stakeholders. This gathers the commitment necessary to see the project through as it passes through the sometimes smooth, sometimes troubled waters ahead.

Just as the vision document has many names, it also has many forms. Most organizations have a form in which they expect information to appear. They may also have requirements for the information they expect. Some of the preceding questions may be part of this required information, others may not. If any of the preceding questions are missing from the version of the document you are dealing with, you might want to ask these questions of yourself before you commit the resources, agree to project manage, sign off as a user of, or develop a new project. If the organization does not have a vision document template, we recommend the one found in Leffingwell [2000].

Determining Project Feasibility: Business Case

The purpose of a business case is to justify the undertaking of a project. The need to develop a business case varies from organization to organization. Most organizations like to know that they are getting their best return on any investment—and software development is an investment. Therefore, it makes sense to see either a tangible or an intangible return on this investment. The job of the business case is to specify the expected return as accurately as possible.

There are many forms of a business case. Most people think of it as a lengthy financial document whose required creation is a bureaucratic block to creativity. In organizations where this a true statement, it is safe to say that most software projects are started and finished without such a document. However, these organizations may be operating under a business case without knowing it.

Suppose you understood the benefits of (or the amount of revenue you would receive from) a software system. You might fix your costs by setting a deadline, using a fixed team of software developers (and managers), and buying the expected equipment necessary to build the system. Sound familiar? You are operating under an informal business case.

Even with the availability of a form, many software development organizations undertake projects without much thought about the full business implications of the projects. This attitude can be attributed to the competitive and entrepreneurial spirit of today’s software market. But whether an organization requires a formal business case or not, the concepts are important, even if they are never written down.

Writing the Business Case

Writing a business case is like writing a use case: it is always difficult at first but becomes easier with experience. The best place to start is with the vision document, in which the expected benefits of the project should be captured. Potential benefits include increased or new sources of revenue, increased productivity, increased reliability, goodwill, accomplishment of an organizational mission, increase in development capability through experience gained, and assets such as reusable components [IBM 1997]. Quantifying these benefits, especially the intangible ones, may not be easy.

The project costs are also difficult to quantify, especially at the outset of the project. We may be able to achieve ballpark figures based on a single person’s experience. Less subjective estimates may come out of a group technique, such as the Wideband Delphi Technique [Boehm 1981], where several people meet and discuss estimates until they agree. When using a technique like this, keep in mind that software developers notoriously underestimate a project’s needs. A common way to improve the accuracy of a software developer’s estimate is to multiply the amount of time (and/or money) predicted by two.

At this point, we do not have all the facts, so the business case will probably characterize the benefits more accurately than the costs. Even without reliable cost estimates, completion of this level of information in the business case is a key decision point. We can see if the costs and the benefits (as depicted in Table 3-1) are in the same ballpark. This comparison allows us to understand whether the benefits warrant further elaboration of the business case and the software project.

Table 3-1. Cash flow analysis of a proposed software system (thousands of dollars)

There are many ways to document the value of a software system. A complete list requires quite a bit of accounting knowledge and is beyond the scope of this book. A simplistic way, which does not reflect the time value of money (e.g., interest rates and other potential investments) is the cash flow method. Using the cash flow method, the costs are subtracted from the benefits to show how cash is accumulated and spent across the life of the project.

A summary of the cash flow (see Figure 3-1) can help to quickly print out whether a project is worth undertaking. The actual business case should break down the costs and benefits in more detail. For example, the benefits might be three payments from a customer of $1.8 million each. The payments might be contingent on the product passing certain acceptance criteria of functionality and performance. These criteria may be documented somewhere else (such as in a contract), but they must also be listed in the business case.

Figure 3-1. Cash flow over the course of development

A detailed analysis of the costs of the software project must also be included. Costs for personnel, capital (hardware, software, and infrastructure), and other things such as travel should be itemized so that they may be understood by the decision makers. References to the requirements described in the vision document help to amplify the expected cost of each new feature and permit decision makers to understand where choices may be made to reduce the price tag of the project at the expense of removing a feature.

Finally, documenting financial risks is critical. Is the “sunny day” scenario projected the most likely outcome? If something goes wrong, what will the impact be? Is a technology new or unproven? What is the experience level of your team? Are the benefits based on a projection or a fixed price contract? What are the contractual or market effects of delivering late? Risk analysis can set expectations for things that go wrong. And following Murphy’s Law, if something can go wrong, it usually does.

One risk not usually anticipated by a business case is the effect of the departure of a critical staff member. Smaller companies may be unable to afford a staffing model that provides the redundancy necessary for complete backup. When these companies lose a key person, the effect can be additional, unanticipated cost. The business case is an appropriate place to document risks such as minimal redundancy in the staffing model.

Each risk should be quantified with a percentage chance of occurrence and a cost of dealing with the problem. The best way to compute these values is through history. For example, if the organization averages 5% turnover per year, this information may be used to quantify the expected likelihood of losing a staff member. In addition, the cost of losing such a staff member may be quantified by the cost of finding a replacement and getting the new person “up to speed.” Staffing models that favor redundancy decrease the costs of turnover and overall personnel costs for the project. Of course, the best case is always when a project does not encounter any problems.

Revising the Business Case

Since the vision document contains only a cursory explanation of the project, revision of the business case will be necessary as more information about the scope of the system is determined through use case analysis and architectural design and prototyping. We therefore recommend at least one revision of the cost analysis after the completion of the project plan. The project plan provides more detailed information on the length of time necessary to complete the project and the amount of staff, materials, and equipment involved. As a result, a detailed cost model may be added to the business case. This detailed cost model can be reevaluated if necessary to ensure that the expected value of the project will still be achieved. Should the evaluation reveal that the costs are starting to outweigh the benefits, the project can be evaluated to see whether reduced functionality can allow the project to remain feasible.

Risks may also be updated in the revised business case as a result of the project plan. Architectural prototypes may have been created, which should eliminate many of the risks documented in the earlier business case. The result is a cost model in which the engineering risks are all but eliminated and the software production risks, usually smaller, are left.

The business case remains a living document throughout software development. Other checkpoints should follow any deviation from the project plan or when a significant problem is encountered. The business case should also be updated to reflect new risks as soon as they are identified.

Building a business case requires accounting knowledge far beyond the scope of this book. For more information about building this complex document, see Schmidt [2000].

Conclusion

The vision document and the business case are tools for determining the scope of a software project. The vision document creates a system boundary for the project by setting expectations for what the system will and will not do. The stakeholders of the system are identified and are expected to reach consensus with respect to the expectations stated in the document.

The business case sets expectations for the benefits and risks associated with the project. The business case attaches financial value to the project defined in the vision document.

Each document marks a key decision point in the project’s ability to move from the inception phase to the elaboration phase. Formulating these documents and successfully passing through the decision points represents the transition from a viable concept to a software system project.