Vision and Scope Document
the notes in italics are meant to be deleted.
The Business Case is the chapter that defines why the project is needed.
To understand the project, every participant needs to understand how things are working now.
Make it clear to everyone that you really understand why the project is needed, and what the problem is in the current situation.
All stakeholders in the project need to be aligned so that they share the same vision of the future product.
Document why a certain direction was chosen, and from which available options.
Make sure that everyone has the same idea of business value for the customer.
The Project Scope is the chapter that defines what the project will produce.
Define, in broad terms, the size of the project by explaining what activities you will perform, and for how long.
Out of Scope
It’s also very important to mention explicitly what you will not do, so that there will be no misunderstandings.
Give the customer an idea of the (sub)systems you will be delivering, without details, on the highest possible level.
People and Roles
Name the stakeholders and their roles and responsibilities in the project. Make sure that everyone knows who can take which decisions.
Name any quality requirements that are applicable, and assign priorities in case of conflicts among the qualities (like performance vs. security).
Name any technological standards and business standards applicable to the product.
Be sure to mention any risks, so that any re-planning (when some of the risks turn into real problems) doesn’t come as a surprise later.
The Project Planning is the chapter that defines how/when we intend to do the project.
Mention the process you will apply, either by referring to a defined method (like Scrum) or to a document describing your own custom process.
Name any specific dates and (if known at this stage) what you expect to be delivering. Regular iterations/releases might be mentioned here.
Name any dependencies, like the involvement of third parties, that are beyond your own direct control.
Make any assumptions explicit, like the availability of a customer stakeholder, or the availability of graphic designs.
Define how you’re going to cope with changes during the project. This is part of the defined process, but it deserves to be mentioned explicitly.