A scope statement
In relation to the knowledge areas in the PMI PMBOK © , developing the scope statement is included in and the most important output from the scope planning process.
The written scope statement identifies both the project deliverables and project objectives. It provides a basis for confirming or developing common understanding of project scope among the stakeholders.
Before the project manager sits down in front of his trusty keyboard, he must have a clear understanding of the project.
The scope statement can be a section within the project plan or can be a separate document.
The scope statement should include the following information:
The scope statement should be reviewed and approved by the project sponsor.
The scope statement also should be approved by the customer. The customer's version of the scope statement will not contain any supplier confidential information, e.g. budgeted costs.
The scope statement is the basis for further processes in the scope planning phase of the project, including scope definition, scope verification and scope change control.
We cannot emphasise enough the need to clear out any grey areas, all uncertainties and ambiguities
One sure way of doing that is to enter into a formal contract or agreement with the principal stakeholder. In an external project this is for sure the paying customer. In an internal project, it will be the Sponsor.
A contract is needed to set the rules, the terms of engagement.
In an external project the contract is between the buyer and the seller, it should be formalised and signed by persons in both organisations given the authority and responsibility to do so.
In an internal project, where "profitability" is replaced with "Return On Investment" as a Key Performance Indicator, the 'contract' or agreement is normally between the Sponsor and the Project Manager.
And in the immortal words of the mighty PMI PMBOK © 1996, the agreement can be formal or informal, highly detailed or broadly framed based on the needs of the project.
The specific details of the scope statement can then be derived from the agreement or contract.
We must also keep in mind the difference between project objectives and project deliverables.
To be successful, a project must not only deliver the product the project was formed to create, according to the buyer's/sponsor's specifications and description but also must meet the predefined project objectives.
To be meaningful these project objectives, usually in terms of time, cost and quality, must be quantifiable and measurable.
Although it is generally accepted that anything not specifically included in a scope statement is not part of the project scope, for clarity it is recommended that the scope statement must also identify known exclusions, especially if they are contentious.
Scope definition is a natural follow on task after writing the scope statement.
Scope definition involves subdividing the project deliverables into smaller components. The smaller components can also be subdivided into even smaller groups of self contained work tasks.
Breaking down the project deliverables into smaller easily identified 'works packages' will
In 'PMI-speak' this breaking up of the project deliverables into smaller easier to manage components is called 'decomposition'.
The lowest level of Work Breakdown Structure and the most defined group of work tasks is called a 'Work Package'.
The recommended method for defining scope is to build-up a Work Breakdown Structure.
A Work Breakdown Structure is a project deliverables oriented grouping of the full scope of work.
It can be used to confirm a common understanding of the full scope of the project. Any work not included in the WBS is not included in the scope of the project.
The Work Breakdown Structure facilitates the planning and control of cost, schedule and technical quality of the project outcome.
A Work Breakdown Structure is developed by identifying the project deliverable and then successively subdividing that deliverable into increasingly detailed and manageable subsidiary deliverables or components.
There is no single best way to develop a WBS. It is acceptable practice to use a WBS template or a WBS from a previous project when developing a project specific WBS. In fact this may be preferable in certain organisations for standardisation and ease of understanding.
The WBS is normally shown in the form of a chart, similar to an family tree. Each level breaking down the scope of the work into more defined components, until the lowest, works package level.
The Works Package components, the lowest level of the WBS consist mainly of physical work. For example, manufacture of components and sub assemblies. The higher levels of the WBS are simply aggregations of works packages into logical sets, for example, buildings or machines.
Each component of the WBS has its own set of goals and project objectives which must be achieved in order for the overall project objectives to be met.
Project success is assured by managing cost, schedule and quality at the works package level.To do this, completion of a works package must be measurable and verifiable.
If this can be achieved then the WBS provides a solid basis for progress monitoring, cost control and project performance assessment.