Scope creep and poorly controlled change requests are among the most common causes of budget overruns and delivery delays in Salesforce programmes. While evolving requirements are inevitable, the way change is governed often determines whether a programme remains under control or gradually becomes unmanageable.
For programme sponsors, the issue is rarely the volume of change itself. It is the absence of clear decision-making, impact assessment, and ownership around what changes are approved, deferred, or declined.
This article examines how scope creep typically emerges during Salesforce implementations and outlines the disciplines that help organisations retain commercial and delivery control as programmes progress.

Scope creep as a governance issue
Salesforce implementations frequently begin with a defined scope, only for additional requirements to surface once delivery is underway. These requests are often well intentioned and individually justified, but when assessed in isolation they obscure their cumulative impact on cost, timeline, and risk.
In practice, scope creep accelerates when early assumptions are left unchallenged and change decisions are made informally. Each additional feature or adjustment introduces downstream implications across design, security, integrations, testing, data migration, training, and licensing. Without structured oversight, these impacts compound quickly.
Disciplines that help control scope and changeSeveral practices consistently help organisations manage change without undermining delivery confidence or commercial discipline.

Define scope with sufficient precision
A clearly articulated scope, including agreed outcomes, constraints, and priorities, provides a baseline for evaluating change. This clarity helps distinguish between essential evolution and discretionary enhancement.

Establish a formal change process
Change requests should be submitted, reviewed, and approved through a defined mechanism. Each request should be assessed for its impact on cost, timeline, and risk before any commitment is made.

Assess impact holistically
Effective change control looks beyond development effort alone. Design complexity, data implications, security, integrations, testing effort, user training, and licensing all need to be considered as part of the decision.

Prioritise ruthlessly
Not all change delivers equal value. Sponsors and stakeholders should prioritise requests based on business benefit and strategic alignment, recognising that approving one change often means deferring another.

Maintain realistic expectations
Clear communication about the consequences of change helps avoid false confidence. Stakeholders should understand that additional scope almost always carries cost and delivery implications.
​
Review scope regularly
Ongoing review of scope, milestones, and spend helps identify emerging pressure points early, allowing corrective action before issues become embedded.
Programmes that apply these disciplines tend to retain control even as requirements evolve. Those that do not often experience gradual erosion of budget, timelines, and stakeholder confidence.

Bringing it together
Scope creep in Salesforce programmes is rarely accidental. It is usually the result of informal decision-making, weak change control, and limited visibility of cumulative impact.
Managing change effectively requires clear ownership, disciplined governance, and objective assessment at the point decisions are made, not after consequences emerge.
Issues like those described in this article are commonly identified through independent Salesforce Project Assurance, where scope, delivery risk, and commercial exposure are reviewed together to support informed decision-making and protect outcomes.

Salesforce implementations are often positioned as technology programmes, but the greatest risks rarely sit in the technology itself. Budget overruns, delayed benefits, and loss of stakeholder confidence are more commonly caused by unclear ownership, weak planning, misaligned incentives, and early decisions that compound over time.
For CIOs and programme sponsors, the challenge is not whether Salesforce can deliver value, but whether the programme is structured and governed in a way that protects that value from avoidable risk.
This article explores some of the less visible risks that frequently undermine Salesforce implementations, from early planning and requirements through to delivery, adoption, and post-implementation support. It draws on practical experience from real programmes and highlights where clearer decision-making and independent oversight can make the difference between a controlled investment and a budget-draining exercise.

​Inadequate planning and requirements gatheringInadequate planning and requirements gathering remain one of the most common causes of cost escalation and delivery delay in Salesforce programmes.
Organisations are often eager to move quickly, with only a partial view of what they want Salesforce to achieve or how it should operate once live. Without sufficient time invested upfront, assumptions remain untested and requirements continue to evolve as delivery progresses. The result is incremental scope growth, additional cost, and increasing pressure on timelines.
In one such programme, delivery began with a high-level vision but without a clear future operating model. As the project moved forward, new business needs surfaced, driving repeated changes in scope. Each adjustment appeared reasonable in isolation, but collectively they led to significant overruns in both cost and effort.
To reduce this risk, several disciplines consistently prove effective.

Envision the future operating model
Develop a clear view of how Salesforce will be used once live, including workflows, roles, and interactions across the organisation. This helps identify essential capabilities early and reduces late discovery of requirements.

Engage stakeholders early and consistently
Involving business, operational, and technical stakeholders from the outset helps ensure priorities are understood and agreed. This reduces the likelihood of material changes emerging once delivery is underway.

Define scope with discipline
A clearly articulated scope, grounded in business objectives and user needs, provides a reference point for decision-making throughout the programme. It also enables more realistic budgeting and planning.

Document decisions and assumptions
Capturing requirements, design choices, and agreed trade-offs creates transparency and accountability. This is particularly important when managing scope and controlling change.

Plan for controlled flexibility
Change is inevitable. Allocating contingency and defining how changes will be assessed and approved helps maintain control without creating unnecessary rigidity.

​Programmes that invest time in these areas upfront often appear slower at the start, but consistently experience fewer disruptive changes later. In practice, this approach reduces cost, shortens delivery cycles, and improves confidence among stakeholders.

Bringing it together
​Salesforce implementation risks are rarely the result of a single poor decision. They emerge when planning assumptions go unchallenged, scope expands without effective control, or delivery momentum overtakes governance and commercial discipline.
Addressing these risks requires more than capable delivery teams. It requires clear ownership, realistic planning, and independent perspective at key decision points throughout the programme lifecycle.
Issues like those outlined in this article are commonly identified through independent Salesforce Project Assurance, where delivery risk, governance, and programme confidence are reviewed together to protect outcomes and control cost.

Defining a robust architecture for your Salesforce implementation is critical to delivering a successful business solution. Over time, business users will demand new capabilities from the platform, and there could also be external demands from customers, partners and technological advances. The Well-Architected Framework (WAF) is emerging as a widespread best practice for cloud-based products like Salesforce. AWS developed WAF to help cloud architects build secure, high-performing, resilient, and efficient application infrastructure. The principles of WAF can be effectively applied to Salesforce solutions, offering invaluable guidance for architects and developers aiming to create robust and scalable solutions on the Salesforce platform.

The WAF comprises six key pillars:

1. Operational Excellence: Focuses on running and monitoring systems and continually improving processes and procedures. Key topics include automating changes, responding to events, and defining standards to manage daily operations. In the context of Salesforce solutions, operational excellence entails effective platform management, including deployment processes, monitoring, and automation. This pillar encourages continuous integration and delivery (CI/CD), proactive monitoring of system health and performance, and automation of routine tasks to streamline operations and enhance agility
2. Security: Focuses on protecting information and systems. Key topics include confidentiality and integrity of data, managing user permissions and establishing controls to detect security events. For Salesforce, security is paramount in any implementation dealing with sensitive customer data. Applying the security pillar involves enabling Multi-Factor Authentication (required by Salesforce), enforcing strict access controls through profiles & permissions, encrypting sensitive data at rest (built-in) and in transit, and regularly running security assessments to identify and mitigate vulnerabilities.
3. Reliability: This topic focuses on workloads performing their intended functions and how to recover quickly from failure to meet demands. Key topics include distributed system design, recovery planning, and adapting to changing requirements. Salesforce already ensures high platform availability and built-in disaster recovery to a second data centre. Furthermore, Salesforce architecture must include reliability measures such as data backup, automated re-deployment from code repository, meaningful error messages from integrations, designs for fault tolerance, and testing of recovery procedures to ensure resilience in the face of disruptions.
4. Performance Efficiency: This pillar concerns properly allocating IT and computing resource types and sizes optimised for workload requirements, monitoring performance, and maintaining efficiency as business needs evolve. For Salesforce, this could involve optimising data model design, using built-in features instead of custom code, leveraging composite APIs, and employing asynchronous integrations for long-running tasks.
5. Cost Optimisation: To avoid unnecessary costs, WAF advocates understanding business needs over time and deploying the right type and quantity of resources as the business grows. As with most SaaS products, cost optimisation involves choosing the Salesforce licenses based on forecast demands (time & volume) and periodically reviewing licenses to avoid waste. (See https://www.caleidoscope.co.uk/licensing-checklist.html and the forthcoming Salesforce License Strategy webinar.)
6. Sustainability: This area focuses on minimising the environmental impacts of cloud infrastructure. By using the Salesforce platform as a strategic component in your overall IT architecture, you already support a high degree of sustainability.

In conclusion, the Well-Architected Framework provides a comprehensive and structured approach to designing and optimising cloud-based solutions, offering valuable insights and best practices across key areas such as operational excellence, security, reliability, performance efficiency, and cost optimisation.

By applying the framework's principles to Salesforce solutions, architects and developers can create robust, scalable, and cost-effective systems that meet their organisations' evolving needs and deliver exceptional user experiences. For further information on how to apply WAF to your Salesforce architecture, please contact Caleidoscope Associates at [email protected]

Resources:

• 8-Factor Success Model™ for Salesforce implementations
• AWS WAF Whitepaper 

Implementing Salesforce solutions is a complex undertaking that requires a blend of information technology and business skills. The endeavour's success hinges on coordinating highly skilled people to perform critical tasks in the correct order to achieve the project outcomes. The project's planning, resource engagement, and risk mitigation are all contingent on the project manager's experience and expertise and the sponsor's ability to set the direction and overcome obstacles. Without the requisite experience, the project plan will lack a good foundation, potentially leading to time and cost overruns, ultimately failing to deliver the intended benefits.

​Each project is unique, and delays can be caused by many things, from poor planning and inaccurate estimates to ineffective task execution and resource conflicts. Many Salesforce projects avoid the traditional waterfall planning approach because the project appears to take too long. Instead, some organisations take an agile approach to deliver working Salesforce solutions faster. Both methodologies have their strengths and weaknesses, but they will only work if they are set up and managed correctly.

The Critical Chain approach, rooted in constraints theory, is valuable in project environments. It focuses on identifying and eliminating obstacles and limitations that impede project progress. This methodology, developed by Eliyahu Goldratt (refer to 'Theory of Constraint'), requires the same planning rigour as waterfall projects. However, it differentiates itself from the waterfall approach by employing buffers to safeguard the critical path. While the Critical Chain approach offers similar vigour as the agile methodology, it mitigates the confusion that you often find on larger agile projects.

There isn't a one-method-fits-all project approach for Salesforce projects; any of the three approaches discussed can work well for a Salesforce implementation. It is crucial to consider which methodology the project team is most comfortable and experienced with. If working with other project teams and third parties, agree to use the same methodology to avoid the added overhead and risks of working with multiple methods.

Do not let jargon like 'out-of-the-box' features, custom configurations and declarative tools like Flow Builder lure you into thinking that implementing Salesforce is easy. In fact, due to the vast array of features and configuration options available in the Salesforce platform, your project team will need the rigour and discipline of traditional software projects to implement Salesforce solutions as specified, on time and within budget. Ensure the approach is applied correctly and governed by whichever project methodology you choose.

To find out more about delivering Salesforce projects effectively and with fewer risks, contact us at Caleidoscope Associates.

Salesforce is often positioned as a comprehensive enterprise platform capable of transforming how organisations operate. While the technology is powerful, the decision to adopt Salesforce is less about the platform itself and more about the assumptions, trade-offs, and commitments made before delivery begins.

For CIOs and programme sponsors, the risk is not choosing the wrong technology. It is committing to a programme without sufficient clarity around objectives, scope, cost, capability, and long-term operating impact.
This article sets out six critical questions that decision-makers should resolve before committing to Salesforce, to reduce risk, protect investment, and establish the conditions for sustainable value.

1. What business objectives and pain points are we addressing?
Before any platform decision is made, organisations need a clear and shared understanding of what they are trying to achieve. Salesforce should be a response to defined business outcomes, not a proxy for strategy.
Without clarity on objectives and pain points, decisions around scope, configuration, and delivery approach become reactive. This increases the likelihood of over-engineering, late change, and misaligned expectations.

2. How well does Salesforce fit our operating model and processes?
Salesforce can support a wide range of standard business processes, but transformational outcomes often require changes in how the organisation operates, not just how the system is configured.
Customisation should be a deliberate choice, not a default. Over-customisation introduces complexity, technical debt, and long-term cost. The balance between standard capability and bespoke design should be assessed in the context of the future operating model, integration landscape, and organisational maturity.

3. What does the full business case really include?
Licence costs are only a small part of the overall investment. A credible business case needs to account for design effort, configuration, testing, training, integrations, environments, security, data volumes, and ongoing support.
Decisions made early around architecture and customisation have a disproportionate impact on total cost of ownership. Without visibility of these factors, organisations are often surprised by cost escalation after delivery is underway or once the platform is live.

4. How will the solution scale as the organisation evolves?
Salesforce scales well for user growth and transactional volume, but scalability challenges often emerge elsewhere. Reporting complexity, integration throughput, data volumes, and performance expectations can all become constraints as usage increases.
Organisations operating across multiple business units, regions, or operating models need to consider how shared data, common processes, and local variation will be managed over time.

5. What security and compliance requirements apply?
Security and data protection requirements are foundational design inputs, not technical afterthoughts. Late clarification of security, privacy, or regulatory obligations often results in rework, cost increase, and delivery delay.
These requirements also influence licensing, architecture, and operating cost. Early involvement of security and data governance stakeholders reduces both risk and long-term expense.

6. What capabilities are required to deliver and sustain the platform?
Salesforce programmes depend on more than delivery partners. Internal capability across product ownership, administration, architecture, and support is critical to long-term success.
Organisations need to decide which capabilities they will own, which they will augment, and how accountability will be maintained once the programme transitions from implementation to operation.

Bringing it together
The decision to adopt Salesforce sets the direction for years of operational and commercial impact. The risks lie not in the platform itself, but in unresolved assumptions around objectives, cost, governance, scalability, security, and capability.
Addressing these questions early requires informed challenge, structured decision-making, and independent perspective before commitments are locked in.
Questions like those outlined in this article are commonly explored through independent Salesforce Project Assurance, where early assumptions, delivery risk, and long-term implications are reviewed together to support confident decision-making.

Salesforce is a powerful platform, but its success is rarely determined by features alone. Many Salesforce programmes underperform not because the technology is flawed, but because early decisions introduce unnecessary complexity, risk, and cost that compound over time.
For CIOs and programme sponsors, the most common Salesforce mistakes are not configuration errors. They are governance, planning, and capability decisions that shape how the platform is designed, adopted, and sustained.
This article outlines five recurring mistakes seen across Salesforce programmes and explains why addressing them early is critical to protecting investment, maintaining delivery confidence, and realising long-term business value.

I. Customisation overload
Salesforce offers extensive flexibility, but excessive customisation often creates fragile solutions that are difficult to maintain and costly to evolve. Over time, heavily customised environments can restrict upgrades, increase technical debt, and slow delivery.
The underlying issue is rarely a single design decision. It is the absence of clear criteria for when customisation is justified and how its long-term impact will be managed. Without this discipline, incremental changes accumulate into significant complexity.

II. Neglecting information security best practices
Salesforce implementations frequently handle sensitive customer and commercial data. When security considerations are treated as technical details rather than core business requirements, organisations expose themselves to avoidable risk.
Late discovery of security, privacy, or contractual obligations can drive significant rework and cost, particularly where third-party data or integrations are involved. These requirements also influence licensing and architectural decisions, making early involvement of security and data protection stakeholders essential.

III. Overlooking data quality
Poor data quality undermines confidence in reporting, decision-making, and user adoption. It is often treated as an operational issue, when in reality it is a strategic one.
Requirements for analytics, KPIs, and data-driven outcomes frequently surface late in Salesforce programmes, limiting the organisation’s ability to extract value from the platform. As organisations increasingly rely on automation and AI-driven insight, the consequences of weak data foundations become more pronounced.

IV. Ignoring scalability considerations
Salesforce is designed to scale, but solutions often struggle when growth, additional business units, or new operating models are introduced. A one-size approach rarely works in organisations with diverse processes, systems, or regulatory constraints.
Scalability challenges typically arise when architectural decisions are made without sufficient understanding of future operating models, integration dependencies, and non-functional requirements such as performance and response time.

V. Neglecting comprehensive user training
Even well-designed Salesforce solutions fail to deliver value if users are not equipped to use them effectively. Training is frequently compressed or deferred, particularly for key roles such as Product Owners, Administrators, and support teams.
When capability development is treated as an afterthought, organisations risk low adoption, inconsistent usage, and increased reliance on external support. Building internal capability early is essential to sustaining value beyond go-live.

Bringing it together
These five mistakes are rarely isolated incidents. They tend to emerge when early assumptions go unchallenged and when delivery momentum overtakes governance, capability planning, and commercial discipline.
Avoiding them requires clear ownership, informed decision-making, and independent perspective at key points in the programme lifecycle.
Issues like those outlined in this article are commonly identified through independent Salesforce Project Assurance, where delivery risk, governance, and long-term platform sustainability are reviewed together to protect outcomes and control cost.