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.
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:
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.
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.
