The Vision: Setting Our Goals

A key artifact for the Inception phase is the Vision. ^[2] The Vision can be represented as a formal document kept under version control or informally ”as simple as a Post-it note stuck to a wall. The purpose of the Vision is to get everyone on board for the project, headed in the same direction. Vision is a powerful thing. In their book Software for Your Head , Jim and Michele McCarthy identify Shared Vision as a key pattern for high-performance teams .

^[2] The template for the Vision includes more than just a Vision statement. It also includes descriptions of the high-level features of the product. So, when we talk about the Vision artifact, we mean both the Vision statement and a statement of features.

Determining what to build was relatively easy for us because Watts Humphrey had written a high-level specification, or at least a high-level problem and solution statement, in A Discipline for Software Engineering . Gary had used the practice for years . Russell knew about PSP from Gary and wanted to use it. So we started the project with an understanding of what to build and needed only to establish boundaries on how much we would build. Throughout the project, Russell helped us identify the feature set and manage changes to it.

Discovering the Extent of the Project: What to Build and What Not to Build

When we started the project, we knew that we wanted to automate the data gathering and reporting for Personal Software Process (PSP) level 1 to help software engineers improve their craft. Our goal was to build a tool that could measure and record planned and actual time spent on specific tasks . This tool would allow a software engineer to compare the estimate against the reality. We also wanted to capture information about defects ”where in the process they were introduced and where they were discovered and addressed. We identified the types of data we wanted to capture and report on by selecting tables from Appendix C in Humphrey's book. (For more about PSP, see Appendix B in this book.) Russell also had ideas about what we should build, based upon the needs of his team.

Because we had a solid understanding of what we wanted to build, writing the Vision was a quick exercise. We started with the RUP Vision template and used the document to define the scope of the project. The Vision included what we planned to build (and why). When we released the first version of our product, we reviewed what we originally thought we would build and compared it to what we actually did build. As we plan each new release, we will use the Vision as our starting point. This doesn't mean that the Vision is static throughout the project. Like most artifacts in a usable process, the Vision is a living artifact that you should change and update when necessary.

On other projects, creating a vision can be more difficult as stakeholders struggle to capture the essence of a large and complex project. However, it is essential to do this work before implementation starts. The Vision is a focusing artifact. It provides the general direction for the team throughout the project. Whenever you are unsure about whether to add a feature or change the way the system might work, the Vision can act as the compass that points you in the right direction. When teams can't agree on the project's scope early, they waste time later by implementing unnecessary features or forgetting to implement necessary ones.

The Vision template contains two small paragraphs, in tabular form, that help focus the team on what they are building and why. Following the format helped us get to the core of our vision quickly, without writing a lot of ambiguous or confusing prose . In our Vision, these paragraphs are part of Section 2, Positioning. The first paragraph is a Problem statement. Figure 5.1 shows the problem statement from our Vision. By filling in the right column, you describe the problem, who it affects, how it affects them, and what type of solution would ease the pain.

Figure 5.1. Problem statement from our Vision

The second paragraph in the Positioning section of the Vision is the Product Position statement. If you could develop software that would solve the problem described in the Problem statement, the Product Position statement describes who would buy it and what would make it unique. The Product Position statement spurs you to focus on your audience early in the process. Figure 5.2 is the Product Position statement from our Vision.

Figure 5.2. Product Position statement

The benefit of following the format of the Product Position statement is that it helps you succinctly capture both the problem you are trying to solve and the value and unique qualities of your solution. The Problem statement and Product Position statement help you communicate your vision to the whole team, including your stakeholders.

Who Are Our Stakeholders?

A Vision is incomplete without an understanding of who the stakeholders are. Who are you building this software for? Who will use it? Why do they need it? The answers to these questions help you identify the right set of people to work with when you gather requirements for the software. Stakeholders are not only customers. They are anyone who has an interest, usually a vested interest, in the success of the project.

The Positioning section identifies customers, or users, of our product. The users are not the only stakeholders, or even necessarily the most important stakeholders. When you build a product for a paying customer, that person is often the most important stakeholder. In many companies, the IT department manager or the manager who orders the software might be the most important stakeholder, sometimes called the gold owner .

Whether you have a single gold owner or many paying customers, you will almost always have several stakeholders. It is important to identify who they all are, and how important their input is to the success of your project.

Identifying Stakeholders

On our project, our customer, Russell, found us. There were other stakeholders for this project. Each of us was a stakeholder. We wanted the project to succeed. We wanted to write this story about how we built the software, and to learn some things along the way. For professionals in our industry, the possibility of learning can be a huge incentive. Later in the project, other stakeholders appeared in the form of potential Beta testers.

Writing a Brochure

Jas and Liz decided to write a brochure that captured the essence of what we thought we were building. The brochure was conceived as a marketing version of our Vision. We wrote it by imagining that the implementation was finished and that we were about to ship our product. For Jas and Liz, who were not planning to write code, this exercise helped them understand the Vision. Figure 5.3 shows the brochure.

Figure 5.3. Our PSP Tools brochure

Gary was initially skeptical about the value of the brochure. He questioned why team members were wasting valuable time on this activity. In hindsight, and with uncharacteristic humility , he wishes we had spent even more time on the brochure. Compared to the Vision document, a brochure provides an easier way to communicate the essence of the product to those not directly involved with building the software. If you are on a project building a new software product, perhaps in a start-up company, the brochure is a great way to convey your vision to potential investors and talent you hope to attract .

In retrospect, Gary says that he should have insisted that we work on the brochure until it captured the spirit of the project. He also should have asked that we each keep the brochure on the wall near our work area. The brochure was, in fact, the high-level vision statement for PSP Tools.

Specifying the Features

Even with the brochure, it was important to specify the product's features in the Vision so that we could refer back to them later and use them when analyzing our solution for completeness. We identified features by holding discussions with Russell, reading the PSP documentation, and hosting brainstorming sessions with the development team. Some of the features we identified were not implemented in the first release, but they were certainly part of our shared vision.