• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Change is treated as an expected condition, not an exception

Purpose and Strategic Importance

This standard ensures that change is embraced as a normal and continuous part of digital delivery, not a disruption to be resisted. By treating change as an expected condition, teams can design systems, workflows, and mindsets that are adaptive, resilient, and focused on continuous evolution rather than rigid control.

It supports our policy to “Treat Change as a Constant” by embedding change-readiness into delivery culture and system architecture. Without this mindset, change becomes feared, delayed, or poorly managed—resulting in brittle systems, reactive teams, and missed opportunities for improvement.

Strategic Impact

  • Builds adaptive capacity into teams and systems
  • Encourages small, safe, frequent changes to reduce risk
  • Promotes continuous alignment with user needs and business goals
  • Reduces bottlenecks caused by fear of disruption
  • Improves resilience and responsiveness to market or operational shifts

Risks of Not Having This Standard

  • Change is delayed or avoided due to perceived risk
  • Teams become reactive rather than proactive
  • Business opportunities are missed due to delivery inertia
  • Rigid systems create technical debt and resistance to innovation
  • Morale suffers from repeated unplanned or disruptive change

CMMI Maturity Model

Level 1 – Initial

Category Description
People & Culture - Change is seen as disruptive or risky.
- Teams rely on fixed plans and resist adaptation.
Process & Governance - Change is heavily gated, slow, and often avoided.
- Processes are not built to accommodate continuous improvement.
Technology & Tools - Change processes are manual and inconsistent.
- Tooling lacks support for incremental delivery.
Measurement & Metrics - No visibility into the volume, impact, or frequency of changes.

Level 2 – Managed

Category Description
People & Culture - Change is acknowledged as necessary, but handled cautiously.
- Teams begin to adopt change management frameworks.
Process & Governance - Basic mechanisms to plan and track changes are in place.
- Larger changes are broken into smaller increments.
Technology & Tools - Source control and deployment automation start to support change.
Measurement & Metrics - Change count and some delivery metrics are tracked.

Level 3 – Defined

Category Description
People & Culture - Change is integrated into delivery practices and team mindset.
- Teams view change as a design constraint, not a disruption.
Process & Governance - Agile and iterative planning processes are used to accommodate change.
- Release cadences and planning incorporate frequent updates.
Technology & Tools - CI/CD pipelines enable regular, low-risk deployment.
Measurement & Metrics - Change volume, flow efficiency, and rework are measured.

Level 4 – Quantitatively Managed

Category Description
People & Culture - Change velocity and impact are monitored and used to improve adaptability.
- Teams use feedback loops to guide controlled change.
Process & Governance - Change is planned, implemented, and observed in small, safe batches.
- Delivery systems include built-in validation and rollback.
Technology & Tools - Tooling supports feature flags, progressive delivery, and telemetry.
Measurement & Metrics - Change frequency, stability, and customer impact are tracked.

Level 5 – Optimising

Category Description
People & Culture - Teams continuously improve how they handle change.
- Leaders and teams experiment safely to learn and improve.
Process & Governance - Change frameworks are adaptive and continuously refined.
- Emergent change is normalised across teams and programmes.
Technology & Tools - Intelligent tooling predicts risk and recommends optimal change windows.
Measurement & Metrics - Real-time metrics guide delivery prioritisation and change strategies.

Key Measures

  • Frequency of change per team or system
  • Lead time for change from idea to deployment
  • Change failure rate and rollback occurrence
  • % of changes delivered with no user disruption
  • Correlation between change volume and business value delivered
Associated Policies
Associated Practices
  • Small Batch Releases

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering