Regardless of the path that you take for implementation, preparation and knowledge can help lead a smoother transition. A typical rollout comprises of a development life cycle
- Plan: A clear plan helps you to communicate with everyone, to do things in the right order, identify key resources, and know when you’re done.
- Discovery: This phase helps to prepare for analyzing phase. It includes conversations with key stakeholders to understand the current system and processes (if one exists) or gather requirements.
- Analyze: Discuss opportunities for business value. Revisit your current processes and determine how they can be improved upon during your move to Service Cloud.
- Design: Map out the use cases that you captured in the Analyze phase, and consider the design options within Salesforce that are user friendly and easy to navigate.
- Build: Begin building out your sandbox with the features from the Design phase.
- Validate: Have a few of your top agents test the configuration with the use cases identified in the Analyze phase. Capture their feedback and make modifications to your sandbox. Import some Desk.com data into your sandbox to use in agent testing and training, as well as to confirm that the data can be imported as expected.
- Deploy: Your configuration is now complete, and you’re ready to train all of your agents. After training, import your configurations to your Production org and all of your desired data from any existing ERP/backend to Salesforce.
- Kickoff meeting with the consulting teams
- Confirmation of resources and their roles
- Come up with a clear communication plan by setting up governance.
- Client team kickoff – Introduce consulting team, align on project purpose and scope
- Project plan sign off – to ensure alignment
- Components of Project Plan
- Describe the purpose of the project and what business value it is about to deliver
- This section should include a few paragraphs describing, at a high level, the key elements of the project that are detailed throughout the project plan.
- It must be determined which organizational objectives will be supported by undertaking the project.
- The purpose and objectives of the project should be stated in this section.
- There should be the definition as to the scope of the project as well as the major deliverables.
- The product breakdown structure (PBS) and the work breakdown structure (WBS) will be determined here.
- Quality specifications will also be included in this section, describing the product or service performance criteria from a customer perspective.
- Project assumptions should also be included, clarifying grey areas in the project scope.
- Communication Plan:
- Describe how and when the various details of the project, resulting in changes, milestones and gathering required inputs will be communicated to all stakeholders.
- Address how communication will be conducted at all stages of the project to help increase adoption.
- In this part there should be a description of the system of communications and the project performance documentation that will be provided to the various stakeholders.
- Budget/cost estimate – Estimates are required for the project duration. Costs are typically divided into three types: capital items, expense items, and labour.
- Roles and Responsibilities:
- Identify who from the customer and implementation partner will be involved.
- Define the project team organization, roles and responsibility requirements.
- this section should define space, any additional hardware/software, and other resources needed to complete the project successfully.
- Change Management Plan
- Assess level of change readyness and plan how ease transition to and adoption of the new system.
- Training Plan
- Analyze how job roles will change as a result of implementation of the new system.
- Identify who needs to be trained, when and how.
- Plan train the trainer sessions to allow customers to train their end users.
- Project Risks
- Identify risks to the project and mitigation actions that can be taken
- This section will detail the process to be employed on the project in order to manage risk.
- The contents of this section will define the milestones and activity schedule of the project, integrating three key elements: deliverables, due date or duration, and critical dependencies.
- Sets out the plan for when the milestones of the project will be completed to ensure timing corresponds with customer expectations.
- List of deliverables that will be produced as part of the project
- Approvals – This section will capture approval signatures from project stakeholders.
- Attachments – Included in this section will be pointers to pertinent documents such as the business case, notes, and related documents.
This phase helps to prepare for analyzing phase. It includes conversations with key stakeholders to understand the current system and processes (if one exists) or gather requirements.
- Key Activities
- Prepare a questionnaire to gather information from the customer.
- Discover interviews with key stakeholders to understand their day to day activities and pain points.
- Understand the as-is process.
- Observe interactions with the current systems.
- The requirement analyst should identify the problem along with the business users and define it accurately. The requirement definition should be able to provide information on:
- The problems the solution is aimed to solve
- The benefits expected from the solution
- Key Information to Gather
- Organizational Chart
- Process Maps
- Report samples
- Requirement docs from previous system implementations
- Source system fields, validation rules, and business rules.
- Key Activities
- Gathering requirements by hosting workshops with key stakeholders
- Prioritizing requirements and confirming the business value
- Documenting workshop results
- Identifying any gaps between requirements and scope defined in the project plan.
- Obtaining signoff of the requirements document.
- Tips for successful requirements gathering
- Establish project goals and objectives early
- Document every requirements elicitation activity
- Be transparent
- Talk to the right stakeholders
- Don’t make assumptions
- Practice active listening
- Focus on Business requirements, not tools.
- Confirm, Confirm and Confirm
- Prioritize your product features.
- Remember that you did not get everything.
The Design Phase seeks to develop detailed specifications that emphasize the physical solution to the user’s information technology needs. The system requirements and logical description of the entities, relationships, and attributes of the data that were documented during the Requirements Analysis Phase are further refined and allocated into system.
A formal review of the high-level architectural design is conducted prior to detailed design of the automated system/application to achieve confidence that the design satisfies the system requirements
In addition, the work planned for future phases is redefined, if necessary, based on information acquired during the Design Phase.
- The Design Document is developed by the Project Manager and Integrated Project Team, identifying the steps used in the design of the application/system.
- In the system design
- system characteristics are defined.
- The data storage and access are designed.
- The user interface is designed.
- The business rules layer or the application logic is designed.
- The interfaces from application to application are designed and documented.
- In the solution design, major use cases are prototyped to give the client a clear vision of how the system will look
- The technical design will include any customizations that require code development.
Roles and Responsibilities
- Business owner may participate in preliminary design reviews
- Project Manager is responsible and accountable for the successful execution of the design phase. PM is also responsible for leading the team the accomplishes the phased activities
- Integrated project team members are responsible for accomplishing the assigned tasks as directed by the project manager
The Build Phase features a key step in the project: system construction. The previous phases lay the foundation for system development; the following phases ensure that the product functions as required. To complete the Development Phase successfully, two elements are required: 1) a complete set of design specifications and 2) proper processes, standards, and tools.
The purpose of the Build Phase is to convert the system design prototyped in the Design Phase into a working information system that addresses all documented system requirements. At the end of this phase, the working system will enter the Validation Phase.
- Building the system
- Testing and integrating the units into larger components
- Preparing the technical environment for the system
- Approval to progress to the Validation Phase
- Ensure there is a common understanding among Development Team members and Stakeholders
- Application configuration and customization will be done during this phase in lower environments (Sandbox).
- Any custom code development is done during this phase if the configuration options are wetted out as not helpful.
- Alpha and Beta reviews will be performed to confirm the configurations and customizations are meeting the requirements.
- Data migration build and review is also performed.
- Unit Testing is also performed during this phase to ensure at least 75% (an organization can set a guideline internally to have a threshold of 90% or high for avoiding maintenance issues) of code coverage is in place for the custom code that is developed.
- Documentation is also done during this phase that includes
- Training Material development.
- User Manuals
- Technical approach documentations
One of the most important phases of project management is known as validation.
Validation is the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Simply “Are we building the right system? Concerned with the customer”
- Testing including UAT, SIT, Performance, and End to End
- Sample Data migration Validation
- Validate configurations and code
- Iterations to validate, test and fix bugs
- Signoff to proceed to go-live.
- Moving configuration and custom code from lower environment to production.
- Data migration into Production from back-end systems
- Project Signoff
- Gathering project feedback via Customer Satisfaction Survey
- Scheduling training sessions.
- Transferring knowledge to support.
References and Trailhead Links
Develop your Implementation Plan: https://trailhead.salesforce.com/en/modules/desk-com-to-service-cloud-transition-plan/units/develop-your-implementation-plan