Change Requests: Scope, Cost and Approval Records

Identify what is actually changing

Link the request to the original scope and version. State whether the proposal adds a feature, changes behavior, repairs a defect or clarifies an ambiguity. These categories can have different commercial treatment; a supplier's label alone should not determine whether the buyer pays. Record the agreed classification and unresolved disagreement.

Describe the desired result in the user's workflow. Adding a report column may also require a data source, permission rule, export format and historical backfill. List dependencies that can change the estimate. A small visible interface change is not proof that the underlying implementation is equally small.

Assess cost and operational impact together

Break the estimate into development, configuration, testing, migration, third-party charges and recurring effects where relevant. Specify units, assumptions, exclusions and validity. Do not bury a new monthly dependency inside a one-time total. Compare the revised project baseline with the original so the cumulative effect remains visible.

NIST's configuration-management guidance treats security as part of managing system changes. Apply that principle by checking authorization, data handling, logging and recovery consequences before approval. A change may be commercially small yet alter who can see sensitive records or whether an old version can still read the data.

Approve a version and close against evidence

Record the authorized approver, decision date and exact proposal version. If price or scope changes afterward, obtain a new decision under the agreed process. Preserve rejected or deferred requests so the team does not later implement an old discussion as if it were approved.

Close the request through its acceptance criteria and record any remaining exceptions. Update the configuration record, support instructions and operating cost forecast. Whole-life procurement analysis, as discussed in the UK Government Sourcing Playbook, is relevant when a change adds continuing obligations. The playbook is a methodological reference here, not a universal legal contract template.

Worked example: a report change with a recurring dependency

A fictional request adds a reconciled settlement-currency column. The accepted estimate includes six development hours at $80 and three test hours at $60: $480 + $180 = $660 one-time. A separate data service would add $25 monthly and remains unapproved. The team approves only a version that uses an existing source; it does not assume the unapproved subscription is included in $660.