Practical Project Management

A scope statement

• forms the basis for agreement between customer and supplier
• will be the basis for all project related decisions
• will be used to determine whether the project has been completed.

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.

• He will have reviewed the contract.
• He will have memorized the project assignment given him by the project sponsor.
• He will have clarified the responsibilities between customer and supplier (documented in the statement of responsibilities)
• He will have identified any constraints and work that is specifically excluded from the scope.
• He will have had discussions with the sponsor, the customer and other major stakeholders.
• He will have had meetings with the sales and negotiation teams.

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:

1. Strategy: An overview of the customers business needs in relation to the project and the business need the project was undertaken to address.
2. Product of the project: A summary of the project deliverables.
3. Project Objectives: Quantifiable goals in terms of time, money and technical quality that the project must achieve to be considered successful.
4. Supporting detail: Description of all assumptions and constraints considered during the development of the scope statement.
5. Scope Management Plan: A description of how the project scope will be managed and how agreed changes will be incorporated into the project deliverables. There is usually a separate document describing the change control process and a cross reference to that document should be included in the scope management plan.

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.

Scope Definition

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

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;

• allow easier management of each component
• allow accurate estimation of time, cost and resource requirement
• make it easier to set a baseline for performance measurement
• allow easier assignment of resources
• allow easier assignment of responsibility for works packages

In 'PMI-speak' this breaking up of the project deliverables into smaller easier to manage components is called 'decomposition'.

Decomposition involves;

• Identifying the major components of the work scope. The way these major components are identified must also be in synch with how the overall project will be managed. For example the first level of decomposition may be into project phases or may even be geographical, country or region.
• Deciding if cost, schedule and quality can be effectively managed at this level of detail. If no, break the component into another level of detail.

The lowest level of Work Breakdown Structure and the most defined group of work tasks is called a 'Work Package'.

Work Breakdown Structure (WBS)

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.