Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

Vision and Scope Document

the notes in italics are meant to be deleted.

Business Case

The Business Case is the chapter that defines why the project is needed.

Current Situation

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.

#Project Scope

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.

Quality Criteria

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.

#Project Planning

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.

Change Management

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.