Managing Scope Creep on Salesforce Programmes

The Psychology and Mechanics of Salesforce Scope Creep

Scope creep is the slow, continuous expansion of a project's boundaries beyond the originally agreed-upon commercial and technical limits. While it affects all custom software engineering projects, Salesforce implementations are uniquely vulnerable to this phenomenon. The primary driver of this susceptibility is the **declarative paradox**. Because Salesforce is a low-code/no-code platform, business stakeholders and delivery managers operate under the illusion that configuration is instantaneous and free. When they request a new custom field, a modified page layout, or an automated screen flow, they assume it can be completed in minutes, ignoring the complex metadata dependencies, regression testing requirements, and governance limits that underpin the change.

The second major driver of scope creep is **requirement abstraction**. During the initial discovery workshops, requirements are often captured at a high level of abstraction (e.g. "We need to manage customer onboarding"). Stakeholders sign off on these broad concepts, but as the project progresses and they see live functional prototypes during sprint demonstrations, they begin to conceptualise the precise operational workflows they actually desire. Each " Show and Tell" session triggers a cascade of reactive requests, such as "Can we automate this email?", "Can we integrate this third-party service?", or "Can we add another approval step?" These requests are rarely framed as scope extensions; instead, stakeholders argue they are merely "clarifying" the original abstract requirement, making it exceptionally difficult for delivery leaders to hold the line.

Furthermore, Salesforce's extensive **AppExchange ecosystem** and built-in features create a state of constant temptation. Business leaders attend Salesforce marketing events or read product documentation and immediately want to adopt the latest AI, analytics, or collaborative tools. They push the delivery team to incorporate these complex platform capabilities mid-stream, without understanding that a secure enterprise rollout requires detailed security reviews, data architecture planning, and licensing compliance checks. This "shiny object syndrome" distracts the delivery team from core objectives, introducing massive integration risk and destabilising the core release branch.

Finally, a primary driver of scope creep is the **lack of architectural ownership** within the business. Business sponsors often fail to appoint a strong internal product owner who can act as a single point of contact and filter stakeholder demands. Instead, a multi-headed stakeholder committee bombards the delivery team with conflicting, unprioritised requirements. The delivery team, eager to satisfy their clients or business sponsors, attempts to accommodate every request, leading to customisation bloat and architectural compromise. To protect platform health and maintain delivery momentum, we must implement a structured, authoritative governance gate to evaluate every single incoming change.

Establishing a Solution Design Authority Gate

The most effective defence against scope creep is the establishment of an independent, authoritative governance body: the **Solution Design Authority (SDA)**. The SDA is comprised of the lead program architect, lead business analyst, and the client's internal platform owner. This body acts as the ultimate gatekeeper for all functional and technical customisations, ensuring that no change is introduced into the backlog without a formal review of its business value, technical complexity, and alignment with Salesforce best practices.

The SDA evaluates every proposed change against a rigid **technical evaluation matrix**. The first filter is the **Declarative vs Custom Code test**. If a business requirement can be met using standard, out-of-the-box Salesforce capabilities or standard declarative configuration, the SDA will approve the approach. If the request requires custom programmatic development (such as custom Apex triggers or Lightning Web Components), the requester must present a comprehensive business case justifying why standard capabilities are insufficient. This immediate friction discourages low-value customisation requests, forcing business units to adapt their processes to the platform's standard design rather than bending the platform to match legacy habits.

The second filter is the **Platform Governance and Limits audit**. The SDA reviews the proposed change's impact on platform governor limits, sharing architectures, integration middleware, and release environments. For instance, if a team proposes adding a complex real-time integration to an Opportunity edit trigger, the SDA will audit the impact on Apex CPU transaction limits and sharing calculation locking behaviour. By identifying these downstream architectural risks early, the SDA prevents high-risk customisations from corrupting the core system, protecting the long-term stability and upgradeability of the platform.

To ensure operational efficiency, the SDA operates with a clear **delegated authority framework**. Minor declarative modifications (such as updating a picklist value or adjusting a standard list view) are delegated to the business analysis team for immediate approval. Medium and high-complexity requests (such as altering the sharing model, introducing custom objects, or creating custom integrations) require a formal review session where the technical leads debate the design, evaluate the alternatives, and document the final decision in an Architectural Decision Record (ADR). This structured process ensures that major technical choices are made deliberately, transparently, and with full accountability.

Implementing Fixed-Capacity Agile Frameworks

In traditional project management, delivery leaders attempt to manage scope creep using rigid Waterfall change request processes. While this provides commercial protection, it often creates a highly combative, slow-moving program culture where the business feels ignored. To combine commercial guardrails with agility, modern delivery leaders should implement a **Fixed-Capacity, Managed-Scope Agile framework**.

Under this delivery framework, the program commercial boundaries are locked using a **Fixed-Capacity model**. The delivery vendor commits to providing a stable, cross-functional delivery team (e.g. one architect, three developers, two configurators, two business analysts, and a QA specialist) for a set number of two-week sprints. The total program budget and launch date are completely fixed, providing the predictable boundaries demanded by corporate procurement and financial audits. However, the functional scope within this container remains flexible, managed dynamically sprint-by-sprint.

The core mechanism of managed scope is the **Scope Exchange agreement**. When business stakeholders identify a new, high-value requirement mid-program, the delivery manager does not immediately refuse the request or initiate a complex change request process. Instead, they present the stakeholder with the current backlog and state: "We can build this new feature in Sprint 8, but to accommodate it within our fixed capacity, we must remove an equivalent volume of existing scope from the launch backlog." This simple exchange immediately shifts the psychological dynamic, converting a combative debate into a collaborative prioritization exercise where the business must directly evaluate the relative value of their requests.

To support this dynamic, user stories must be estimated using consistent, objective units (such as story points or T-shirt sizes) that represent relative technical complexity and effort. The delivery team's historical velocity (the average number of story points delivered per sprint) acts as the ultimate capacity boundary. If the team's velocity is 40 points, the product owner cannot load 60 points of scope into the sprint backlog. By keeping the capacity locked and enforcing the scope exchange rule, you ensure that the program launch date is never compromised, while giving the business the flexibility to pivot their priorities as they learn.

The MoSCoW Prioritisation Process Under Pressure

Managing scope under capacity constraints requires a highly robust prioritization methodology. The industry standard is the **MoSCoW method**, which categorises requirements into **Must have** (critical features without which the system cannot launch), **Should have** (high-value features that are important but have manual workarounds), **Could have** (desirable features that can be easily deferred), and **Won't have** (features agreed to be out-of-scope for the current release). However, during active delivery, stakeholders often suffer from "Must-Have inflation," categorising every single request as a critical, show-stopping requirement.

To combat Must-Have inflation, the delivery team must enforce a strict **operational definition for Must-Haves**. A requirement is only classified as a Must-Have if the program would be forced to cancel the launch if the feature were missing, or if launching without it would violate legal, regulatory, or compliance mandates. If a business unit can operate for a single day using a manual workaround (such as updating an Excel sheet or sending a manual email), the feature is immediately downgraded to a Should-Have or Could-Have. Applying this objective filter strips out low-value requests, protecting the core delivery timeline.

Furthermore, establish a firm **mathematical ratio for backlog composition**. The total estimated volume of Must-Have stories in the launch backlog must never exceed 60% of the team's total program capacity. The remaining 40% of capacity must be allocated to Should-Haves (30%) and Could-Haves (10%). This ratio creates a vital buffer that protects the project from unexpected estimation errors, technical hurdles, and genuine late-stage discovery. If the program encounters delays, the delivery manager can simply trade out the Could-Haves and Should-Haves without impacting the core launch validity, guaranteeing on-time delivery.

Tactical Refusal and Relationship Protection

Holding the line against scope creep ultimately depends on the delivery leader's interpersonal capability and tactical negotiation skills. Simply saying "no" to a senior business sponsor without context or empathy will build resentment, damage trust, and lead stakeholders to bypass program governance to force changes through executive escalation. We must master the art of the **constructive 'no'**, framing scope decisions around technical realities and platform health rather than obstinacy.

The first tactical approach is to **depersonalise the refusal**. Avoid framing the decision as your personal choice; instead, frame it around the objective capacity limits of the team, the signed Solution Design Authority charter, or the platform's architectural guardrails. Instead of saying: "I won't build this custom object for you," present the program metrics and state: "Our sprint velocity is capped at 40 points, and our Must-Have backlog is currently full. To build this custom object within our timeline, we would need to defer the core billing integration, or we can place it at the top of the Phase 2 backlog. How would you like us to balance these priorities?" This approach repositions the delivery team as partners helping the business manage their limited resources, rather than gatekeepers blocking their progress.

The second technique is the **Phase 2 Pipeline**. Never tell a stakeholder that their idea is worthless or will never be built, even if it is technically suboptimal. Instead, validate their business challenge and route the request to a visible, structured **Continuous Platform Innovation backlog** (often referred to as Phase 2 or the Enhancement Pipeline). By documenting their request in a visible system (such as Jira or ADO) and categorising it for post-launch enhancement, you show the stakeholder that their voice has been heard and their requirement has been preserved. This defuses immediate tension, allowing the team to maintain sprint focus on the critical launch MVP.

Finally, implement a **weekly scope audit report** for the executive steering committee. This report must explicitly track the volume of incoming change requests, the status of SDA evaluations, and the quantitative impact of approved scope exchanges on the launch date. By visualising scope creep at the executive level, you empower your senior sponsors to intervene when specific business units are bombarding the team with low-value requests. When executive sponsors see that a minor operational request threatens to delay a multi-million-pound program, they will quickly step in to hold the line, protecting your team and your timeline.