Master the Chaos of Your Salesforce Program: 3-Step Guide

What is the goal of your Salesforce program? 

Do you need to coordinate better between orgs, standardize processes, drive efficiencies of time and cost, and (most importantly) create a better overall experience for your users and teams?

Establishing a Salesforce COE (Center of Excellence) is how you make all of the above a reality. It’s the key to achieving operational efficiency and maximizing the value of your Salesforce investment. 

What is a Salesforce COE?

A Center of Excellence is a management framework that ensures efficient, effective, and timely digital transformation. At 10K, we like to consider a COE as the CEO of your Salesforce program. A COE has five pillars that answer the following questions:

Salesforce team roles and structure

Who on the team does what?

How do you articulate responsibilities?

How do you define and develop solutions?

Delivery standards and processes

What do you have in place to ensure you deliver capabilities to the business predictably and consistently?

Governance, change, and release management

How do you prioritize requests, communicate across teams, and roll out changes effectively?

End-user support processes

How do you ensure your end users get the answers and solutions they need in a timely manner to increase usage and adoption?

Education and growth

How do you and your team keep up with the constantly expanding Salesforce platform to help your stakeholders?

Knowing where to start with a Salesforce COE can feel too overwhelming and expensive to consider (especially during an uncertain economy). However, the good news is a COE doesn’t have to be complex to be effective. They come in many shapes and sizes and provide the structure necessary to drive higher Salesforce ROI. 

Why would I need a Salesforce COE?

Every Salesforce customer wants to accomplish the same things. However, we’ve found most are missing the education necessary to be intentional about making their Salesforce program a success. 

It might be time to explore the benefits of a COE if you’re currently seeing:

  1. A lack of innovation with Salesforce (new features, capabilities, and clunky processes)
  2. It’s taking too long to make the above a reality 
  3. A lack of predictability and visibility into how work gets done

Survey results of Salesforce customers that correlate ROI with their COE

Consider making a COE the CEO of your Salesforce program. Here is how to start building one. 

How to start building a Salesforce COE

Like building a house, we recommend starting with the foundation of your COE. Here are the first three steps to building a Salesforce COE.

First: Define your Salesforce roadmap and validate it with an architect 

A Salesforce roadmap is a centralized plan that lays out what you’re going to do and how you’re going to do it. It plays an essential role in delivering on business goals and will help prioritize Salesforce projects and implementations, determine what kind of skills and capacity you need to hire for and outline the timeframe in which work needs to be completed. Salesforce roadmaps help take you from Project to Program, ensuring a better return on innovation. 

Who should build my Salesforce roadmap?

Building a Salesforce roadmap is a collaborative process that requires technical and business stakeholders. You will also need a Salesforce architect to review and validate your roadmap. 

Speaking of architects, let’s revisit the building-a-Salesforce-house analogy. Like building a house, you don’t call an architect when the walls go up. You hire an architect for the design process starting from Day One. Building a Salesforce roadmap or COE (or any major Salesforce initiative) is no different. 

Salesforce architects can not only validate the type of technology you want to use but also provide contextual insight and call out the risk areas of any plans while helping with design decisions about delivery standards and processes, integration architecture, or data migration strategy. They also help confirm product and feature selection. 

Why are Salesforce architects essential?

For example, your sales reps say creating quotes has become too complicated and have heard CPQ is a great solution. Before investing in new technology, it needs to be evaluated if CPQ is the best solution given specific circumstances. A specialized CPQ architect can step in, holistically evaluate your team’s challenges, and determine whether the solution comes down to process improvement, a new product like CPQ, or a combination of the two. 

Architects play an essential role in maximizing Salesforce ROI and minimizing technical debt. Our Project to Program research survey found that regular use of architects strongly correlates with the highest ROI. The majority of respondents who report A-grades (73%) and the highest return on investment (82%) always work with a technical or solutions architect.

With an architect at the helm, it’s time to assemble your team. Before you turn to your talent acquisition team or a recruiter, take inventory of your team’s current state – the roles you have filled in-house and their accompanying skillsets – to provide direction on what kind of talent you need to bring on board to execute your roadmap. 

After this exercise, you should be able to answer…

How many of which roles do we need?

Which roles are essential to have in-house, full-time?

Which roles can we hire for on-demand as we need them?

To illustrate this for a specific project, let’s revisit the CPQ or not to CPQ scenario above. If your architect determines that investing in CPQ is the best solution, then it is likely that you’ll need an in-house expert to manage such a specialized cloud. To execute the initial implementation, however, you should hire a team of hire on-demand consultants. 

Second: Define the roles and capabilities that will deliver on the roadmap

One of the most important pillars of a Salesforce COE includes having defined and assigned team roles and leadership structure.

When it comes to the specific roles within a COE, here are the most common ones we see:

COE Lead: This role is responsible for overall program execution. He or she establishes the standards and guidelines that anyone who touches the Salesforce system must abide by, coordinates the resources needed to execute the established strategy, and manages partners and vendors.

Admin: This role primarily supports those across the business who use Salesforce. They tackle everything from creating dashboards and reports to managing configurations and campaigns to communicating changes and updates to end users. 

Business Analyst: This role works directly with the business to review operational processes and identify opportunities to automate and improve those processes using Salesforce. He or she gathers and articulates requirements and serves as a change management agent across the business.

Technical Architect: This role owns the technical design of the Salesforce system, ensuring declarative and non-declarative features are used appropriately and that the org can scale as the amount of functionality grows. Our recent research into Salesforce Best Practices and COEs indicates that architects can play an outsize role in improving ROI.

Developer: When your requirements warrant non-declarative functionality, this role is responsible for building it using platform features such as Apex Classes or Lightning Components. This role may also be responsible for integration development, configuration changes, and solution design for complex features.

The roles and responsibilities within your COE may vary based on your organization’s size, structure, complexity, budget, and other factors. In some instances, one person plays all or most of these roles in some way, shape, or form (this is the life of a solo admin). 

Larger organizations may have multiple experts in each of these roles. However, most companies fall somewhere in the middle and use a combination of internal and external expertise to build and manage their implementation. According to our research into Salesforce best practices, 61% of respondents say at least half of their implementation was built by consultants. 

For more on building an Executive Committee and Salesforce Steering Committee, visit our article: The Roles and Structure That Guide a Successful Salesforce COE.  

Third: Create the processes and standards to guarantee predictable and successful outcomes 

You have a roadmap and the talent to make your Salesforce Center of Excellence a reality. Now what?

As we mentioned at the beginning of this article, four other pillars stand up a successful Salesforce COE. For more in-depth detail and the benefits of each pillar, we invite you to visit our Center of Excellence series: 

1. Delivery standards and processes

How to Build a Well-Oiled Delivery Machine for Your Salesforce COE

2. Governance, change, and release management

Process that Speeds, Not Slows: Establishing an Effective Governance Model for Salesforce

3. End-user support processes

Why a Support Process is a Vital Component of a Salesforce COE

4. Education and growth

Education is the Best Way to Get More from Salesforce

It’s always the right time to restrategize and further integrate Salesforce with your business and operations — whether you just started building your Salesforce foundation or are simply looking to get more from the investment you already made.

We have a full how-to guide that provides even more detail on the concepts in this article. To achieve Salesforce operational excellence and maximize ROI, download our Salesforce Center of Excellence Handbook!  

Salesforce Operational Excellence Handbook: A Guide to Getting the Most ROI from Salesforce

Download the guide to maximizing your Salesforce program ROI.

It’s always the right time to restrategize and further integrate Salesforce with your business and operations — whether you just started building your Salesforce foundation or are simply looking to get more from the investment you already made.

Download our Salesforce Operational Excellence Handbook to learn how to establish a Salesforce Center of Excellence (COE) and get the most bang from your investment. Topics covered include: 

  • Team roles and structure

  • Delivery standards and processes 

  • Change management 

  • End-user support 

  • Education and growth 

This handbook was developed based on content from our 6-part COE blog series (below) and research from our Salesforce Project to Program Best Practices report:

Why a COE should be the CEO of your Salesforce Program

The Roles and Structure That Guide a Successful Salesforce COE

How to Build a Well Oiled Delivery Machine for Your Salesforce COE

Process that Speeds, Not Slows: Establishing an Effective Governance Model for Salesforce

Why a Support Process is a Vital Component of a Salesforce COE

Education is the Best Way to Get More from Salesforce

Education is the Best Way to Get More from Salesforce (Part 6 of 6-part COE Series)

The last five posts in our six-part Center of Excellence (COE) series have covered:

The team roles and structures of a COE

The delivery standards and processes a COE should put in place

How to establish an effective governance model

Why a tiered support system is vital to Salesforce success.

In this last post of the series, we make the case for why ongoing learning is the best way to get the most out of a rapidly evolving platform like Salesforce.

Salesforce is constantly evolving and expanding its capabilities.

The breadth of the overall Salesforce platform(s) has grown tremendously over the past 20 years. At one time, it was reasonable for one to be familiar with all of the features Salesforce had to offer. Now, no matter how seasoned you are, it’s nearly impossible to know all there is to know about Salesforce. Part of this is because of the continuous innovation Salesforce pushes with its three annual releases. Salesforce’s penchant for acquisitions is also contributing to this, with CPQ, Mulesoft, Marketing Cloud, and Tableau now large enough to support entire sub-ecosystems of partners, consultants, and apps.

In the past, traditional platforms would release updates maybe once a year. Many organizations wouldn’t even install the new releases because it was such a manual process and had the potential to break customizations already in place. Some organizations might choose to wait for three releases down the road and take a year to make the necessary updates. Even then, things still might break.

Salesforce has shifted that paradigm, releasing hundreds of new features three times a year as part of their subscription model — not something extra for which customers have to pay. While these releases might impact existing features and make certain features obsolete, for the most part, they don’t break customizations the way updates might in the old model. And often times these new features will replace a previous customization that makes your instance better in the long run. 

While this is all great, it makes it even more imperative to educate yourselves, your employees, and your users on how these new features best fit into your business and how to properly take advantage of them. With releases happening so frequently, it’s not always easy to stay up-to-date on what every new release is offering, but if you set create habits around continuous learning, it can help. 

Where is the best place to start learning Salesforce?

The first place anyone should look is Trailhead, Salesforce’s free online learning platform that releases bite-sized learning content that can be consumed in anywhere from five minutes to five hours. Trailhead content covers everything from deep dives on new features to release readiness. And given that it’s self-serve, Trailhead meets users where they are, allowing users to learn at their own pace from anywhere they are. The new Trailhead GO mobile app is a great example of this. It gamifies the experience with assessments, badges, and points that need to be earned to help track progress, which gives users a tangible form of accomplishment and allows managers to know that information is actually being absorbed versus going in one ear and out the other.

If you want to take it a step further, you can incorporate myTrailhead into your ongoing education. For $25 a user a month, myTrailhead allows a company to customize Trailhead with their own brand and assign teams learning content. You can also create your own content that is tailored specifically to how your company has designed and implemented Salesforce.

There are other ways to create a culture of learning in your organization beyond using Trailhead. Simply scheduling review meetings after each release to assess and debate the impact of new features or discuss lessons learned can go a long way. Assign each team member a section of these meetings to own and present so it doesn’t fall to one person on the team. 

And last but certainly not least, it helps to stay on top of how others are using and working with Salesforce. Conferences — even virtual ones, which might be our new reality for the foreseeable future — are great for this. My favorite conference put on by Salesforce is actually TrailheaDX, which I find easier to navigate than the company’s giant Dreamforce conference. If you’re lucky enough to have a local user group, try out a meeting. Or, if it’s available, join their Slack group. Salesforce offers a list of local Trailblazer Community Groups on If you don’t see a user group in your area, start one of your own!

Continuous learning is a big focus for us here at 10K, and it’s what I believe sets apart the best consultants and COEs from all the others out there. If you are a COE leader reading this, I can’t stress enough the importance of setting aside time in both team and individual schedules for learning.

Having a COE in place with the right team, structures, and processes around your Salesforce program can make a huge difference when it comes to seeing a higher return on your Salesforce investment and making Salesforce an integral part of your business. 

Download our guide to maximizing your Salesforce program ROI with a Salesforce COE.

Why a Support Process is a Vital Component of a Salesforce COE (Part 5 of 6-part COE Series)

The previous posts in our Center of Excellence (COE) series have covered everything from team roles and structures to delivery standards and processes to effective governance models for your Salesforce COE. In this post, we’ll focus on the support processes you need to establish for users and why that is vital to the success of your COE.

When it comes to products, great customer service plays a critical part in strengthening brand and product loyalty, and the same holds true for your Salesforce program. The right support structure and processes, established at the outset of a program, can not only make sure people are using the system to its full potential but also help turn them into evangelists for your program. If done right, a well-oiled support process can also provide valuable insight into user behavior, needs, and potential improvements that are invaluable for future iterations of an ever evolving platform like Salesforce.

Here are seven steps to creating an efficient and effective support process that can scale as you grow, and evolve as you do.

1.Outline your rules for engagement.

The first order of business is to establish the structure for your Service Delivery — clearly outlining and defining the different tiers you will use to address issues. Not all problems are created equal, and you shouldn’t treat them equally.  For instance, you wouldn’t make an appointment with an orthopedic surgeon to figure out the best way to get a splinter out of your finger. You’d probably just Google it, right?  

Tier 0: This initial self-service tier can be used for roughly 50% of all support needs, giving users a first point of contact for content, whether it’s process related questions, technical documentation about how the system is supposed to function and why, or guidance for different business functions related to your Salesforce system, such as sales stage definitions, lead conversion criteria, required data for certain records, etc. The goal here is to minimize the number of cases that need to go beyond this tier by providing users with the resources they need. Remember that scene in the late 90’s film Jerry Maguire where Tom Cruise implores Cuba Gooding Jr.’s character to “help me help you?” It’s kind of like that. If these resources can’t provide the answers that users need, then they move down the funnel to Tier 1.

Tier 1: Tier 1, essentially the “help desk”, can be accessed in many different ways depending on the organization and its resources — calling a 1-800 number, through a Slack or text-to-chat option, or by filing a formal support ticket. This tier is capable of handling programmatic administrative functions, and it acts as a gatekeeper, escalating cases to the appropriate team or individual as needed based on its discretion. That’s where Tier 2 comes in.

Tier 2: As the escalation point for Tier 1, Tier 2 is for cases that might need to be routed to a functional expert for non-standard process questions, or to a specialist for complex requirements or sensitive legal issues, or to an IT specialist for deeper technical issues. If one of those doesn’t solve it, then on to Tier 3.

Tier 3: Tier 3, which should comprise only about 10% of your queries, should either be an escalation point for strategic issues related to business performance or for technical issues and enhancements requiring code fixes and/or customizations.

Like in any good relationship, it’s important to create boundaries, and these tiers can help keep your high level technical staff focused on the right problems rather than handling every single request that comes in. Based on the size of your company, the make up of these tiers will vary. For smaller companies, you’ll probably have fewer tiers and/or the same people or groups handling responsibilities for multiple tiers. Larger companies, on the other hand, may have more stratified layers of support. However, even larger companies shouldn’t have too many levels for users to have to go through.

2. Determine what tools you’ll need. Now that you have your tiers outlined and a clear scope, it’s time to define the tools needed for work intake, prioritization and execution. Such tools could include Salesforce Knowledge for self service, Salesforce Service Cloud for case management, and omni-channel tools for advanced case handling (e.g. chat/phone integration). Once you have those established, it’s important to make sure you align your entire team around this set of tools, making sure everyone is educated and able to use them. 

3. Assemble your team. With the structure outlined and necessary tools in place, now it’s time to define the responsibilities of the various roles across the different tiers and begin training them.  Don’t forget to ensure that security is configured appropriately for all team members based on their defined set of responsibilities.

4. Empower super users. Try pinpointing certain users as “Super Users” and empower them with the necessary tools, training and permissions to help with training, to answer common questions, or to resolve basic issues. This will allow the COE and support team to focus on other areas that will add more value to the business.  

5. Build an internal knowledge base. Next, make sure you establish an internal Salesforce Knowledge Base which can be used for Tier 0 self-service as well as for the support team to reference. Doing this preemptively rather than after the fact will help deflect many cases that may otherwise have ended up taking up more valuable time and resources. A knowledge base can be built in many ways, but is typically created using release notes and/or documentation from the change management function.

6. Map feature requests to the roadmap. While the primary purpose of most support processes is to make sure users get the answers they need as fast as possible, it’s also an intake mechanism for feature requests, bug fixes and other enhancements that could add more value to the business. When outlining your support processes, make sure to clearly define your process for how service requests turn into feature requests which then flow back to the COE for roadmap evaluation.

7. Continuous improvement. Occasionally support requests come through because of a legitimate issue with the system. These instances need to be prioritized with the delivery team, and the necessary fixes should be incorporated within a defined release process. Sometimes support requests are enhancements that also need to feed back into the delivery process for prioritization. For more on this, you can revisit our post on delivery process and release management.

These seven considerations can get you well on your way to a fully functioning COE support center. Like most things in life though, communication is key. It’s important to communicate the process early and often, both to the team providing the support and to the users in the organization. People move around and things change, but your process should remain as consistent as possible so it becomes entrenched in your organization. A problem I see often with companies is that while the support teams have a clear grasp on the process and what needs to happen, the users themselves don’t and thus aren’t fully capable of properly using the system that was designed to support their needs in the first place. All because it wasn’t communicated well.

In the meantime, we’d love to hear about your own COE experiences on social media using the hashtag #SFDCCOE or if there’s a topic we haven’t covered yet that you think is missing.

Process that Speeds, Not Slows: Establishing an Effective Governance Model for Salesforce (Part 4 of 6-Part COE Series)

If you asked most companies why they bought Salesforce, “speed” or “agility” would probably top the list. Companies gravitate to a platform like Salesforce because they want a tool that will help them automate time-consuming manual processes and capitalize on new opportunities faster than what is currently possible with their existing systems. 

If a company’s goal is to move fast, it’s easy to see why many might resist the idea of a Center of Excellence. To these resistors, COEs = process, and process = bureaucracy. Few people think of bureaucracy and think speed. However, I can tell you from experience that Salesforce COEs — if done right — can in fact help an organization increase its pace of innovation. 

The Value of a Salesforce Governance Model

One of the primary jobs of a Salesforce COE is to establish and enforce an effective governance model around the platform. In essence, to provide the structure – the systems, principles, and processes – that a growing organization needs to take full advantage of a platform like Salesforce. 

Salesforce has become a sophisticated platform that can now cross multiple functions and touch nearly every role in a business. Without some kind of governance model in place, IT teams and their business partners will spend more time dealing with conflicts and managing rework than making sure the organization is using the system to its fullest potential. A governance model helps in three ways:

It aligns system decisions with business priorities.

As requests for new features, fixes, or components come in, a governance model can make sure they are evaluated and prioritized in a way that will have the greatest business impact and will ensure the appropriate people are involved in making decisions.

It speeds decision-making.

A governance model lays out who is responsible for what and establishes decision criteria and dependencies at the outset to make sure decisions can happen fast and not get stuck in limbo.

It increases system usage and adoption.

The processes and principles laid out in a governance model make sure executives and stakeholders are involved in key decisions and milestones, which not only helps identify issues early on but also increases support and communication around changes. More on change management later in this blog.

How to Establish a Governance Structure That Works

A governance model can’t be created in a vacuum. It needs to be a collaborative effort between the business and IT. However, the enforcement of it ultimately rests with the COE lead, or in larger organizations, a governance board. Below is an example of how a medium to large organization might structure its governance model and the groups that are involved. In a smaller organization, you might have members spanning multiple committees, roles, and responsibilities.

Governance model for Salesforce Center of Excellence
The groups and responsibilities for an effective Salesforce governance model

For more details on the specific roles within a COE and these steering committees, check out part 2 of our COE blog series

A COE’s Role in Communicating and Managing Change

Change management is something that needs to be thought through for any major business investment, and it is a critical function of any Salesforce COE. I separate change management into two areas — managing change with people and managing change within the system.

Let’s start with the people side as that’s typically the more difficult aspect of change management. Plenty has been written about humans’ natural resistance to change, and how change triggers our instinctual fight or flight mechanism. However, research also shows that if you can help people understand what change is coming, why it’s happening, and how they might benefit, they are much less resistant to that change. Even better if you can get them involved early on. Once people are bought into what’s coming and why, giving them the tools and time to deal with change in their own way can make the difference between success and failure. 

Salesforce COEs play an important role in evaluating how new features or changes to Salesforce will affect an existing implementation and the users who depend on that functionality. A COE should establish a two-way communication structure to communicate changes early and often and make sure feedback from affected parties reaches the appropriate decision-makers. Unfortunately, many companies take the Field of Dreams approach of “If we build it, they will come.” That only works in movies, and there is no such thing as too much communication when it comes to change management.

Once changes are decided upon, communicated, and built, it’s time to take them to primetime and release them. This gets us into release management, which is essentially the process by which you introduce change into your Salesforce environment.

Move Fast But (Try Really Hard Not to) Break Things

Release management relates to planning, scheduling, and managing a software build through different stages and environments, including testing and deploying software releases. Some companies release continuously, which means as features are developed they move through different testing and production environments in near real-time. Others stick to milestone release schedules where features are released in bulk on a scheduled basis. You can read more on how leading organizations handle release management in our Salesforce Best Practices research.

Whether you are a large organization releasing continuously, or a small organization with a few external developers releasing once a year, it’s critical to establish a process for how you are going to move changes into production. We see too many people not using the developer sandboxes that come with their Salesforce licenses, and working directly in production. If you do this, 10 times out of 10, you will get an error or will end up overwriting or breaking something in production. 

There is a range of tools to help Salesforce teams manage releases – from Salesforce Change Sets at the basic level to more sophisticated tools like 10K Connect which can instantly simulate a deployment and validate changes before they are pushed to production. The important thing is to pick a tool and process and hold to that.

All of this takes a certain level of time and preparation. A governance model isn’t established overnight, and it should be evaluated on a regular basis to make sure it’s still working inside the organization. Change management and release management processes take time and forethought to establish and enforce. But I guarantee you that a small investment up front will pay dividends down the road for your users and the overall health of your Salesforce system. 

Part 5 of our COE series covers how to give end-users the support they need and how to ensure their feedback is incorporated into your Salesforce roadmap. 

Download our guide to maximizing your Salesforce program ROI.

How to Build a Well Oiled Delivery Machine for Your Salesforce COE  (Part 3 of 6-part COE series)

Our last blog in the Center of Excellence (COE) series described the team, roles and structure that will help organizations run a highly successful Salesforce program. In this blog, we’ll focus on how those experts work together and execute in the most efficient and productive way possible.

Let’s start at the beginning. The purpose of a COE is to manage your Salesforce system in a way that delivers on near-term needs while ensuring long term performance, and that all comes down to execution. More specifically, managing your implementation as part of a cohesive program, not a series of one-off projects. It’s not unlike a relationship. Serial dating might keep you busy and happy for a while, but if you want a long-term relationship, you’re going to have to put in some work. And like any relationship, it’s always good to set some standards upfront.

Set Your Standards

Standards set the bar for what is expected, and establishing them at the outset will ensure teams understand what is expected of them and result in higher quality deliverables. Standards, if they are set early and communicated often, will also help guide internal team members and external vendors to look at the Salesforce system in a cohesive way, ultimately reducing your technical debt over time. For Salesforce COEs, at a minimum, you should be considering technical standards and delivery standards.

Technical standards include things like:

Metadata creation: These are things like naming conventions, descriptions, and the help text that will help give you a more consistent and easily maintainable implementation.

Feature usage: Depending on the specifics of your implementation and the skillsets of your team, you may choose to use certain Salesforce features over others. Documenting how and when to use features like workflow, process builder or flow, versus writing code, is an important distinction to make. This also extends to how you use add-on features such as CPQ or Field Service Lightning in conjunction with the standard Sales and Service Cloud features. 

Coding: Coding standards ensure your developers (which may be in-house or outsourced) craft code that is easier to maintain, and if done correctly, performs better. This includes documenting naming conventions, code style and structure, the use of trigger frameworks, test classes, and more. Here is an example of what a document like that might look like, albeit dated.

Delivery standards include things like:

Requirements definition standards: These definition standards outline what information has to be included when defining user-centric requirements and ensures that those collecting and writing requirements know which questions to ask. This will also guide how to document the answers, which will allow for a more efficient handoff to the delivery team.

Success criteria/metrics: One of the most important questions you can ask your business stakeholders when interviewing them is “How will you measure success?” This can sometimes be a challenging question to answer, but it is very valuable as it adds context to the requirements. It will also help ensure the solution is designed in a way that allows stakeholders to achieve those measurements.

User acceptance criteria: Along the same lines as success criteria, user acceptance criteria provides context around the specific actions that users of the solution should be able to accomplish. When these are clearly defined they are not only helpful in solution design but also very effective for quality assurance and testing.

Proposed solution design: This is a written and/or visual explanation of how a solution should be developed and includes information about the technical components that should be used by the delivery team. This is very useful for stratified teams where an architect or tech lead reviews a solution design prior to development.

Define Your Delivery Process

Once you have your standards documented and communicated, you need to think about how the delivery process will work across your Salesforce COE. There are many different delivery methodologies that range from agile to iterative to waterfall to everything in between. Which delivery process you choose will depend on your organization’s overall maturity in IT delivery. Some companies enforce a business-wide set of processes that are tightly coupled across teams while others allow more autonomy. The majority of companies today use some sort of agile-like process, ranging from strict adherence to Agile methodologies such as Scrum to a basic iterative, story-based process. 

Delivering on the Salesforce platform is different than most other technologies because Salesforce is both easier to customize and sees more frequent platform updates. Salesforce issues three releases and hundreds of new platform features every year, so regardless of your situation and your broader IT process, you’ll likely want to tailor certain tenants of your delivery process. For example, our research into Salesforce Best Practices shows that more than half of Salesforce program owners do production releases at least every other week or more often. This may be different than how other systems are handled in your organization. 

Frequency of Salesforce production releases
According to 10K’s Best Practice Research, more than half (55%) of Salesforce program owners release AT LEAST every other week.


Plan Holistically

As you outline your process, it’s important to think about it as a journey and consider every milestone along the way, from the moment work has been scheduled to when it is released into production. In our experience, work typically breaks down into the following major categories:

1) Requirements definition, sizing, scoping

2) Backlog review and scheduling

3) Capability delivery (development, testing)

4) Release (environments, regression testing, production)

Each gate should have clearly prescribed entry and exit criteria, including who is responsible. Here is an example of the entry and exit criteria that we use for 10K Connect:

Entry and Exist Criteria

One of the best ways to document the different steps and owners is to create a swim lane diagram, which is a high-level flow outlining the end-to-end delivery process and the interdependencies. For more complex processes, it may be helpful for you to create multiple diagrams. For example, one outlining the high-level delivery flow, one for the detailed development process, and one for release management.

Swim lane diagram

Once you’ve documented your definitions, process, and owners, don’t forget to communicate it!  You can’t hold people accountable if the standards and process aren’t communicated clearly and often. Using tools that align with your specific delivery process (vs. a generic tool, or worse no tool at all) can help immensely with communication and ensure your teams will adopt the right process. 

Part 3 of this series covers release and change management. It will also highlight the COE’s role in governance and ensuring the process, standards, and flow are top of mind for everyone involved. 

Download our guide to maximizing your Salesforce program ROI.