Share the Vision

What is the problem?

The lack of a clear vision about a system can lead to indecision and contrary opinions among the stakeholders and can quickly paralyze the project.

What the trade-offs influencing the vision?

Time pressures can encourage people to start developing a system prematurely, basing their work on erroneous assumptions.  Pulling them back together again can be expensive.   Often, the builders simply enumerate the system’s basic services, creating use cases without any regard to their purpose or understanding their value to the actor requiring the service.  This approach fails to accurately reflect the user’s needs and can paradoxically result in features that are unnecessary or deficient.  Many of the so-called CRUD (Create, Read, Update, and Delete) use cases originate from a lack of a clear vision. 

Builders have a natural tendency to expand the scope of the system. Without some guiding principle that can be used as criteria for evaluating and scrubbing features, there is a danger the development team will expand the scope of the system. The vision provides a mechanism for removing vague, ambiguous or poorly defined requirements from the scope of the project. It is an objective filter for scrubbing requirements, and helps to define what is in or out of the system’s scope.

Stakeholders have competing visions. There are competing visions of what are the needs and responsibilities of actors may be, and often very little knowledge to help select the most appropriate vision of the system. Most projects are under time pressure and cannot simply evaluate countless number of alternatives. They must begin to limit the solution space quickly. If there is no clear vision, then project participants may substitute their own vision for the project, which may conflict with the corporate mission. For example, without a vision the software developers may create their own vision for the product that emphasizes scalability and flexibility in the software architecture. While these are highly desirable architectural characteristics, they may conflict with the corporate need to quickly and cheaply deploy a system.

People in the trenches don't know what the goal of the project is or why they are doing it.  An interesting experiment on larger projects is to go around and ask the participants why they think the project is important. If you’re fortunate, most people will understand how their specific piece of the project contributes to the overall project. But does anyone understand what the goal of the project is beyond make money or reduce costs? What does the system allow its users to do that they couldn’t do before? Why is this important? Simply, is it clear to all project participants why someone is willing to pay money for the system?

People don't communicate.  Despite the best efforts to encourage communications by tearing down private offices and replacing them with cubicle hell there are many barriers to informal communications in any organization. The larger the organization the stronger these barriers are. When there are strong barriers to informal communications, then the formal communications channels must be strengthened.

What do we need to do?

Prepare a statement of purpose for the system that clearly describes the objectives of the system. Ensure that this vision supports the mission of the organization, and freely distribute it to everyone involved with the product.

Include:

  •  the objectives of the system,

  • ·the problems that the system is solving,

  • ·the problems the system is not solving,

  • ·who the stakeholders are, and

  • ·how the system will benefit the stakeholders.

Maintain consistency in the vision by having a small team of people responsible for creating the vision.  A characteristic of many successful projects is the appointment of a single person who champions the vision of the system and is responsible for maintaining the consistency of that vision. This responsibility usually falls on someone in a marketing role such as the product manager. This person must also take an active role in ensuring that all members of the development team share the same interpretation of the vision.

Validate the vision and seek support for the vision by obtaining advice from those who will be affected by the system..

Strengthen and constrain the vision by clearly specifying what is outside of the system and what is part of the system  

Ensure the vision is supportive of the stakeholders’ mission and does not work at cross-purposes. A truly excellent system vision will fail if it defines a vision that works against the organization’s mission

 

TPFKB Practices that help share the vision:

Task: Define Vision and Vision Work Product

The TPFKB task  Define Vision prescribes the Analyst create a Vision work product. The intent behind this work product as a concept document is to insure everyone has a common understanding of what the project is about. Creating the Vision is not a task where the intention is simply to "tick it off" the work item list of required work products. While the artifact is part of the TPFKB, the intent behind the work product is to put all stake holders and participants on the same page. Vision is a vital element to the creation of unity of purpose on the team. For the team to have a proper vision they must know why this project is being undertaken, what are the trade-offs (e.g. time or low cost). The vision is important to enabling individual team members to take the initiative and make decisions quickly and independently.

Steps: Review and Assessment Steps

Review and assessment steps in different tasks are opportunities to reflect if work products have captured the intention behind the vision for the system.

Why Is this Important?

The vision is important because it is what gives focus or the Schwerpunkt to all activities and helps project participants take the initiative when opportunities present themselves, yet still work harmoniously and not at cross purposes. This concept of harmonious initiative enable a team to make progress rapidly in an uncertain environment.

While TPFKB advocates the creation of a Vision you must not delude yourself into believing simply producing a vision work product creates the vision. The intent behind this is the creation of a useful shared common  vision between all project stake holders (customers, managers, developers).

Situational Awareness

Shared mental model.