Understanding the Planning Process
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 Phase 8 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.
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.
2.3 The Functional Specification
After the Vision Document is approved, effort typically shifts to production of the Functional Specification. Some companies create separate marketing and technical requirements documents, but however it is packaged we will call it a Functional Specification here to avoid getting lost in terminology.
The Functional Specification is the cornerstone of software planning. It embodies all of the business requirements, software requirements, and product specifications. The intent is to provide a complete, self-contained master plan of what will be produced. Normally, it is hoped that by the time this document is complete, all questions have been answered and the solution has been fully designed on paper. With the Functional Specification in hand, many managers and planners feel that they should be able to hand it to any development team and lock them in isolation until the system is ready for deployment.
|Flashback—VB Database Class|
I have taught a class on Visual Basic database programming for many years. As part of that class, my students complete a personal class project. Their first assignment is to produce a simple one-page Vision Document/Functional Specification of their project. I tell them to simply explain in plain English what their planned programs will do. You'd think it would be easy points.
Despite the apparent simplicity of the assignment, I get a tremendous variety in content, most of which is not at all useful. Their planning documents are littered with sparse, overly general, unnecessarily detailed, or meaningless boilerplate. Although I expressly tell them not to dwell on implementation aspects such as database structure because that is documented in the next lesson, most do so anyway. Most of the students do not communicate effectively and do not seem to consider the needs of the reader.
At one point I became so frustrated that I considered discontinuing this assignment. Then I decided that the fact that students have so many problems with it is the best reason to continue to assign it. Usually out of a class of 24, there will be two or three reasonably clear specifications that actually do give the reader some useful insight into what their project will do. I typically read one or two of those to illustrate an effective specification and point out what the student did right.
Page 4 of 8