Commercial, IP and Statement of Work Alignment

Overview

Our agile process is designed to operate inside a controlled commercial model. Agile gives flexibility in how we solve problems. It does not remove the need for a clear Statement of Work, commercial authority, acceptance criteria or IP protection.

Statement of Work Alignment

Every phase should be linked to a Statement of Work or other approved commercial authority.

The Statement of Work should define:

• phase

• objectives

• scope

• out of scope

• deliverables

• milestones

• acceptance criteria

• assumptions

• customer responsibilities

• dependencies

• team model

• governance cadence

• commercial model

• IP position

• security and data requirements

Agile Scope Control

The backlog can change frequently. The authorised scope cannot change informally.

A backlog change may remain inside scope where it:

• supports the agreed objectives

• does not add material deliverables

• does not change acceptance criteria materially

• does not extend timeline or cost

• does not introduce new material risk

• does not change the IP or security position

A backlog change should go through change control where it affects:

• cost

• timeline

• deliverables

• acceptance

• security

• data

• IP

• supplier obligations

• material assumptions

Milestone Alignment

Milestones should be connected to evidence.

A milestone should not simply say that a phase has progressed. It should identify what has been delivered, reviewed or accepted.

Examples:

• discovery findings accepted

• alpha prototype playback completed

• beta release deployed to private beta users

• live readiness evidence approved

• support model accepted

Acceptance Criteria

Acceptance criteria should be agreed before delivery starts. They may be refined as learning emerges, but material changes must be approved.

Acceptance criteria should be:

• objective

• testable

• linked to deliverables

• capable of evidence

• commercially meaningful

• realistic for the phase

IP Categories

We classify IP as:

• Background IP: pre-existing company assets, templates, methods, code, frameworks and know-how

• Foreground IP: IP created specifically during the project

• Customer IP: materials, data, documents and systems provided by the customer

• Third-party IP: externally owned components or services

• Open-source components: components governed by open-source licences

IP Reuse Principles

• Reuse approved company assets before rebuilding.

• Do not transfer Background IP unless expressly agreed.

• Check licence terms before using third-party or open-source components.

• Do not contaminate reusable assets with customer confidential information.

• Record improvements that may be reusable.

• Confirm Foreground IP treatment in the contract or Statement of Work.

Accelerator Use

Accelerators may include:

• discovery interview guides

• service blueprint templates

• backlog templates

• architecture patterns

• code scaffolds

• deployment pipelines

• test scripts

• security evidence packs

• acceptance criteria libraries

• governance templates

Accelerators should be used when they are relevant, current, secure, legally usable and appropriate to the customer environment.

Commercial Health Checks

At each governance review, ask:

• Are we still inside the agreed Statement of Work?

• Are deliverables and acceptance criteria still valid?

• Are customer dependencies being met?

• Are changes being controlled?

• Are milestones and payment triggers supported by evidence?

• Is the IP position still clear?

• Are supplier outputs aligned to customer obligations?