Transition Plan (TP) Improving Thai CDC Establishing a New Client/Donor/Partner Communications & Project Tracking Tool Team #: 01 Team Members & Roles Name Primary/Secondary Role Brandon Foster IIV & V/Development Ding Li Life Cycle Planner/Software Architect Yi Li Feasibility Analyst/Requirements Engineer/Test Ino Mantaring Requirements Engineer/Prototyper Chas Muckenthaler IIV & V/Quality Focal Point Vishal Punjabi Operational Concept Engineer/Prototyper/Development Katelyn Swift-Spong Manager/Operational Concept Engineer/Development 11/21/2011Transition Plan (TP) Version: 1.0 TP_TRR_F11a_T01_V1.0 ii Version Date: 11/21/2011 Version History Date Author Version Changes made Rationale 11/21/11 BF 1.0 Composition of the initial draft Initial draft for the TRR package deliveryTransition Plan (TP) Version: 1.0 TP_TRR_F11a_T01_V1.0 iii Version Date: 11/21/2011 Table of Contents Version History ...................................................................................................................... ii Table of Contents ................................................................................................................. iii Table of Tables ..................................................................................................................... iv Table of Tables ..................................................................................................................... iv Table of Figures ..................................................................................................................... v 1. Transition Strategy ............................................................................................................................................. 1 1.1 Transition Objectives .................................................................................................................................................. 1 1.2 Transition Process Strategy ......................................................................................................................................... 2 2. Preparing for Transition ..................................................................................................................................... 4 2.1 Hardware Preparation ................................................................................................................................................ 4 2.2 Software Preparation .................................................................................................................................................. 5 2.3 Site Preparation .......................................................................................................................................................... 5 3. Stakeholder Roles, Responsibilities and Schedule ............................................................................................. 7Transition Plan (TP) Version: 1.0 TP_TRR_F11a_T01_V1.0 iv Version Date: 11/21/2011 Table of Tables Table 1: Transition Schedule ......................................................................................................................................... 7Transition Plan (TP) Version: 1.0 TP_TRR_F11a_T01_V1.0 v Version Date: 11/21/2011 Table of Figures No table of figures entries found.Transition Plan (TP) Version: 1.0 TP_TRR_F11a_T01_V1.0 1 Version Date: 11/21/2011 1. Transition Strategy The Transition Strategy lays forth the objectives and processes necessary for transitioning the cloud-based CRM tool from the implementation team’s development and administrative control into the customer’s domain and control. The strategy aims to limit any miscommunication or confusion regarding between the implementation team and customer by identifying the tasks and activities each team (development versus client) is responsible for. 1.1 Transition Objectives Several objectives are laid forth below to ensure that the customer’s CRM solution is successfully transferred from the development team into the hands of the customer. Objectives include, but are not limited to, capabilities to be delivered, support and maintenance expectations, validation techniques, etc… Extent of Capability Transitioned: o The development team will be delivering a fully operational cloud-based CRM solution to the client/customer. Fully operational is defined as a solution that delivers all of the core capabilities, levels of service, organizational goals, and constraints outlined in the OCD and Winbook. Number and Nature of Transition Sites: o The provided solution will reside in a single site that is on the servers of Salesforce.com. Salesforce.com is a NCS/NDI vendor offering cloud-based CRM solutions and provides all facilities required to run a cloud based CRM deployment. The site is homogenous with access being available to Thai CDC users with a valid Salesforce.com licenses. Degree of Validation of Operational Satisfaction of Stakeholder Objectives: o Operational Satisfaction is validated through several processes of the ICSM-Sw EPG. These processes include Team Meetings, Client Meetings, Win-Win Sessions, Architecture Review Board Meetings, and product validation Team Meetings – weekly meetings were held to address any problems in developing and delivering the core capabilities of the system. Risk mitigation plans of execution were constructed to address any problems. Client Meetings – developers and the client held meetings to discuss the status of development, exchange any information regarding difficulties and successes, and identify any potential evolutionary features that the client would like to have. Win-Win Sessions – implementation team and client routinely discussed requirements and issues/concerns with new requirements. EachTransition Plan (TP) Version: 1.0 TP_TRR_F11a_T01_V1.0 2 Version Date: 11/21/2011 requirement was then qualified as feasible or not and further quantified using a TOPSIS approach. ARBs – opportunities for the client to see how the system has progressed towards their goal of the delivered system. Clients can provide feedback on expectations being met or not, and from the ARB results the development team knows if rework is required or if the operational capabilities are met and the team should proceed further. Product Validation – each component of the system is validated and reviewed for correctness by
View Full Document
Unlocking...