Skilling Up for the Implementation Lifecycle

  • As Salesforce has moved from a tactical application to becoming a strategic application, the Salesforce community has recognized a need to take a more rigorous approach to implementation.
    • Can no longer just create a few new objects, onboard a few users, and call it a day.
    • Increasingly, changes can have huge downstream implications and it is necessary for organizations to have broad strategic alignment before making some changes.
    • This presentation is about the skillsets required to navigate the stages of the implementation lifecycle as quickly as possible, but also as safely as possible.

  • Four Phases to Implementation Lifecycle
    • Analyze: Capturing and understanding requirements
    • Build: Building/coding the application
    • Deliver: Loading data and getting into production
    • Operate: Monitoring in production, getting feedback

  • Couple considerations to the lifecycle
    • Adoption: Whatever we are building should be driving adoption - licenses are expenses if no one is using them
    • Agility: We should go through the lifecycle as quickly as possible to be agile, but no steps in the process above can be totally left out
    • Trust: Trust is also a critical part of the process. There is no point rushing a release only to find out it doesn’t work and we need to start over.

  • Documents: As we implement, there are a series of documents we create that are used and re-used as we go around the cycle
    • Analyze phase: capturing requirements, mapping business processes, modelling data, doing org analysis. All these documents are reused in the build phase.
    • Build phase: User stories are the critical document that admins/developers need to go and build the applications. First, test against user stories. Then for User Acceptance test, we test against process maps.
    • Deliver phase: using the data models and org analysis to understand how to do the data loads. Releasing both the processes and the new application into production.
    • Operate phase: use the process diagrams to make sure our end users know what their requirements are from a regulatory perspective. Use the processes as part of training.
    • Takeaway: Need to be careful not to create document silos during implementation. Reuse the same documents whenever possible so information isn’t copied into something new.

  • Handoffs from one phase to another - Should not move from one phase to another unless you are very clear you have finished the prior phase
    • Tendency is to rush into build because Salesforce makes building so easy - need to resist this
    • Admins/developers need to be very clear that they need a better idea of what the users actually need before building
      • If the new functionality is not exactly what the users need, then they will not use it
      • Should only move onto the build phase when very crisp and clear user stories have been developed
    • Reenter the loop when there is feedback on the functionality or issues with adoption

  • Biggest issues with the overall development process observed by presenter Ian Gotts:
    • Poor business analysis resulting in people rushing into build
    • In the build phase, poor consideration of architecture, which comes back to bite people later
    • Lack of overall understanding of the implementation lifecycle and its phases

Analyze Phase

  • Phase involves:
    • Capturing feedback from users
    • Translating into business requirements
    • Creating business process maps
    • Modeling data, creating ERDs
    • Developing user stories
    • Org risk impact analysis - depending on the risk to the org, may take different development paths.
      • High risk - formal, multiple sandboxes
      • Low risk - straight into production

  • Green boxes come straight out of “Operate” phase
    • Raw feedback from users
    • Optimization/cleanup identified (IE getting rid of technical debt)
    • Raw requirements from users are distilled into “validated requirements” that are finally mapped into processes and “final requirements,” which are then translated into user stories
    • “User stories” are the technical requirements that are sent to the developers
    • User stores are used to perform risk analysis. Three perspectives on risk:
      • Operational risk: how much the business is going to change
      • Technical risk: what is likely to break
      • Regulatory risk: are there any potential compliance issues?
  • There is other content on Trailhead that breaks down the Analysis phase in much more detail

Build Phase

  • Build starts when we have some crisp user stories and is finished when we have a tested app
  • Key skills:
    • Architecture design: very important as we’re building relatively complex and strategic applications in Salesforce. Better to get the right architecture the first time as re-architecting is difficult.
    • Declarative - Declarative coding is also known as “configure” - Search for #LowCodeLove to find examples.
    • Coding - Salesforce & integrations
    • Testing - manual and automated, especially acceptance testing
  • In all steps, necessary to track why we’ve done something - documentation

Deliver Phase

  • Terminology/Acronyms:
    • ALM - Application Lifecycle Management
    • CI/CD - Continuous Integration / Continuous Deployment, has become very popular
    • DevOps - Developer Operations, been around for a while now
      • Book: “Mastering Salesforce DevOps” by Andrew Davis
      • Huge amount of information available how to drive the DevOps cycle, thinking multiple sandboxes, driving through a deployment pipeline, thinking about metrics you need to measure to understand how to improve CI/CD cycle
  • Deployment pipeline
  • More complex Salesforce implementations can mean more complex data models
  • Release management

  • Screenshot above is from the trail on ALM

Operate Phase

  • In Operate phase, the application is in production
    • User Adoption hopefully is high
    • Org metrics
      • Can monitor what Salesforce users are doing, see which screens are being most frequently used, think about how screens are optimized
      • Fewer fields is better, page layouts load faster
      • Lots of techniques for improving user experience
    • Backup/restore
    • Regulatory compliance
      • More than “do we have data privacy in place”
      • Make sure users are following due process

Takeaways

  • The implementation lifecycle requires different skillsets
    • Solo admins need to “wear a lot of hats”
    • Teams need to understand where the handoffs are between you and the different groups
    • Salesforce ecosystem is very supportive in terms of helping you gain those skills
  • Accelerate implementation, but DO NOT skip steps
  • We are now building “strategic applications”
    • Skills on this page are fundamental skills
      • Architecture skills, Analytic skills, configuration skills, declarative/programmatic coding skills

Resources