# 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
• 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
• 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”