Over the coming weeks we are going to explore each of the 13 pillars of a Center of Excellence (COE). In this article we are going to look at the 4th: Change Control. In each article for each pillar we will set out the scope, look at what success looks like and explore the tools and techniques you need to master.
Center of Excellence – 13 pillars
Whilst every organization is different, there are some common aspects. No matter what size of project, these need to be established. These are activities, not roles. The smaller the project, the lighter the touch. As background for this article, here are the 13 pillars of a COE
• Vision: strategic vision and direction for Salesforce for both the business and IT (link to article)
• Leadership: Steering Committee and key sponsors in business and IT (link to article)
• Governance: overall control of strategic direction, business cases, investment and risk management (link to article)
• Change control: management of changes to all aspects of the project
• Methodology: the implementation methodology covering 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 and data architecture of Salesforce and how it relates to the integrated systems
• Security: like architecture, security needs to be designed in, not bolted on as an afterthought.
• 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
• Innovation: innovation hub that builds out Salesforce prototypes to show the “art of the possible”
Scope / approach
This is tightly tied into Governance, the 3rd pillar. Governance is the overall approach for agreeing and signing off on changes to scope at all levels – vision, roadmap and release.
Change control is the blocking and tackling. How are you going to capture the suggested changes, which will be presented at very different levels of granularity and completeness. It could be as high level as “We need to satisfy CCPA. the regulatory standard” or “We should leverage AI – such as Einstein or ChatGPT
Tools and techniques
Below are the tools you can use to manage changes to the different types of “content”
These should be captured centrally so that they can be managed, prioritized and tracked. Many people use spreadsheets or build a custom object in Salesforce, or use Jira. Spreadsheets do not really do enough in the complex world of Salesforce changes. The custom object will quickly become almost an app in its own right.
The power is the ability to link to different types of supporting content, manage through a set of stages with notifications as stages change.
To map the processes you should use the UPN approach. It is easily understood and shared. They app needs collaboration features so you can capture suggested changes and version control so that you can track changes. Elements.cloud is the only application with all these features.
#expertsreact with Jim Boots on selecting a process mapping tool
Salesforce Diagrams is the predefined notation for the different architecture diagrams. There are just a few applications that support the notation. However from a change control perspective you need similar features as process diagrams; hierarchical mapping, collaboration, version control. Again, Elements.cloud is the only application with all these features aht supports the Salesforce Diagrams notation.
User stories / work items:
These are the hand-off between the business analysts and the developers. So they are typically created by business analysts with a lot of the business analysis documentation linked to them. This could (or should) be in Elements.cloud because power is in the ability to link to different types of supporting content, manage through a set of stages with notifications as stages change. But the developers may want track the user stories in a ticketing systems like Jira. But Jira is often overkill for the business analysts. So there needs to be a seamless integration
Changes to metadata need to be documented so that you have a change history that can be referred to when future changes are made. This is so the impact of any change can be assessed quickly.
First there is a metadata dictionary for each Prod and Sandbox org with all the metadata items, which is kept in sync. This enables system generated documentation such as core metadata information, impact assessment, dependency analysis, usage analysis and data population. This needs to be kept refreshed as metadata is added or changed.
The metadata dictionary can also track the changes that are made to metadata, so the difference between versions can be easily understood.
Then there is manually created documentation that can be in many formats – requirements, user stories, architecture diagrams, process maps, video, wireframes, photos of whiteboards, screenshots etc etc etc. Some of these items needs to be linked to multiple metadata items. They all need some form of change control.
Metadata and code:
The master version of declarative changes is the org are they often managed by ChangeSets. Developer changes are stored in a source control system (e.g GitHub). But with Salesforce DevOps Center, the free replacement for ChangeSets, all metadata changes are stored in a GitHub source control system. THis ensures a more rigorous and consistent approach to development
For more information on this approach check out the Salesforce DevOps Center Implementation Guide.
All the above change control activities are covered by a DevOps platform