5.3 Change Control & Configuration Management

5.3 Change Control & Configuration Management

Change control cannot operate effectively without Configuration Management. While issue management provides the decision-making process for evaluating change, configuration management provides the underlying technical control that identifies, tracks, and safeguards products, ensuring that project teams always know which version of a deliverable is approved.

PRINCE2 7 Principle: Change control and configuration management go hand in hand. If you do not control product baselines, you cannot control change.

---

What is Configuration Management?

Configuration Management is the management practice responsible for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its lifecycle.

In PRINCE2 7, every deliverable (specialist product) and management artifact (management product) that requires version control is designated as a Configuration Item (CI).

The Four Core Functions of Configuration Management

1. Identification: Specifying products, assigning unique naming structures, defining product breakdown structures, and establishing version numbering schemes (e.g., Major.Minor.Patch format).
2. Control: Ensuring products are frozen and baselined upon formal sign-off, and enforcing that modifications occur exclusively via approved Requests for Change.
3. Status Accounting: Maintaining live records and generating reports on the location, state, author, owner, and version history of configuration items throughout the project.
4. Verification & Audit: Conducting systematic physical and functional reviews to confirm that physical assets or digital code matches the specifications documented in Configuration Item Records.

---

The Concept of Baselining

A Baseline is a cornerstone concept in PRINCE2 progress and change control.

PRINCE2 7 Definition: A Baseline is an approved version of a product or management document that can only be changed through formal change control procedures.

The Baselining Lifecycle Step-by-Step

• Draft Development (v0.1, v0.2...): Products are created and iteratively refined by technical teams or project authors. Edits occur freely without formal change board review.
• Quality Review & Baseline Sign-Off (v1.0): Once a product satisfies its Product Description quality criteria, it is formally signed off by designated reviewers and baselined (frozen).
• Proposed Change (v1.1 draft): If a stakeholder submits a Request for Change (RFC) and it is approved by the Change Authority, a new working version is checked out.
• Re-baselining (v2.0): Following implementation, testing, and quality verification of the change, the updated version is formally re-baselined as version 2.0.

[Draft Work: v0.1] ──> [Quality Review] ──> [BASELINED: v1.0] ──> [RFC Approved] ──> [Draft: v1.1] ──> [RE-BASELINED: v2.0]

---

Key Configuration Records & Management Products

PRINCE2 defines three primary management products to support configuration management:

1. Configuration Management Approach

Formulated during project initiation, this document specifies how configuration management will be executed, defining:

• Naming conventions, repository structures, and versioning schemes.
• Storage locations, cloud repository security, and role-based access rights.
• Roles responsible for configuration management (e.g., Configuration Librarian / Project Support).
• Audit schedules, verification criteria, and baselining procedures.

2. Configuration Item Record (CIR)

PRINCE2 7 Definition: A record that provides a detailed description of the status, version, location, relationships, and history of a specific Configuration Item.

For every tracked product, a CIR is maintained in the project's configuration management database (or digital tool). Key CIR fields include:

• Item Identifier & Name: Unique reference ID (e.g., CI-MODULE-PAYMENT-004).
• Current Version & Status: (e.g., In Development, Under Test, Baselined, Archived).
• Location / Repository Path: Digital URI or physical storage coordinates.
• Product Owner & Author: Designated technical leads and owners.
• Variant / Branch Information: Environment branch details (e.g., staging vs production).
• Relationships & Dependencies: Downstream components dependent on this item.
• History of Changes: Audit trail of previous baseline modifications and linked RFC IDs.

3. Product Status Account

PRINCE2 7 Definition: A report issued by Project Support summarizing the status of configuration items within a stage, release, or the entire project.

The Product Status Account answers critical management questions such as: "Which products scheduled for Stage 2 delivery have reached baselined status?" or "What outstanding Requests for Change currently impact Component B?"

---

Configuration Audits & Verification

Periodically, Project Assurance or an independent auditor conducts a Configuration Audit to verify that recorded records reflect physical reality:

1. Physical Audit: Checks that the physical assets, hardware items, or digital files listed in the Configuration Item Records actually exist in designated storage locations.
2. Functional Audit: Checks that the configuration items perform correctly and satisfy their specified requirements, security criteria, and operational standards as documented in their Product Descriptions.

---

Digital Integration & Agile Change Control

In modern PRINCE2 7 implementations, manual configuration logs are replaced by automated digital systems:

• Git Version Control: Commits, feature branches, and pull requests automatically update Configuration Item Records.
• Automated CI/CD Pipelines: Build pipelines automatically enforce quality checks, run unit tests, and freeze baseline releases upon successful build completion.
• Feature Toggles / Flags: Enable digital teams to deploy baselined code to production while dynamically enabling or disabling features without breaking baseline integrity.
• Digital Dashboards: Generate Product Status Accounts on demand directly from software repositories (e.g., Jira, GitHub, Azure DevOps).