Get the Right People

Phase Envision

It is rare to discover anything in the realm of human behavior that occurs with great consistency. Therefore, it was surprising to find that in every case, without exception, when an effectively functioning team was identified, it was described by the respondent as having a clear understanding of its objective (Larson and LaFasto 1989).

It's the vision thing again! Visioning and goal setting have been identified time after time as key ingredients of project, and general management, success.

But how does this need for a clear vision jibe with the exploratory nature of product development, which we have just gone to great lengths to describe as volatile and fuzzy? This apparent dichotomy is resolved by the fact that while the details of requirements and design can be volatile and fuzzy, the overarching business goal or product vision must be clear. In fact two critical aspects of a vision are clarity and an elevating goal that makes a difference and conveys a sense of urgency to the project (Larson and LaFasto 1989). Absent a clear vision, the exploratory nature of an agile project will cause it to spin off into endless experimentation. A clear vision must bound exploration.

If everyone knows that creating a clear, compelling vision is so critical to project success, then why do so many teams suffer from lack of vision? The answer is that creating a clear, compelling vision is hardit takes work, and it takes leadership. In the process of developing a new product there are so many options that creating a clear path forward can be daunting. This is one activity in which effective leaders leadthey help cut through the ambiguity and confusion to create an effective vision. Compounding the problem is the fact that there is no fixed rule for creating a good vision statement. It's one of those "I'll know it when I see it, but I can't describe it" phenomena, in part because the essence of a good vision is the leader's articulation of it.

The purpose of the envisioning phase is to clearly identify what is to be done and how the work is to be accomplished. Specifically, this phase answers the following questions:

For small projects, much if not most of the work of the Envision and Speculate phases can be accomplished in a single "kickoff" week. For larger projects, requirements gathering, additional training, resource procurement, and architectural work may take longer and can be included in an Iteration 0 (see Chapter 6). For large- to medium- sized projects there is normally a debate and discussion period required in order to obtain agreement about the product vision. During the Envision phase the vision constantly evolves based on new information. After the Envision phase it needs to be reviewed periodically to ensure that the team continues to understand the vision.

Depending upon the situation, the information available to an Envision phase will vary, but the key outputs remain constant: product scope, project objectives and constraints, project participation, and project approach. While there are other important aspects of initiating a project, such as budgets , staff organization, and reporting needs, without a commonly held vision the project will falter.

Envisioning begins in whatever feasibility study initiates the project. Because the APM model as shown is not a portfolio or total product lifecycle model, it uses information provided by the feasibility study and extends it. Many companies conduct feasibility and marketing studies prior to initiating development projects, while others use only brief project requests .

Figure 5.1 depicts the evolution of a project planfrom vision, to scope, to featuresutilizing three simple but powerful practices: the vision box, the project data sheet, and the iterative feature plan (accomplished in the Speculate phase). Each of these artifacts is simple in concept, powerful, and low ceremony (informal), and each operates on the principle of limited "real estate." The vision box exercise forces the team to condense information about a product vision onto the limited space of a box. The project data sheet forces the team to condense key project scope and constraint information into a single page. Feature cards force the team to condense the key information about a feature onto a single 4x6-inch index card. Limiting the space in which we record information requires focus and selectionit demands collaboration and thinking, and it compels the team to make effective tradeoffs.

Figure 5.1. Evolution of a Project Plan

In the Envision and Speculate phases of APM it is particularly important to remember that:

The practices explained in this chapter fall into four categories: visions for product, project, community, and approach (see Figure 5.2). [1]

[1] For additional information on project envisioning, see (Highsmith 2000), Chapter 4.

Figure 5.2. Envision Phase Practices

Product Vision

Project Scope (Objectives and Constraints)

Project Community

Approach

Related

Категории