 |
Although much work has been done, this will be a first attempt
to put a fence around the scope. While some issues remain
unresolved regarding the scope, these can be managed by making
some assumptions and ensuring these assumptions are documented.
The High Level Scope will evolve over time into the final
scope for the project. This can then be managed and any changes
treated as a variation which is submitted to a proper change
control process.
It is not uncommon for the first draft of the High Level
Scope Document to be modified by the time the Phase Zero Report
is approved. Approach this document on the basis that it is
easier to modify something that exists than it is to work
with an undocumented concept. You cannot rely on something
that only exists as individual interpretations of what people
might perceive the project to be.
There is a logical connection in the way the scope is documented.
- The starting point is to define the business problem.
- An outcome is how the world will look when the business problem is resolved.
- In order to achieve the outcome, certain things have to
be delivered. Some are delivered to the
organisation as an output of the project, and some are internal
project deliverables. An internal deliverable may be a project
plan, or a risk assessment, or a requirements document.
- To know if we are successful, we need to set measurable targets or objectives
- There will be things that might be mistaken for being in the project and we need to define if they are in scope or out
of scope
- There will be immovable things we need to work about so we need to list constraints
- We must assume some information in order to plan. These are the assumptions
- There will be critical success factors or things that must happen or the project will fail
- No project happens in isolation. This project may be dependant on something else, or another project may be dependant on this project
|
