Over the last 20 years, Salesforce has evolved from a cloud sales automation app to a platform that can support any business process and link to every legacy application. This power and sophistication mean that Salesforce implementations have become increasingly complex. So we are seeing several established implementation approaches emerging in the Salesforce ecosystem. And to support them, Salesforce is now developing training in Trailhead, creating certifications, and presenting at events.
These are Business Analysis, DevOps, and a Center of Excellence. They are not discrete approaches, but actually complementary and work together as you can see from the diagram below.
Let’s look at each in turn:
Business Analysis (and Config Knowledge)
As the diagram says, the key is to make sure that development is building the right thing. This means really understanding the users’ pain points, capturing their requirements, and mapping their business processes to validate the true need. It is also critical knowledge of the configuration of the Salesforce and other systems. The output of this analysis is crisp, clear user stories that can be passed to the development teams.
The analysis should also uncover the risks – operational, regulatory, and technical – in making the changes. This risk analysis enables the development teams to allocate the right level of development and test resources to user stories and the business to understand the change management and training effort required.
Too often projects rush through the analysis phase and start development too early. Whilst it initially feels like it is accelerating the delivery, it introduces rework to correct misunderstandings in the requirements or because config conflicts are discovered in build, test, or production. There is a concept called “Shift Left”. The earlier you find issues, the cheaper they are to fix i.e further left in the implementation lifecycle. Finding and resolving business or technical issues during analysis is 10x cheaper to fix than finding them once the system has gone live.
The results from good business analysis are stunning; 80% reduced rework. 25% process improvements.
DevOps (Development Operations) takes the user stories and through clicks or code turns them into working applications in production. The DevOps approach is applying a more methodical, rigorous, and measured approach to development, test, and release. It means taking the entire development cycle and looking at how different risk user stories take different development paths so low risk can be fast-tracked and high risk are taken through the full development and test pipeline.
The metrics are release cycle time (how often you release), roll-backs (how often you need to reverse a release due to an issue), speed of recovery (how long it takes to roll back).
The benefit of a clearly understood development process is that parts of it can be automated to increase speed of release and at the same time increase app quality. For example if you have strong code control and all changes are managed centrally then it is easier and faster to deploy. Just think of the time saved by not creating change sets!! But also it enables automated testing and regression testing which saves time and improves quality.
Center Of Excellence
The Center Of Excellence (COE) is not a team but is a series of guiding principles for great Salesforce implementations. You need to think about “excellence” rather than “center”. These principles are described below as the 13 COE pillars. The other thing to remember is that there is a COE maturity model. Not every implementation will have all 13 pillars mastered. But what is clear is that the more complex and strategic the implementation, the more important it is to have all the pillars in place.
In the 10K Program to Project study, they discovered that 91% of the highest ROI Salesforce implementations have a Center Of Excellence in place.
Here is an overview of each of the pillars.
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 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: the technical architecture of Salesforce and how it relates to the integrated systems and InfoSec
Security: like architecture, security needs to be designed in particular as cloud systems have so many integrations that can introduce vulnerabilities.
Change management: communications, organizational change, and training to get Salesforce adopted
PMO: the Project Management Office that manages the COE activities, managing the program streams and KPIs
Tooling: platforms/apps/ tools used to support the project
Prototyping: an innovation hub that builds out Salesforce prototypes to show the “art of the possible”
As Salesforce has become a strategic application in the enterprise IT landscape, the maturity of the change cycle has had to increase. The approaches we’ve grown up with for enterprise on-premise application implementation are now evolving to support SaaS and Salesforce. The good news is that we don’t need to make these up from first principles. History can be a great teacher.
Guest post by Ian Gotts, CEO of Elements.cloud