Clear and unambiguous scope definition is paramount to successful completion of any project.
Without a clear and agreed and approved and signed-off scope definition there will always be confusion and delays in project completion because your customer will always be asking for more.
Both Parties Need to Sign-off on the Project Scope
I 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.
The specific details of the scope statement can then be derived from the agreement or contract.
Project Objective or Project Deliverable?
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
This breaking up of the project deliverables into smaller easier to manage components is called ”Decomposition”.
Scope 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”.
And what is a Work Breakdown Structure? Later…
