12 minute read

Why every Org needs a Center of Excellence (race car analogy)

Home » Blog » Why every Org needs a Center of Excellence (race car analogy)
Home » Blog » Why every Org needs a Center of Excellence (race car analogy)


Salesforce was a Ford Focus, now it is an Aston Martin GTE race car.
Salesforce was quick, easy, and safe. But had a narrow focus. Now it is strategic, powerful, and flexible. But it needs a full race team with the skills and tools to exploit the full performance since everyone depends on it.

We’ve been customers since 2001. Salesforce has changed dramatically since then from a Sales Force Automation app (tactical) to a customer experience (strategic) platform, with many customers spending over $20m/year.
The power, scope, and complexity of the Salesforce platform have increased dramatically.

At the same time, a growing ecosystem of Trailblazers is inspired by the potential of learning through Trailhead, but far more expansive implementation skills are required to run increasingly complex Orgs. The expectation set by marketing, sales, and Trailhead that Salesforce is “so quick and simple anyone can get it going in days” is no longer true. These are risky, strategic, and costly project implementations. The penalties for failure are high.

Customers of all sizes are struggling with levels of technical debt that are killing agility. This is (at least in part) due to the low levels of implementation maturity compared with the general IT industry. The good news is that these are “solved problems” in other ecosystems where the implementation maturity is much higher.

All research and experience point to the importance of implementing a Center of Excellence.


Having been a customer since 2001, we never could have imagined the changes over the last 20 years. Salesforce has broken records in the IT industry for growth and democratizing app development. It has been an amazing ride.

Back in 2001, there were just 5 objects, no AppExchange or Trailhead. Sandboxes didn’t exist. But the huge power of the platform was evident. For those of us with years of Oracle, SAP or custom IT implementations, the speed, flexibility, and potential to configure Salesforce took our breath away. For our own business, we built out 285 custom objects to run all aspects of our operations with clicks not code. Salesforce was our core platform. Cloud, or ASP as it was called then, meant our teams around the world had access to a single source of truth for all customer data: customer-360. There were no IT barriers to scaling our business internationally. Amazing.

Fast forward 20 years. Salesforce has invested heavily through R&D and M&A to expand the platform capabilities and integrations to the corporate IT landscape. The scope and complexity of projects have expanded massively. Customers are committing to Salesforce as a strategic platform and it is the single source of customer data access across their enterprise. That rapid growth and success has enabled Salesforce to go from a tactical sales automation app to a strategic platform in many of the 200,000 customers.

So far, so good.


A key issue, that has been recognized by Salesforce over the last 2-3 years, is the increasing levels of technical debt in Orgs. Technical debt is at crippling levels in mature orgs and is the #1 reason for not migrating to Lightning. It kills agility, which ironically was the most compelling reason for using Salesforce in the first place. It stops customers from adopting more Salesforce technologies and puts renewals at risk.

Back in 2017, Forrester wrote an article called the “Salesforce @scale dilemma” which summarizes perfectly the current issues of technical debt we are now seeing. John Rymer from Forrester explains

“Salesforce@scale dilemma: a client chooses Salesforce CRM for its business responsiveness.

Typically, clients are impressed by Salesforce’s CRM applications, which are more modern and user-pleasing than older applications. And they love Force.com’s high productivity for developers to configure the CRM applications as well as create new applications from scratch.

Initial success breeds demands for more and more. As additional departments ask for Salesforce subscriptions, business leaders want to expand initial wins with Salesforce CRM into customer and/or partner engagement, marketing automation, and analytics. New custom applications and customizations mushroom.

In addition, the complexity of scale crushes Salesforce’s responsiveness. As Salesforce use grows, innovation slows and flexibility evaporates. Why? Every app change risks breaking one of the hundreds of data and process customizations, integration links, and third-party add-ons. The result: every change requires long and expensive impact analysis and regression testing projects – killing the responsiveness that made Salesforce attractive at the start.

The Salesforce@scale dilemma is a challenge for clients to overcome, rather than an inevitable outcome of large-scale, strategic Salesforce implementations. It is a big issue because Salesforce has become a much more strategic supplier in technology strategies to win, serve and retain customers.”

Without strategies and tools to manage a Salesforce Org it can rapidly get to a stage where the technical debt is out of control, resulting in one of 3 things;

  • it becomes unresponsive and ROI disappears
  • a costly clean-up project is launched
  • the Org is thrown away and replaced with a new Org or a different platform.

We’ve analyzed over 1 billion Org metadata items and the scale of Org customizations is staggering. Here are the highest numbers of metadata items we have seen in Orgs: 250,000 reports, 50,000 email templates, 2,000 custom objects, 400 record types on an object, 20,000 custom fields, 13,000 dashboards, 100 managed packages, 18 million cases, 1.4x storage limit. There was an org with 10 million task records, which we thought was jaw-dropping, only to be beaten the week after when we analyzed an Org with 114 million tasks!!


This race car analogy really does bring to life the transformational change to Salesforce that we have seen in the last 20 years. But it also shows what is now required to exploit its awesome capabilities.

Back in 2001, Salesforce was relatively simple with a narrow scope; sales automation for a small group of people. The speed and flexibility of Salesforce was amazing. And if it stopped working, no biggy. Only a few people were impacted.
It was a Ford Focus and a couple of people could easily get from A to B.

But now in 2020, Salesforce is a core platform. The entire company depends on it. Having a customer-360 view is a competitive advantage for the company. It is strategic, and unplanned downtime is unacceptable.
It is an Aston Martin GTE race car and the whole team depends on it to win

What does it take to run a winning race car team?

It requires a Race Director, sponsors, car designer and builders, a race car and spare car, mechanics, pit crew, time in the wind tunnel, on the test track and on the circuit, in-car analytics, a race strategy, highly trained driver, and PR & communications.

Here is a video from the Aston Martin GTE race team on what it takes to get it from the drawing board to the track yet the second video is about how many orgs still seem to be managed

Best of breed

It is a team effort and the winning teams have the best leadership, the best sponsors, best race strategy, the best tools, the best car, best team, and the best driver. Not all of these relate directly to the roles, skills and tools on Salesforce projects, but broadly:

Best leadership: CIO or CRM owner
Best sponsors: budget/investment
Best race strategy: implementation approach
Best tools: Center Of Excellence, business analysis, DevOps, Org analytics, change management
Best cars: Salesforce platform and Appexchange add-ons
Best team: qualified project managers, business analysts, architects, admins, developers and change managers
Best driver: trained users

To continue the analogy. Trailhead and Certifications cover how to maintain and configure parts of the car: how to rebuild the engine; how to set the suspension; how to set the spoiler downforce. Whilst these are vitally important to understand, they are tactical activities as part of an overall strategic plan.

Strategy puts tactics into context

You cannot just turn everything up to the max. For example: High downforce increases grip but increases drag, so it makes the car slower in a straight line but is vital on twisty tracks. Long fast circuits need less downforce with the added benefit of less drag. So the race strategy determines the downforce settings of the spoilers. You can’t just switch downforce to the max without an understanding of the implications and how it fits with the race strategy.

The same is true for Salesforce functionality. For example, Flow, Record Types, and Permission Sets are powerful and have a place but only in the overall implementation strategy.

BTW “Record Types are like glitter. Once you add them, you can never get rid of them.”


These are not new issues. These are “solved problems” and are not unique to Salesforce. Salesforce implementations have similarities with the Oracle and SAP implementations post-2000, but with 2 key differences: cloud and the power of the Salesforce low-code platform. Sure, the cloud has made some aspects easier, but the fundamentals of implementing technology remain. Successful implementations consider more than the core technology. They cover people, processes, AND technology. What is missing from successful implementations are the activities that are grouped under a Center of Excellence (COE).

The 10K Advisors Project to Program research identified that 91% of customers with a very high ROI and 82% of customers who felt they were A players had a Center of Excellence.


Now that Salesforce is a major strategic platform it requires the proven approaches, tools and skills of a COE to exploit the power and deliver the potential ROI at scale. Without them, the true differentiator of Salesforce – the super agile platform – is blunted. These approaches and tools are available in the ecosystem, and being applied by the global SIs and some large customers, but not yet adopted across all customers.

That needs to change.


Whilst every organization’s COE is different, there are some common aspects. No matter what the size of the project, these need to be in place. These are activities, not roles. The smaller the project, the lighter the touch.

Key pillars

Here is the overall scope or key pillars of a COE

  • Vision: strategic vision and direction for Salesforce for both the business and IT
  • Leadership: Steering Committee and key sponsors in business and IT
  • Governance: overall control of strategic direction, business cases, investment, and risk management
  • Change control: management of changes to all aspects of the project
  • Methodology: the implementation methodology covers people, process, and technology which includes business analysis, DevOps, and adoption.
  • Standards: includes standards for business analysis, org documentation, metadata naming, coding, testing, communication, change management, and training
  • Metadata management: control of the Salesforce metadata across the deployment pipeline
  • Architecture: technical architecture of Salesforce and how it relates to the integrated systems and InfoSec
  • Security; coding and external integrations introduce vulnerabilities that need to consider from the outset
  • Change management: communications, organizational change, and training to get Salesforce adopted
  • PMO: the Project Management Office that manages the COE activities
  • Tooling: platforms/apps/ tools used to support the project
  • Prototyping: innovation hub that builds out Salesforce prototypes to show the “art of the possible”

Phased approach

As the size and strategic importance of the Salesforce implementation increases, then each of these aspects becomes more important. We’ve tried to give some perspective in the diagram below. The definition of “size” is by no means prescriptive, but an indicator of strategic importance.

  • Small – Solo or small Admin team with limited developers. Fewer than 100 users
  • Medium – Team with BA, Admin, and Developers. SI engaged. External integrations. 100-1000 users
  • Large – Multi-org, multi-cloud. 1000+ users

The colors of the circles indicate how important it is to have that capability in place (white: not required, yellow: needed, red: mandatory). Ideally, every implementation has all of them, but we understand the trade-offs of running an Org.


There are real-world benefits of a COE and a more structured approach as the Forrester report and 10K Advisors research have shown. Often it is best to hear from customers. Here are both sides of the story from the Forrester report:

A food and beverage firm that adopted Salesforce for all its customer operations avoided the Salesforce@scale dilemma with planning and governance for adopting a platform as opposed to a CRM application and associated tools.

The firm set up a CoE and defined a common data model (including built-in and Custom Objects), a master data service, and a process rollout across the world. “One platform for all data and application building blocks means you need to be aligned on how you use those assets,” says a leader of the firm’s Salesforce CoE. “[The assets] have to fit together, and everyone needs an understanding of what is possible and what should be done.”

And a less successful outcome at a large US public sector agency. Sadly this is a more familiar story.

One department was happily using Salesforce’s core customer relationship management (CRM) application when a cloud-first directive changed everything for the worse. The directive was: move as many applications as possible to the cloud – including Salesforce.

“The perception was that it almost didn’t matter what we did – if we put apps on cloud and Salesforce, we’d be successful,” recalls the agency’s Salesforce Center of Excellence (CoE) leader.

The agency quickly added about 12,000 Salesforce seats in seven separate Orgs, lots of customizations, and many custom applications. As this expansion progressed, innovation on the agency’s core Salesforce apps slowed to a crawl, and operating costs rose. Updates and changes to enterprise processes and existing apps were now sluggish, although the agency still could quickly stand up isolated new applications.

“When you start adding custom code [to Salesforce], you need developers to make changes,” says the agency’s CoE leader. “And Salesforce becomes way more expensive to maintain.”


I will leave the final word to John Rymer from the Forrester analysts, who said this back in 2017 in their report “Five ways to cut the risk of going all-in with a Salesforce customer platform”

“The Salesforce@scale dilemma is a challenge for clients to overcome, rather than an inevitable outcome of large-scale, strategic Salesforce implementations. It is a big issue because Salesforce has become a much more strategic supplier in technology strategies to win, serve and retain customers.”


COE Lounge (monthly discussion, ET / PT / Europe): invite
COE Success Community: join
COE LinkedIn Group: join
10K Advisors: Project to Program report: download
Forrester report summary blog
Forrester report (requires client membership) link


Back to News