In my practice, do not use the term, "Vision and Scope Document." However, prominent author Karl Wiegers does and...
is gracious enough to make an excellent example of a vision-and-scope plan available for download on his website. Here's a brief overview of the vision-and-scope planning outline Wiegers' suggests:
- Background, Business Opportunity, and Customer Needs
- Business Objectives and Success Criteria
- Business Risks
Vision of the Solution:
- Vision Statement
- Major Features
- Assumptions and Dependencies
Scope and Limitations:
- Scope of Initial and Subsequent Releases
- Limitations and Exclusions
- Stakeholder Profiles
- Project Priorities
In my consulting work, I do use the term "vision" in the contexts of strategy and leadership, but not with respect to requirements. I also do use the terms "scope" and "business requirements," but in somewhat different ways from Wiegers'.
For instance, I use the REAL business requirements methodology, wherein I define two types of scope, both in terms of high-level business requirements deliverable whats. The first type of scope is the "scope of the requirements," which is what must be delivered in business terms to provide value by solving a problem, taking an opportunity, or meeting a challenge. This scope is not at all determined by the organization's available resources. It's what is needed to get real value, regardless of their ability to accomplish it.
I believe this approach places much greater emphasis and effort on assuring the problem/opportunity/challenge is defined correctly, its value is quantified, its key causes have been identified accurately, and the business requirements in fact will reasonably address the causes and achieve the value by solving the problem. I encourage using a very powerful and systematic disciplined tool called the Problem Pyramid to help guide this critical identification of the scope of the requirements.
The second type of scope is the "scope of the implementation project." It consists of a subset of the requirements scope's high-level business requirements based on budget, resource, and time constraints which typically limit the ability to fully satisfy the requirements scope. I believe the implementation scope is more likely to be what's described in a Vision and Scope Document like Wiegers'.
A Vision and Scope Document prepared by someone with Wiegers' skill very well could seem to deal largely with business needs and cover much the same information as a Problem Pyramid. However, in more typical projects, the Vision and Scope Document is very likely to leap directly to describing high-level design features of a product, system, or software to be implemented.
In contrast, my methodology first discovers additional detailed business requirements to flesh out the implementation scope's subset of high-level business requirements; and only then, is a product, system, or software designed which can reasonably meet the relevant detailed business requirements.
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.