Delivery Approaches, Change and Configuration Control

Introduction

Software quality is not created only through testing at the end of a project. It is built into the way work is planned, developed, reviewed, changed, integrated and released. Delivery approach strongly influences how quality and risk are managed. A predictive project may define most requirements early and control changes through formal approval. An Agile project expects learning and change, using short delivery cycles, continuous feedback and a prioritised backlog. A hybrid project combines elements of both.

Regardless of the approach, every software project must answer four practical questions:

1. What product or increment is being delivered?
2. How will the team know that it is acceptable?
3. How are changes evaluated, approved and implemented?
4. How can the organisation identify exactly which versions of products, documents and components were used?

Version control, configuration management, change control and release readiness provide the operational discipline needed to answer these questions. They reduce accidental overwriting, uncontrolled scope growth, incompatible components, untraceable decisions and releases that are technically complete but operationally unsafe.

This chapter explains how quality and risk practices can be integrated into predictive, Agile and hybrid delivery. It also shows how configuration items, baselines, change requests, approval authorities, automated pipelines and release criteria work together.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish predictive, Agile and hybrid delivery approaches;
• integrate quality assurance and risk management into each approach;
• explain version control, configuration management and baselines;
• design a proportionate change-control process;
• distinguish corrective, adaptive, perfective and preventive changes;
• apply traceability from requirements through code, tests and releases;
• define practical release-readiness criteria;
• evaluate governance, security and ethical issues in software delivery; and
• recommend an appropriate delivery and control approach for a project context.

1. Delivery Approaches and Their Quality Implications

1.1 Predictive delivery

In a predictive approach, major scope, schedule and technical decisions are planned before implementation. Work commonly proceeds through sequential or overlapping phases such as requirements, design, construction, integration, testing and deployment. A baseline represents an approved version of scope, schedule, requirements or design against which performance and change can be assessed.

Predictive delivery is useful when requirements are relatively stable, contractual obligations are detailed, regulatory evidence is important, or physical and organisational dependencies make frequent change expensive. Its strengths include visibility of the intended end state, formal approval points and structured documentation. Its weaknesses include delayed feedback, the risk that incorrect assumptions remain undiscovered, and the possibility that a change-control process becomes slow or bureaucratic.

Quality activities in predictive projects include requirements reviews, architecture assessments, design inspections, test planning, formal verification, audit trails and stage-gate approvals. Risk management is often integrated into planning through a risk register, quantified or qualitative assessments, planned responses and periodic reviews.

1.2 Agile delivery

Agile delivery develops and evaluates software in short, repeated cycles. A product backlog contains desired outcomes, features, technical work, defects and other items. The team selects a manageable set of work for an iteration or sprint, produces a potentially usable increment, obtains feedback and reprioritises future work.

Agile does not mean that planning, documentation, quality or control are unnecessary. Instead, these activities are performed continuously and at an appropriate level of detail. Quality is supported by acceptance criteria, a Definition of Done, peer review, automated tests, continuous integration, exploratory testing and frequent demonstrations.

Agile is particularly effective when requirements are uncertain, users can provide regular feedback, and the organisation can release incrementally. Risks include inadequate architectural attention, excessive technical debt, weak documentation, unstable priorities and the assumption that self-organising teams require no governance.

1.3 Hybrid delivery

Hybrid delivery deliberately combines predictive and Agile practices. For example, a programme may use predictive governance for budget, procurement, regulatory approvals and high-level architecture while using Agile iterations for software development. Alternatively, a product may use a predictive release roadmap but Agile discovery and development within each release.

Hybrid delivery is not simply a compromise. It should be designed around the sources of uncertainty and the cost of change. Stable external constraints may be managed predictively, while uncertain product functionality is explored iteratively. The danger is creating two incompatible systems: formal governance that is disconnected from team work, or Agile ceremonies that provide little evidence for organisational decisions.

1.4 Comparative view

2. Integrating Quality and Risk Across Delivery Approaches

Quality management has three related dimensions. Quality planning defines standards, methods, roles and acceptance criteria. Quality assurance evaluates whether the project processes are suitable and followed. Quality control examines deliverables and identifies defects or nonconformities. In modern software practice these activities overlap and occur throughout delivery rather than only at a final test phase.

Risk management is also continuous. A risk is an uncertain event or condition that may affect objectives. A realised risk becomes an issue. Teams should identify risks, assess their probability and impact, plan responses, assign owners and monitor triggers. Common responses are avoid, mitigate, transfer and accept. Opportunities may be exploited, enhanced, shared or accepted.

2.1 Predictive integration

A predictive project may establish a quality management plan containing:

• applicable standards and contractual requirements;
• review and approval responsibilities;
• requirements traceability expectations;
• test levels and entry and exit criteria;
• configuration and document-control rules;
• defect classification and escalation rules; and
• audit and reporting arrangements.

Risks should be linked to work packages and milestones. For example, the risk of an unavailable external interface may lead to a mitigation involving an early technical spike, a test stub and a contingency schedule. Quality reviews should occur before major commitments, not only after implementation.

2.2 Agile integration

In Agile work, quality and risk are distributed across the workflow. A backlog item should be sufficiently understood before selection, include acceptance criteria, and meet the team’s Definition of Ready where such a practice is used. During implementation, developers and testers collaborate rather than treating testing as a separate final phase. The Definition of Done can require code review, automated tests, security checks, documentation updates and successful integration.

Risk items can be placed visibly in the backlog. A high-risk architectural assumption may be addressed before lower-risk features. Technical debt should be made visible and prioritised rather than hidden. Product demonstrations provide evidence of product value, while retrospectives provide evidence about process quality.

2.3 Hybrid integration

A hybrid project should define which controls are universal and which are adapted. Universal controls may include identity and access management, secure code handling, production approval, incident response and legal compliance. Adapted controls may include the level of documentation, approval thresholds, iteration length and release frequency.

A useful governance principle is that control should be proportionate to risk. A minor text correction in a low-risk internal tool should not require the same approval as a change to financial calculations, safety logic or personal-data processing. However, proportionality must not be used to bypass mandatory security, privacy or regulatory controls.

3. Version Control and Configuration Management

3.1 Version control

Version control is the systematic recording of changes to files or other managed artefacts. It allows authorised users to identify who changed an item, what changed, when it changed and, where supported, why it changed. It also permits recovery of earlier versions and supports parallel development.

A repository may contain source code, infrastructure definitions, database scripts, test assets, configuration templates, documentation and build instructions. Binary files and externally hosted components require particular attention because they may not merge easily or may change without an obvious source-code diff.

Common version-control concepts include:

• Commit: a recorded set of changes.
• Branch: an independent line of development.
• Merge: combining changes from different lines of development.
• Tag: a named reference to a particular version.
• Pull or merge request: a proposed change submitted for review.
• Repository: a managed store containing project history and related metadata.
• Protected branch: a branch subject to rules such as review or successful checks.

A simple and effective practice is to keep changes small, coherent and traceable. Commit messages should identify the purpose of the change and, where appropriate, reference a requirement, defect or approved change record.

3.2 Configuration management

Configuration management is the discipline of identifying, documenting, controlling and auditing the functional and physical characteristics of a product and the items needed to build, test, operate and maintain it. It is broader than source-code version control.

A configuration item is an artefact placed under configuration control. Examples include requirements specifications, source files, test scripts, compiled packages, database schemas, cloud infrastructure definitions, operating procedures, interface contracts, security rules and release notes.

The principal configuration-management activities are:

1. Configuration identification: determine which items require control and define naming and numbering conventions.
2. Configuration status accounting: record the identity, state and history of configuration items.
3. Configuration control: ensure that changes are evaluated, authorised, implemented and verified.
4. Configuration verification and audit: confirm that the product contains the approved items and that records are accurate.

3.3 Baselines

A baseline is an approved reference point. Examples include an approved requirements baseline, architecture baseline, test baseline or release baseline. A baseline is not necessarily immutable; it may be changed through authorised control procedures. Its purpose is to make the state of the product and its governing information explicit.

A release baseline might identify:

• application version;
• source revision or tag;
• dependency versions;
• database migration level;
• infrastructure definition revision;
• configuration values and secrets-management references;
• test evidence;
• known defects and accepted limitations; and
• rollback or recovery instructions.

3.4 Traceability

Traceability connects needs to implementation and evidence. A typical chain is:

Requirement → design element → code change → test case → test result → release record.

Traceability supports impact analysis, defect investigation, auditability and confidence that important requirements have been verified. It need not mean that every document is linked manually in a large matrix. Automated links among backlog tools, repositories, test systems and deployment records can provide efficient evidence, provided that the links are reliable and maintained.

4. Change Control

4.1 The purpose of change control

Change control prevents uncontrolled modification while allowing valuable change to occur. It is not intended to reject all change. Its purposes are to understand consequences, obtain appropriate authority, coordinate affected parties, preserve traceability and verify the result.

Changes may be classified as:

• Corrective: removes the cause of a detected defect.
• Adaptive: modifies the product for a changed environment, such as a new operating system or regulation.
• Perfective: improves performance, usability or maintainability without correcting a failure.
• Preventive: reduces the likelihood of future defects or failures.
• Emergency: requires accelerated treatment because delay creates unacceptable harm or exposure.

4.2 A proportionate change process

A practical change process contains the following steps:

1. Log the request. Record the requested change, source, reason and urgency.
2. Clarify the need. Define the desired outcome and acceptance conditions.
3. Assess impact. Consider scope, architecture, security, privacy, quality, schedule, cost, operations, suppliers and other requirements.
4. Recommend a decision. Approve, reject, defer, request more information or process as an emergency.
5. Authorise the change. The person or group with suitable authority makes the decision.
6. Plan and implement. Update affected plans, backlog items, code, tests and documentation.
7. Verify. Confirm that the change works and has not introduced unacceptable regression.
8. Close and communicate. Record the result, update baselines and inform affected stakeholders.

The decision authority should match the risk. A product owner may prioritise a normal backlog item, while a change-control board or technical and security authority may be required for a production change affecting regulated data.

4.3 Change control in Agile

In Agile, a change to an unstarted backlog item is usually handled through prioritisation. A change to work already in progress may require renegotiation of the iteration goal, cancellation or splitting of work. A change to a completed increment may become a new backlog item unless it is a production incident or urgent defect.

Agile change control therefore relies on transparency and explicit policies rather than assuming that no control exists. Useful policies define who may alter priorities, how urgent work enters an iteration, what happens to unfinished work, and which production changes require additional approval.

4.4 Impact analysis

Impact analysis should be evidence-based. Questions include:

• Which requirements and stakeholders are affected?
• Which modules, interfaces and data structures may change?
• What tests must be added or repeated?
• Does the change alter security, privacy or legal obligations?
• Does it affect performance, resilience, accessibility or supportability?
• Are suppliers, contracts or operational procedures affected?
• What is the rollback or recovery method?

A change that appears small in source code may be large in operational impact. For example, changing a customer identifier can affect databases, integrations, reports, data migration, privacy controls and support procedures.

5. Release Readiness

A release is a controlled introduction of a product version, configuration or capability into an environment. Release readiness is the judgement that the release can proceed with risks understood and acceptable controls in place. It is not identical to “all defects are fixed.” Some defects may be accepted if their impact is understood, documented and authorised.

A release-readiness checklist may include:

Readiness criteria should be measurable where possible. “The system is stable” is weak; “no open severity-one defects, required acceptance tests passed, and monitoring alerts verified” is more useful. Criteria must also identify who can approve an exception and how the exception is recorded.

6. Continuous Integration, Delivery and Deployment Controls

Continuous integration means that changes are integrated frequently and verified by automated or repeatable checks. Continuous delivery keeps software in a releasable state, while continuous deployment automatically releases qualifying changes to a target environment. These practices can improve feedback and reduce large integration events, but automation does not eliminate governance.

A delivery pipeline may include:

1. source validation and dependency checks;
2. compilation or packaging;
3. unit and component tests;
4. static analysis and security scanning;
5. integration and contract tests;
6. deployment to a test or staging environment;
7. acceptance, performance or exploratory testing;
8. approval or automated policy evaluation; and
9. controlled production deployment with monitoring.

The pipeline itself is a configuration item. Its rules should be versioned, reviewed and protected. Secrets should not be stored in source code. Build outputs should be identifiable and, where appropriate, signed or stored in a trusted repository. Dependency versions should be controlled because an apparently unchanged application can change when an unpinned external dependency changes.

Deployment strategies such as blue-green deployment, canary release and feature toggles can reduce exposure. They also introduce operational complexity. Feature toggles require ownership, testing of both paths and removal plans; otherwise they become hidden configuration debt.

7. Case Study: A Hybrid Digital Benefits Service

The following is an illustrative case.

Background

A public-sector organisation is replacing a legacy benefits application. The programme has a fixed legal compliance date and a contracted budget, but user needs and service workflows are still being discovered. The programme therefore adopts a hybrid approach. Regulatory requirements, security controls, procurement milestones and the target date are managed predictively. User-facing functionality is developed in two-week Agile iterations.

Problem

After four iterations, the team proposes changing the customer identity model. The original design used a locally generated identifier, but integration testing shows that several partner agencies use a national identifier. The change may improve interoperability but could affect privacy, data migration, reports, interfaces and test data.

Analysis

The product owner logs the request and the technical lead performs an impact analysis. The security and privacy specialists identify that the national identifier is more sensitive personal data than the local identifier. The team identifies affected configuration items: data model, interface contract, migration script, access-control rules, privacy assessment, test fixtures, user guidance and operational reports.

The change is classified as adaptive and high impact. It cannot be handled merely as a reprioritised user story because it affects the approved architecture and compliance evidence. The change authority approves investigation first, subject to a privacy design review and a migration rehearsal.

Approach and solution

The team creates a short technical spike and updates the architecture decision record. It uses tokenised test values rather than real identifiers in non-production environments. Database migration is tested against a representative copy of data. Contract tests are added for each partner interface. The release plan is adjusted, but the legal deadline is preserved by deferring a lower-value reporting feature.

The release baseline records the application tag, migration version, interface contracts, pipeline result, privacy approval, known limitations and rollback procedure. A staged deployment is used, beginning with a small operational group. Monitoring confirms that records reconcile correctly, and the deployment is expanded.

Outcome

The change is delivered without a critical incident. The project avoids treating the request as a local code modification and instead recognises its broader configuration, privacy and operational consequences. The deferred report is scheduled for a later increment through normal backlog prioritisation.

Learning points

• Hybrid delivery requires explicit boundaries between flexible and controlled decisions.
• A small-looking data change can have extensive configuration and risk impact.
• Privacy analysis should occur before implementation, not after deployment.
• Traceability links technical decisions to evidence and approvals.
• Release readiness includes operational and governance evidence, not only passing tests.

8. Challenges, Limitations and Governance

8.1 Excessive bureaucracy

Heavy approval systems can delay valuable work and encourage informal workarounds. The response is not to remove control but to simplify low-risk paths, automate evidence collection and reserve formal boards for changes with material consequences.

8.2 False confidence from automation

A green pipeline proves only that defined checks passed under defined conditions. It does not prove that requirements are correct, users will understand the product, security is perfect or operational conditions will match the test environment. Human review, exploratory testing and production monitoring remain important.

8.3 Configuration drift

Configuration drift occurs when an environment differs from the approved or recorded state. Infrastructure as code, environment comparison, immutable artefacts and regular audits reduce this risk. Manual production changes should be exceptional, recorded and reconciled with the managed configuration.

8.4 Emergency changes

Emergency changes may be necessary to address active security incidents, severe outages or legal exposure. They should use an expedited route, not an undocumented route. The change should still have an owner, an assessment, a record, verification and a retrospective review.

8.5 Security, privacy and ethical responsibilities

Access to repositories and deployment systems should follow least privilege and separation of duties appropriate to the risk. Audit logs should be protected from unauthorised alteration. Personal data should be minimised, protected and used only for legitimate purposes. Teams must consider accessibility, discrimination, explainability and the effect of defects on vulnerable users.

AI-assisted coding and automated code-generation tools can improve productivity but create risks involving insecure suggestions, licence incompatibility, confidential-data exposure, fabricated dependencies and unclear authorship. Generated code must undergo the same review, testing, security assessment and configuration control as human-written code. Organisations should define acceptable-use rules and retain responsibility for the released product.

9. Best-Practice Guidance

A certificate-level practitioner should be able to apply the following practices:

1. Choose the delivery approach based on uncertainty, regulation, dependencies and cost of change.
2. Define quality and release criteria before implementation begins.
3. Keep requirements, code, tests, environments and releases traceable.
4. Place all important configuration items under appropriate control.
5. Use small, reviewable version-control changes and protect critical branches.
6. Make risk and technical debt visible rather than hiding them in informal work.
7. Match approval effort to risk while preserving mandatory controls.
8. Automate repeatable checks, but do not treat automation as complete assurance.
9. Record exact release contents, dependencies and configuration.
10. Prepare rollback, recovery and communication plans before production release.
11. Review emergency changes after the immediate risk has been controlled.
12. Measure outcomes such as escaped defects, failed deployments, recovery time and change lead time, while interpreting metrics in context.

Chapter Summary

Predictive, Agile and hybrid delivery approaches differ mainly in how they plan, learn and control change; none removes the need for quality or risk management. Predictive projects emphasise baselines and formal approval, Agile projects integrate quality into frequent increments and backlog decisions, and hybrid projects allocate different controls to stable and uncertain work.

Version control records changes to managed files, while configuration management governs the broader set of artefacts required to build, test, operate and support a product. Baselines provide approved reference points, and traceability connects requirements to implementation and evidence. Change control evaluates consequences, assigns authority and verifies that approved changes are correctly implemented. Release readiness requires functional, security, operational, configuration, governance and recovery evidence. Automation strengthens these practices when its rules are controlled and its limitations understood. Effective practitioners apply proportionate governance, protect privacy and security, and maintain accountability for every released product.

Key Terms

Configuration item: An artefact placed under configuration control.

Configuration management: The discipline of identifying, controlling, recording and auditing product configurations.

Baseline: An approved reference version used for comparison and control.

Version control: Recording and managing successive changes to files or artefacts.

Repository: A managed store containing versions and related metadata.

Branch: An independent line of development in a version-control system.

Merge: Combining changes from separate development lines.

Traceability: The ability to relate requirements, implementation, tests and release evidence.

Change control: The process for evaluating, authorising, implementing and verifying changes.

Change request: A documented proposal to modify an approved product, plan or baseline.

Corrective change: A change that removes the cause of a detected defect.

Adaptive change: A change made to accommodate a changed environment or requirement.

Technical debt: The future cost created by expedient technical decisions or postponed improvement.

Release baseline: The recorded set of product and configuration items authorised for release.

Release readiness: A judgement that a release can proceed with acceptable understood risk.

Continuous integration: Frequent integration of changes supported by repeatable verification.

Continuous delivery: Keeping software in a releasable state through automated and controlled practices.

Configuration drift: Unplanned divergence between an environment and its recorded configuration.

Definition of Done: Shared criteria that work must satisfy to be considered complete.

Impact analysis: Assessment of the consequences of a proposed change.

Review Questions

Short Answer Questions

1. What is the main purpose of a configuration baseline?
2. How does version control differ from configuration management?
3. Identify two quality practices commonly used in Agile delivery.
4. What is configuration drift?
5. Why should release readiness include rollback or recovery planning?

Long Answer Questions

1. Compare predictive, Agile and hybrid delivery approaches in relation to quality and risk management.
2. Explain the stages of a proportionate change-control process.
3. Describe how traceability supports defect investigation, auditability and release confidence.
4. Explain how continuous integration and delivery can improve quality while still requiring governance.
5. Discuss the ethical, privacy and security responsibilities associated with configuration and release control.

Analytical / Application Questions

1. A team wants to change a database identifier two days before release. Explain the impact-analysis questions, approval route and evidence you would require before deciding whether to proceed.
2. A project has formal approval gates, but its development team works in short iterations. Design a hybrid quality and change-control arrangement that avoids both uncontrolled change and excessive bureaucracy.
3. A production deployment passed all automated tests but caused incorrect customer notifications. Analyse how version control, configuration management, release readiness and monitoring could be improved to reduce recurrence.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes configuration management from version control?

A. Configuration management applies only to source code, while version control applies to documents.

B. Configuration management covers controlled product artefacts and their relationships, while version control records changes to managed items.

C. Configuration management is used only after deployment, while version control is used only before coding.

D. Configuration management eliminates the need for change approval.

Correct Answer: B. Configuration management covers controlled product artefacts and their relationships, while version control records changes to managed items.

Question 2

In an Agile project, what is the most appropriate way to handle a change to an unstarted feature?

A. Reject it because Agile projects cannot change scope.

B. Modify production code immediately without assessment.

C. Evaluate and reprioritise it through the backlog process.

D. Wait until the entire project is complete.

Correct Answer: C. Evaluate and reprioritise it through the backlog process.

Question 3

Which item is most appropriately included in a release baseline?

A. An informal conversation about a future feature

B. An unreviewed developer suggestion

C. The exact application version, dependency versions and migration level

D. Only the project budget forecast

Correct Answer: C. The exact application version, dependency versions and migration level

Question 4

A change that modifies software to operate with a newly mandated operating system is best classified as:

A. Adaptive

B. Corrective

C. Perfective

D. Preventive

Correct Answer: A. Adaptive

Question 5

What is the primary purpose of impact analysis?

A. To ensure that every change is rejected

B. To identify the likely consequences of a proposed change

C. To replace all software testing

D. To assign project salaries

Correct Answer: B. To identify the likely consequences of a proposed change

Question 6

Which practice most directly reduces configuration drift?

A. Allowing undocumented manual production changes

B. Using infrastructure as code and comparing environments with managed configuration

C. Deleting deployment records after release

D. Keeping configuration knowledge only in one employee’s memory

Correct Answer: B. Using infrastructure as code and comparing environments with managed configuration

Question 7

Which statement about automated pipelines is correct?

A. A successful pipeline proves that the product has no risks.

B. Pipeline rules do not need version control because they are operational only.

C. Automation provides repeatable evidence but does not replace all human judgement and governance.

D. Automated tests make rollback planning unnecessary.

Correct Answer: C. Automation provides repeatable evidence but does not replace all human judgement and governance.

Question 8

Which evidence is most relevant to operational release readiness?

A. A list of developers’ preferred programming languages

B. A tested recovery procedure, monitoring and support runbook

C. An unrelated marketing slogan

D. A discarded early design sketch

Correct Answer: B. A tested recovery procedure, monitoring and support runbook

Question 9

A high-impact change affects personal-data processing. Which additional consideration is most important?

A. Whether the commit message is short

B. Whether privacy and security obligations have been assessed and approved

C. Whether the change uses the newest programming language

D. Whether all low-priority features are complete

Correct Answer: B. Whether privacy and security obligations have been assessed and approved

Question 10

Why should an emergency production change still be recorded and reviewed afterwards?

A. To preserve traceability and learn whether controls or prevention should improve

B. To prevent the organisation from ever making emergency changes again

C. To avoid testing the emergency change

D. To convert every emergency into a budget request

Correct Answer: A. To preserve traceability and learn whether controls or prevention should improve