3 Change Approval and Implementation Control

Purpose and scope of change control

A change request proposes modifying an approved product, process, requirement, or project baseline. Change control ensures that each proposal is evaluated by the appropriate people, authorized at the appropriate level, clearly communicated, and implemented and verified without losing traceability.

The project should define its process and scale it to the change’s risk and scope. It should also specify which authority controls each baseline or item, the limits of that authority, and how requests outside those limits are escalated. Clear boundaries help avoid both unauthorized approval and unnecessary review at the highest level.

Decision roles and authority

Different roles contribute to a controlled decision. Their responsibilities should be clear so that assessment, approval, implementation, and verification are not confused.

• Requester (originator): Describes the problem or opportunity, proposed change, justification, and any known urgency or constraints.

• Change-control coordinator: Logs and screens requests for completeness, identifies the applicable approval authority, circulates review materials, and maintains the record.

• Technical assessors and affected stakeholders: Analyze impacts in their areas of expertise, such as requirements, design, interfaces, cost, schedule, operations, security, safety, and testing. They advise the decision-maker but do not necessarily approve the change.

• Change authority: A designated manager, board, or other authorized group—often called a Change Control Board (CCB)—makes the disposition within its assigned scope. Its membership should include the expertise and authority needed to judge the change.

• Implementer and verifier: The responsible team makes the authorized change. An appropriately assigned reviewer or test function checks that it was implemented correctly and that required records are updated.

From request to controlled closure

A practical workflow moves each proposal from submission to verified closure. The request should not be implemented before authorization, and approval alone does not establish that implementation is complete or ready for release.

1. Submit and log. Assign a unique identifier and record the originator, description, rationale, affected items, and requested timing.

2. Screen. Check that the request is understandable, complete enough to assess, within scope, and routed to the correct authority. Return incomplete requests for clarification.

3. Analyze impact. Assess expected benefits, alternatives, risks, and effects on relevant requirements, interfaces, dependent work, cost, schedule, quality, safety, security, testing, and documentation. Record assumptions and unresolved questions. The authority may perform the analysis or assign it to specialists.

4. Review and decide. Provide the authority with the request and analysis. Typical dispositions are approve, defer, or reject. Approval may specify conditions, responsibilities, timing, or verification requirements. Escalate requests that exceed the authority’s limits.

5. Authorize before implementation. Record the decision and required actions. Approval permits work to proceed under the stated controls; it does not by itself prove the change has been completed or is ready for release.

6. Implement, verify, and close. Make the approved change to the authorized items, update associated records, verify the result, and release it through the project’s controlled process. Close the request only when required implementation, verification, and documentation are complete.

Assessing connected impacts

For example, adding a required field to an online form could affect data storage, downstream reports, user instructions, and tests. Reviewers identify those impacts, and the designated authority approves, defers, or rejects the proposal. If approved, the team changes the form and affected components, updates documentation and tests, verifies the results, and records the released version against the request.

This example illustrates why impact analysis should consider connected work and why the change must be linked to the items it affects.

Communicating decisions

Notify the requester, affected teams, and relevant stakeholders promptly through the agreed tracking system or another controlled channel. Communicate the request identifier, disposition, decision date, rationale, approval conditions, assigned actions and owners, expected timing, and location of the authoritative record.

For a deferral, record when or what will trigger reconsideration. For a rejection, give the reason. Keep meeting minutes or decision records with the request so stakeholders can understand the decision later.

Implementation records and traceability

An approval record does not substitute for controlling the implementation. Link the authorized request to the specific requirements, designs, code, procedures, tests, or other items it affects. Use controlled repositories and release procedures so that changes are made to the correct versions and the approved baseline is updated only through authorized means.

Track implementation actions, verification evidence, release status, and any effects requiring follow-up. The change log, or an equivalent configuration-management system, should preserve a traceable history that includes:

• Unique request identifier and description.

• Requester and submission date.

• Impact analysis and supporting review comments.

• Decision, rationale, authority, and date.

• Assigned actions, owners, and status.

• Affected items and versions.

• Implementation and verification results.

• Release information and closure date.

A complete record connects what was proposed and decided with whether the authorized change was actually implemented and verified. Traceability across analysis, decision, implementation, verification, release, and closure helps protect the integrity of approved baselines.