This chapter is from the book
This chapter is from the book
This chapter is from the book
2.2 The Vision Document
A Vision Document is the starting point for most software projects. It is the primary deliverable produced in the Envisioning Phase8 and is therefore the first document produced in the planning process. The main purpose of this document is to move the project forward into detailed project planning and ultimately into development.
The Vision Document is designed to make sure that key decision makers on both sides have a clear, shared vision of the objectives and scope of the project. It identifies alternatives and risks associated with the project. Finally, it presents a budget for the detailed planning phase for the stakeholders to approve.
A substantial amount of work is normally invested in the Vision Document. It typically takes several weeks or more to do the interviewing and high-level analysis, to agree upon the content, and to prepare the document.
This is an essential first step. Certainly Vision Documents do have value at the time they are produced. They move the process along into subsequent phases. But do Vision Documents have value after that?
We always like to think that the Vision Document will have enduring value after it is approved. We speak of it as a living document, with the expectation that it has legitimately useful content after approval and is worth maintaining over the life of the project. This is seldom the case. Despite the large amount of time and effort that is often put into these documents, they are rarely ever even looked at by the project team after they are approved. This is frustrating for both the vision authors and the client because they feel they have put a lot of effort into something with very limited return.
While it may take a lot of effort to produce the Vision Document, it often presents only a very general outline of the project boundaries. At best, the Vision Document allows the detailed planners to get a vague idea of what they are going to work on before they interview the client experts. At worst, it has wasted a lot of unnecessary effort and creates the illusion that the detailed planners ought to be much farther along than they are when they join the project.
This happens mainly because there is no overall planning plan and no customer orientation. The needs of the detailed planners were probably not considered in producing the Vision Document. Vision Documents that are not developed as an integral part of the larger software planning process are not likely to provide a helpful foundation for subsequent planning efforts. The Vision Document is designed to satisfy the expectations of internal and external decision makers more than the needs of the planners who will inherit it. The authors probably never asked the planners, "What would help you most during the envisioning phase and how would you like it presented?" Then they are surprised when the planners find little value in a document that was prepared without consulting them or truly understanding their needs.
The fact is that the Vision Document does serve different audiences with very different needs. When managers read a Vision Document, they see the culmination of a lot of time and effort that helps them reach a decision regarding approval of the project. When planners and developers read a Vision Document, what they mostly see are boilerplate, broad generalizations, irrelevant detail, or premature overspecifications that must be corrected. They see very little information in the Vision Document that will benefit them and save them effort.
Certainly the Vision Document is necessary to obtain high-level approval to proceed with design, but once the approval is obtained, what can and should the document contain that is of use to the designers? What material can it feed into the design phase to improve the efficiency of the development process?
If the answer is that the Vision Document is intended to be only a throw-away document which moves the project along into the detailed phases, then the main thrust should be to improve process efficiency by eliminating all information that isn't essential to the goal of project approval.
If the goal is to also improve overall process efficiency by laying the groundwork for subsequent phases, then the emphasis should focus on meeting the very different needs of the project planners. That can happen only by listening to the planners and by putting a software planning process in place that spans these project phases.
To improve process efficiency in either case, what not to include may be a more critical decision than what to include. Only by understanding exactly what information our audience requires, and by limiting our effort appropriately, can we optimize the process. And only that way can we produce a Vision Document that retains its value past project approval.
Later in Chapter 7, we discuss the Vision Document further, identifying what not to include as well as what should be included. It provides some insights on how to seamlessly integrate your envisioning phase into the overall project planning process so that your Vision Document can become a basis of subsequent efforts.