Change Request Management on Salesforce Projects

The Agile-Governance Paradox: Control vs. Agility

Salesforce occupies a unique position in the enterprise software ecosystem. Its low-code/no-code capabilities, visual development tools, and robust platform architecture create a powerful value proposition: rapid delivery and immediate responsiveness to business needs. Business stakeholders, having observed an administrator drag and drop a custom field or configure an automated Lightning Flow in a live demonstration, frequently develop a dangerous illusion of frictionless change. They assume that because a modification can be made in minutes, it should be made immediately, directly within active sprints or even production environments, without the burden of formal governance.

For senior delivery practitioners, this illusion is the root cause of systemic project failure. In an enterprise Salesforce environment, a seemingly simple change rarely exists in isolation. A single custom field might be referenced in three Apex classes, two validation rules, a MuleSoft integration mapping, a Snowflake data warehouse pipeline, and several Tableau dashboards. Modifying that field without evaluating the downstream impact triggers a cascade of regression issues, data sync failures, and deployment blocks.

This creates the classic Agile-Governance Paradox:

• Too Much Control (The Bureaucratic Bottleneck): Implementing heavy, traditional IT change control boards that meet monthly and require forty-page impact documents destroys the very speed and agility for which the organisation purchased Salesforce. The business becomes frustrated, shadow IT flourishes, and the platform's value is lost.
• Too Little Control (The Cowboy Chaos): Allowing uncontrolled backlog creep, direct-to-production customisation, and undocumented architectural pivots results in a "spaghetti org." Technical debt accumulates exponentially, performance degrades, governor limits are breached, and future upgrades or enhancements become prohibitively expensive and risky.

To resolve this paradox, senior delivery leaders must move away from adversarial "scope policing" and establish a collaborative, guardrail-based governance model. The goal is to define clear, objective boundaries between "agile refinement" (which belongs in the standard sprint backlog under the Product Owner's authority) and "architectural change" (which requires formal technical triage and commercial evaluation). By standardising these boundaries, the programme can maintain delivery momentum while protecting the stability and integrity of the enterprise architecture.

Defining the CR Taxonomy: Classification and Thresholds

To prevent the governance process from becoming a bottleneck, a programme must establish a rigorous, objective taxonomy that classifies proposed modifications based on risk, effort, and system impact. Not every change request is a threat to the budget, and not every sprint adjustment can be absorbed without consequence.

The following three-tier taxonomy provides an operational framework for triaging change requests:

By codifying these thresholds, the Delivery Manager can immediately deflect minor requests from the Steering Committee, empowering the Product Owner to make rapid, localised decisions. Conversely, it ensures that any request that threatens the system's foundational architecture or the programme's key milestones is routed through a rigorous evaluation workflow.

The Zero-Ambiguity CR Evaluation Workflow

Once a modification is identified as exceeding the Class 3 threshold, it must enter a standardised, transparent evaluation lifecycle. Ambiguity is the enemy of delivery velocity; when the process for assessing changes is ill-defined, active sprints stall because key resources are pulled into unstructured meetings trying to "solve" the change on the fly.

A highly effective, zero-ambiguity workflow follows five strict phases:

1. Intake and Logging

Every proposed change must be formalised. The requester must submit the request to the Delivery Management Office (PMO) using a standardised Intake Form that captures: the business driver (e.g., regulatory compliance, operational efficiency, strategic pivot), a detailed description of the desired outcome, and the perceived urgency. The Delivery Manager immediately logs this in the programme's CR Register with a unique tracking identifier (e.g., CR-016).

2. Technical and Process Triage

Before any commercial or scheduling discussion occurs, the Lead Solution Architect and Lead Business Analyst must perform a technical triage. The Solution Architect evaluates the technical feasibility and architectural impact, specifically analysing:

• Governor Limit Headroom: Will this customisation push the org closer to platform execution limits (e.g., CPU timeout, heap size, concurrent API calls)?
• Data Model Integrity: Does the request align with standard Salesforce objects and relationships, or does it introduce unneeded custom objects?
• Security and Sharing: Does this require changes to the global Organisation-Wide Defaults (OWD), sharing rules, or the role hierarchy?
• Package and Dependency Boundaries: Will this modify metadata that is shared across multiple workstreams or packages?

3. Cost and Timeline Estimation

Once the technical approach is defined, the Delivery Manager facilitates the sizing exercise. This sizing must represent the Triple Constraint (scope, time, and budget) and cover all delivery workstreams: requirements elaboration, technical design, core build, regression testing, data migration, release coordination, and user training. Sizing should never be expressed as a single "developer build estimate" because build represents, at most, 40% of the total effort required to deploy a change successfully to production.

4. Governance Board Review

The completed impact assessment is presented to the appropriate governance body based on the CR classification. For Class 2 changes, this is the weekly project change board. For Class 1 changes, this is the SteerCo. The delivery team presents three distinct options to the decision-makers:

• Option A (Full Adoption): Accept the entire change, adjusting the commercial scope, budget, and timeline as required.
• Option B (The Tactically Optimised Path): Accept a simplified, low-customisation MVP of the change that delivers 80% of the value for 20% of the cost, minimising technical debt.
• Option C (Defer / Reject): Defer the request to a post-go-live phase or reject it entirely due to high risk or architectural alignment issues.

5. Schedulability and Release Planning

Once approved, the Delivery Manager schedules the change. Schedulability determines whether the change will be injected into the current release boundary (via a formal scope-swap or timeline extension) or queued in the product backlog for a subsequent release.

The Estimation Engine: Standardising CR Impact Assessments

To prevent the estimation process from distracting the development team from active sprints, senior delivery leaders must establish a structured "Estimation Engine." A common failure mode on Salesforce projects is that developers spend half their time estimating hypothetical changes instead of building active user stories.

To shield the core build team, the Delivery Manager should utilise Discovery Spikes. A spike is a time-boxed story (typically 4 to 8 hours) allocated in a sprint to an architect or lead developer to research a complex change, build a proof of concept, and formulate an accurate estimate. The rest of the development team continues executing the sprint scope without interruption.

Every medium-to-large Change Request must be documented in a Change Request Impact Assessment (CRIA). The CRIA is a highly analytical, five-page document that includes:

When calculating the cost of a CR, the Delivery Manager must estimate the Total Cost of Ownership (TCO), not just the build hours. TCO includes:

• Data Migration & Cleansing: Custom fields or new objects require historical data backfilling and cleansing.
• Regression Testing Tax: Custom code and complex Flows require ongoing maintenance. As Salesforce delivers three major platform releases per year, every piece of customisation must be tested and maintained indefinitely.
• User Adoption and Change Management: Training materials, quick reference guides, and delivery of training sessions to affected users.
• Licence Costs: Does the change require upgrading user licences (e.g., from Salesforce Platform to Service Cloud Enterprise) or purchasing new add-on licences?

Maintaining Sprints: Sprints as Sacred Delivery Boxes

Once the governance board approves a change, the final hurdle is injecting it into delivery without derailing momentum. The single biggest threat to team morale and delivery velocity is "mid-sprint disruption." When a Delivery Manager allows stakeholders to inject new requirements into an active sprint, the team is forced to halt current tasks, switch context, re-estimate, and re-test. This behaviour systematically destroys predictability and introduces severe quality defects.

To protect the delivery velocity of the programme, the Delivery Manager must enforce two fundamental rules:

Rule 1: The Scope-Swap Rule

The "Scope-Swap" rule is non-negotiable for any approved Class 2 or Class 1 change that must be delivered within the current release timeline without extending the go-live date. If a new Change Request representing 20 Story Points is injected into the release scope, the Delivery Manager and Product Owner must identify and remove lower-priority backlog items representing exactly 20 Story Points from the active release boundary.

This discipline forces the business to acknowledge a simple physical reality: a development team has a finite capacity (velocity). You cannot add volume to a fixed-size container without removing something else, or purchasing a larger container (extending the timeline and budget).

Rule 2: Sprints are Sacred

An active sprint is a locked delivery box. Under no circumstances should an approved Change Request be injected mid-sprint, unless it is a critical production blocker that halts all progress. All approved Class 2 changes must be queued in the product backlog and scheduled for a subsequent sprint. This protects the developers and QA engineers from disruptive context-switching and ensures they can deliver on their sprint commitments.

For senior delivery leaders, managing change is not about saying "no" to the business; it is about providing clear, structured visibility into the real cost, risk, and timeline trade-offs of their decisions. By establishing a robust change request management process, you can ensure your Salesforce programme delivers the agility the business expects, with the professional controls and quality assurance the organisation demands.