Scope definition, and why cost and risk controls fail without it

Scope is rarely the first thing anyone reaches for at the start of a project. Most organisational processes are built around cost and risk, because cost overruns are what get noticed. That is understandable and largely futile: every other project control operates on the scope, so if the scope is loose, the controls are measuring something that keeps moving.

Scope is what the project will change or deliver. Just as important, and far more often neglected, is what it will not deliver. An unstated exclusion is a claim waiting to happen.

Three documents carry the weight.

Project charter

Identifies the project manager, the project owner, the objectives and a high-level schedule. It goes by various names. Its function is to establish who is accountable for what, before anyone has an incentive to be vague about it.

Scope statement

The single source of truth for what is in and what is out. It should carry:

• the problem statement — what issue is being resolved;
• the business objectives — why the business wants it resolved;
• the project objectives;
• the project deliverables — what packages of work the project will produce.

Stakeholders contribute to it. That contribution is the point: the argument you have while writing the scope statement is the argument you would otherwise have during commissioning, at ten times the cost.

Requirements and traceability matrix

This is the document that separates projects that can prove completion from projects that argue about it. It distils the scope statement into individual requirements, and for each one records:

• who originated the requirement;
• which business objective it serves;
• how it will be validated — the test performed, the audit conducted, the document approved;
• that it has been verified, with the project owner's sign-off.

Kept properly, it is both a live control and, at handover, the proof that the project delivered what it undertook to deliver.

Keeping it current

Detail accumulates as a project develops, and these documents have to keep up. Re-issue and re-approve the scope statement at the end of each project phase. Anything that changes the scope definition — a different meter type, expanded battery limits, a client trimming scope for budget — goes through management of change and the scope statement is re-approved. A scope statement that was accurate at FID and untouched since is not a control, it is an artefact.