In projects, “requirementsRequirements that may lead to changes” and “changes” are often mixed, even though they represent two different perspectives on the same target state. Requirements define the future state of a system or process. They describe what must be present in the target solution, regardless of the current as‑isRepresentation of the current state situation. Changes, on the other hand, define the deviation from the as‑is state — the concrete adjustment needed to reach or modify the target state. This distinction is essential because it separates the functional definition of the target state from the technical or organizational work required to achieve it.

1.1. Requirements as the Definition of the Target State

A requirement describes what a system must deliver in the target solution. It typically emerges in early project phases and is solution‑neutral. Requirements define scope, functional expectations and the criteria that will later be accepted in the UAT. They are not reactive but planning‑oriented. A requirement such as “The system must support four languages” describes only the target state, not the work needed to reach it.

1.2. Changes as Adjustments to the As‑Is State

A changeAny planned or approved change to a system, process, or organizational unit—whether technical, organizational, or procedural. always arises from the difference between the as‑is state and the target state. If a system already supports Russian and Spanish but the target solution requires four languages, the change consists of adding English and French. The change is therefore the concrete adjustment of the as‑is state, not the abstract definition of the target state. Changes arise from new insights, technical constraints, regulatory requirements or defects and have direct impact on timeline, budget, testing and cutover(i) Phase of the 5-phase model: Execution of the production transition; includes technical switchover and operational implementation. (ii) Selective transition of a project to the production environment. (iii) Production transition phase of an IT system, often under time pressure and requiring high coordination..

The User Acceptance Test (UAT) is the acceptance of the target state. It does not test the change itself, but the result of the change. Even if the system already supported Russian and Spanish, these languages must be tested again in the UAT because the UAT accepts the complete target state. The UAT therefore tests not only the new languages English and French, but all four languages, since the requirement defines four languages. The UAT is not a change test but a requirement test. It confirms that the target state has been fully achieved — regardless of how many changes were required.

2.1. Regression as an Integral Part of UAT

Retesting existing functionality is a logical consequence of target‑state acceptance. Any change can affect existing functionality, whether through new configurations, new data models, new UI elements or new translation logic. The UAT does not test history; it tests the target state — and this target state includes all functionality, not only the changed parts.

Requirements define the target state, but they do not generate work. Only the deviation from the as‑is state — the change — generates effort, resource needs, timeline impact and budget. Therefore, projects do not plan “requirements”; they plan “changes.” Project planning answers the question: “What must we do to reach the target state?” And this question can only be answered based on changes, not requirements.

In classical PMI logic, a change request is a modification of the approved scope. PMI views changes exclusively as scope changes and does not differentiate between requirement changes and solution changes. For PMI, every change is a modification of project scope, regardless of whether it is triggered by new functional requirements, technical constraints, regulatory demands or defects. This perspective is sufficient for traditional project managementResponsible for the overall coordination, planning, and strategic management of the project. but does not reflect the complexity of modern solutions.

In real projects, there is no linear relationship between requirements and changes. It is always an n:n relationship: one requirement can generate multiple changes, and one change can affect multiple requirements. A requirement may require no change if the as‑is state already matches the target state. A change may arise without a requirement, for example due to regulatory demands or defects. Requirement‑to‑change mapping makes these relationships visible and provides the foundation for making changes traceable, testable and governable.

The mapping shows which concrete changes are necessary to implement a requirement and which requirements are affected by a change. It forms the basis for impact analysis, test planning and cutover evaluation. Without mapping, the connection between target state and as‑is adjustments remains invisible — and so do risks, dependencies and regressions.

In ITILFramework for IT Service Management with defined processes., the Change Advisory Board (CAB)Governance body responsible for evaluating and approving changes—particularly those relevant to productivity or security. is intended to evaluate changes — the deviations from the as‑is state needed to reach or adjust the target state. In practice, however, CAB meetings often present requirements instead of changes. The CAB then discusses functional target definitions, even though it should evaluate the impact of concrete changes. The reason is simple: requirement‑to‑change mapping is rarely performed. When it is unclear which changes arise from a requirement, the CAB has no choice but to evaluate the requirement itself.

As a result, the CAB loses its actual function as a solution‑change governanceStructured management and decision-making logic for the cutover, including roles, rules, and communication channels. body and becomes a scope‑review board — similar to classical PMI logic. Risks, dependencies, regressions and cutover impacts remain invisible because the changes were not explicitly documented.

The Change Governance Matrix (ChGM)(i) Strategic management tool for recording, evaluating, and approving changes—including RACI logic and relevance dimensions. (ii) Framework for managing change domains separates these layers clearly. It treats requirements as the definition of the target state and changes as deviations from the as‑is state. Only through requirement‑to‑change mapping does it become visible which concrete changes are necessary to implement a requirement and what impacts these changes have. The CAB then evaluates not the requirement but the changes arising from it. The ChGM provides the structure that PMI and many classical project methods lack. It operationalizes the connection between target state and as‑is adjustments and makes the n:n relationship between requirements and changes transparent.

Requirements define the target state. Changes define the deviation from the as‑is state. Project planning focuses on changes because they represent the actual work. UAT tests requirements because it accepts the target state. PMI views changes as scope changes and does not differentiate between requirement changes and solution changes. The Change Governance Matrix (ChGM) goes further: it governs changes at solution level and uses requirement‑to‑change mapping to make the n:n relationship between target state and as‑is adjustments transparent and manageable. This enables the CAB to fulfill its intended role: evaluating and governing changes at solution level.

The change governance matrix is available (i) as a digital product for download and (ii) is described in the book on “SAP Cutover Management“, written by Guido Nageldinger.