Vision Approved Milestone and Its Deliverables

The goal of the Envisioning Phase is to reach the Vision Approved Milestone, which is the culmination of the team's work during this phase and signifies agreement between the customer and the team on critical project issues.

Four deliverables are required to meet the Vision Approved Milestone. They are:

• A Vision Document, which outlines the product being developed, the needs it will meet, its features, and initial schedule
• A Project Structure Document, which outlines who is responsible for each role in the MSF Development Team Model and identifies the team lead for each role
• A Master Risk Assessment Document, which lists possible risks to the project and outlines how the team plans to deal with each one

We also recommend that a prototype system be included with the deliverables for this milestone to show how the team initially plans to execute the project, and to present concrete visual evidence of the product vision.

NOTE

---

The goal of any deliverable is that it serves as an efficient communication tool. In this context, a deliverable does not necessarily result in a paper artifact. A deliverable can take whatever form is appropriate (a document, a diagram, a screen shot, e-mail, and so on) as long as it facilitates communication.

Every major milestone in the MSF Development Process Model signifies an agreement between the customer, the project team, and any other key project stakeholders. Reaching the Vision Approved Milestone indicates agreement on the points listed in Table 5.4.

Table 5.4 Agreement achieved by the Vision Approved Milestone

Point of agreement	Documented in
Business needs that will be met by the project	Vision Document
The project vision	Vision Statement
The product design goals	Vision Document
The product team	Project Structure Document
The initial concept of the business solution	Vision Document and Prototype
Risks of building the product	Revised Master Risk Assessment Document

The Vision Approved Milestone provides the initial opportunity for the customer and the project team to decide whether to proceed with the project. After reviewing the deliverables from the Envisioning Phase and fully understanding the product vision, the customer or the project team may decide that the product does not provide enough benefits to justify its costs. This decision represents a critical point in the beginning of the project. A well-executed Envisioning Phase enables the team and the project stakeholders to proceed with confidence, knowing that there is sufficient information about the remaining development phases to maximize the chances for success.

Vision Document

To be effective, the Vision Document developed by the end of the Envisioning Phase should include at least these elements:

• A vision statement
• User research
• Competitive information
• Feature buckets and features
• A rough schedule

Writing a Vision Statement

During the 1960s, when the United States was trying to place a man on the moon, President John F. Kennedy created a vision for everyone in the country to rally behind. We can paraphrase that vision as:

In the next decade, we will send a man to the moon and back safely.

This vision statement illustrates many of the attributes of SMART goals, which are:

• Specific
• Measurable
• Achievable
• Relevant
• Time-based

To bring this discussion down to earth, another example of a solid vision statement is:

Quickly create the fastest spreadsheet on the planet.

Presented with that vision statement, every member of the project team would instantly know that performance issues were more important than any other factor. In fact, a good rule for concise vision statements is to make them so clear that a new employee will stand as a good chance of working toward a solution that is consistent with the project's goals as a current employee.

Reporting on User Research

What the team learns about its customer and users is the underpinning of everything else it does. Site visits, contextual research, market research, focus groups, and international visits will help gather the information needed to describe the primary customer and the users. Additionally, this research provides information for creating usage scenarios that describe how users currently work and how they will work in the future with the product.

Providing Competitive Information

Will the product provide an appropriate return on investment in both today's and tomorrow's competitive landscapes? What other solutions are available to meet the customer's needs? The team must make sure that the product it envisions solves the customer's problem better than any other available solution and that it does so in a way that justifies the investment. The best solution to a problem doesn't have to be a software solution. For example, it may be simpler and more cost-effective to hire the services of a person, such as an accountant, instead of using financial software. Even if a software solution does fit the needs, it should not be assumed that the software must be built from scratch. Research about other systems that provide the required functionality might identify a commercial solution. Even if the solution is not purchased, insight can be gained from the commercial software that will lead the team toward creating a stronger internal product.

Sometimes a project must compete with other demands on the organization's resources. For example, in the latter part of the 1990s, many companies spent a significant portion of their software budgets evaluating the threat of the Year 2000 problem, which directly affected many other software projects.

Describing Feature Buckets and Features

Feature buckets are the categories into which all the product's features will fit. Program Management uses these categories to test whether the proposed features meet the goals of the product. If a feature doesn't fit into any of the buckets, it's probably not important enough for the current release.

Feature buckets should be specified with an eye to the future. Some people maintain that each release of a product can provide only three categories of features. Even so, it's a good idea to create as many as five feature buckets to allow for a product's current and future needs. This practice builds a foundation now for the features that will be postponed until a later version of the product.

Specifying Priorities and the Schedule

By the end of the research, analysis, and rationalization steps in the envisioning process, the team usually has a rough idea of the schedule and of the tradeoffs necessary to meet it. Additionally, the team will choose the appropriate tradeoff triangle setting for the project and will use the triangle to communicate how the project's resources, features, and ship date will be constrained, optimized, and accepted. Including this information in the Vision Document shows that the team is thinking about the tangible realities of development, and gives some structure to the other elements of the vision.

Prototype System

Clearly communicating the information learned from the customer and users is difficult. Information about business requirements must be communicated to team members with varying degrees of technical and business background, and information about how the product will solve the business problem must be communicated to the customer and users.

To more easily accomplish this communication, a prototype application that demonstrates portions of the product's vision should be developed during the envisioning process and included in the Vision Approved Milestone deliverables. The prototype may be a working application, or it may be a series of sample application screen shots. This prototype helps clarify existing ideas and helps draw out additional ideas from the team, the customer, and the product's users.

Project Structure Document

Whereas the Vision Document describes what will be done, the Project Structure Document describes who will do it. This document simply identifies:

• Each team role.
• Who the lead is for each role.
• Who is assigned to each team and their contact information.
• Who the project stakeholders are.
• How the project will be managed, such as change control systems and status reporting.
• Project meeting schedules, e-mail aliases, and web sites.

It can also be helpful to include a short description of the team leads' background and experience and to provide contact information for stakeholders such as the product's customer and key users.

Master Risk Assessment Document

An important deliverable of the Vision Approved Milestone is the Master Risk Assessment Document, which provides an analysis of the project's risks and plans to manage them. The bulk of the Master Risk Assessment Document consists of the itemized risks with their descriptions that were gathered in the risk action planning step of the MSF Risk Management Process described earlier. These are typically summarized into a top-ten list, both for an executive overview and to raise additional awareness. This list describes the risks, their contingency plans, and who is responsible for executing those plans. Finally, a simple chart of risks with their management metrics can quickly communicate which risks have the greatest probability of occurrence and greatest impact on the project.