SOFTWARE SYSTEMS IMPLEMENTATION PLAN TEMPLATE

SYSTEMS IMPLEMENTATION PLAN

PROJECT TITLE
PROJECT MANAGER	PROJECT SPONSOR	DATE INITIATED

PLANS	WHERE TO FIND
Implementation Strategy	This Document
Testing Strategy	This Document
Knowledge Transfer and Training Plan	This Document
Operational Impact Specification	This Document

Help Using This Template Delete this box after reading. The systems implementation plan is the hub for all planning activities associated with developing and implementing an information system. The plans included in this template should be removed, updated, or extracted to suit project needs. Projects that require custom software development will need far more planning around design, construction, and testing. This page should provide hyperlinks to all plans, whether in this document or elsewhere.

IMPLEMENTATION STRATEGY

COMPONENTS TO BE IMPLEMENTED

COMPONENT NAME	DESCRIPTION OF FUNCTION	SOURCE
<Application>	<A brief description of what the component does>	<Developed in-house, custom developed by a contractor, off the shelf, etc.>
<Module>
<Database>

DEVELOPMENT APPROACH

<This section briefly describes the development model that will be used, for example, Waterfall, iterative, evolutionary, prototyping, Agile, etc.>

INTEGRATION APPROACH

<This section identifies dependencies and the sequences in which components will be integrated and tested. A diagram could be substituted or added to show connection points to other systems.>

IMPLEMENTATION STRATEGY

<The implementation strategy should cover the following topics: Implementation environment and facilities Methods and tools Deliverables for the user community, including training Identification of deployment sites>

CONVERSION STRATEGY

<The conversion strategy should describe how legacy data is being handled. It describes the overall approach and covers the tools, techniques, sources of data, challenges, etc.>

DEPLOYMENT STRATEGY

<This section presents the overall deployment strategy by addressing the elements needed to deliver the system to identified sites. It covers activities, tools, locations, people, etc.>

Help Using This Template Delete this box after reading. The implementation strategy is a high-level plan of how the system will be implemented. First, the system is broken down into components that are described, and then aspects of implementation are described. Add or remove sections to suit your particular needs. Identifying your approach early on can be useful for planning costs, scope, and time.

TESTING STRATEGY

DEPLOYMENT ENVIRONMENTS

NAME	TECHNICAL DESCRIPTION	USAGE DESCRIPTION
Development	<Hardware, software, CPUs, etc.>	<Purpose, frequency of updates, stability, etc.>
Functional Testing
User Acceptance Testing
Production
<Other Environments>

ENVIRONMENT CONTROL APPROACH

<This section describes how the various environments will be updated and used. It covers deployment tools, schedules, etc.>

PLANNED TESTING ACTIVITIES

TYPE OF TEST	DESCRIPTION	FREQUENCY
Unit Testing	<Describe method, tools, people involved, effort, etc.>	<Every x days, before major releases, etc.>
Integration Testing
Load Testing
User Acceptance Testing
<Other Tests>

DEFECT TRACKING AND RESOLUTION APPROACH

<This section describes how defects arising from testing will be tracked and resolved. This should coordinate with the overall quality management plan in the project management plan.>

Help Using This Template Delete this box after reading. The testing strategy defines, at a high level, how testing will occur. Testing generally involves periodic deployment to various environments and the involvement of various testing groups. Testing should cover a broad range of areas, such as functional testing, load testing, performance testing, user acceptance testing, integration tests, unit tests, etc. Planning how the system will be tested and what hardware/software will be required helps you plan costs, assign roles, and coordinate with the TSC. Lastly, the approach to defect-tracking and resolution should be described, including any tools and processes to be used.

KNOWLEDGE TRANSFER AND TRAINING PLAN

KNOWLEDGE REQUIREMENTS

KNOWLDEGE AREA	KNOWLEDGE GROUP	REQUIRED OPERATIONAL GROUPS
<Technical Knowledge>	<Who on the implementation team knows about this area?>	<Who on the operational team needs to know this area?>
<System Knowledge>
<Application Knowledge>
<Other Areas>

KNOWLEDGE TRANSFER PLAN

TRANSFER ACTIVITIY	AUDIENCE	PERSON RESPONSIBLE	TIMEFRAME
<Produce Operations Manual>	<Who on the operational team is this activity intended for?>	<Who on the implementation team is responsible for this activity?>	<Dates, times, frequency, etc.>
<Conduct Workshop>

TRAINING REQUIREMENTS

USER GROUP	TRAINING NEEDS	SIZE OF GROUP	LOCATION OF GROUP
<Admins>	<Roles, modules, functions>	<# people>	<HQ, communities>
<Users>
<Other Groups>

TRAINING PLAN

TRAINING ACTIVITY	AUDIENCE	TRAINING TEAM	TIMEFRAME
<Production Guide>	<Who is this activity intended for?>	<Who is involved in delivering this training?>	<Dates, times, frequency, etc.>
<Workshop>

Help Using This Template Delete this box after reading. The knowledge transfer and training plan describe the activities that will be undertaken in the critical areas of knowledge transfer (operational team) and training (end users). Planning these activities early on is helpful in cost estimation, resource allocation, scheduling, etc. This plan can be used as the basis of developing a full training schedule later on. It can also help you coordinate the transition of operations to the operational team and the TSC.

OPERATIONAL IMPACT SPECIFICATION

OPERATIONAL PROFILE

Operating Hours	<7 days - 24 hours per day, 6 days - 22 hours per day>
Expected Availability	<high availability: 99.5%>
Expected Reliability	<fault tolerance: 99.9%>
Peak Busy Hours	<09:30 - 10:30 hours, 13:00 - 14:00 hours>
Maximum Tolerable Outage	<For example, how long can the system be offline? 2 hours, 24 hours, 48 hours>
Backup Window	<daily between 23:00 - 24:00 hours, weekend availability>
Backup Requirements	< full backup once a week, off-site requirement>
<Other Specifications>

GROWTH ESTIMATES

Year 1	Year 2	Year 3	Year 4	Year 5
# of Workstations
# of Application Servers
# of Database Servers
# of Other Servers
# of Virtual Cores
Storage Requirements (GB)
<Other Estimates>

INTEGRATION POINTS

SYSTEM TO BE INTEGRATED	APPROACH	FREQUENCY
<Financial System>	<Technique, tool, etc.>	<Real-time, daily, weekly>
<Other Systems>

Help Using This Template Delete this box after reading. The operational impact specification is a planning tool used to estimate the impact of the system in the environment where it is being implemented. Add or remove specifications to suit the system being implemented. This plan can be used as the basis of planning costs, hardware requirements, service-level agreements, disaster recovery planning, and many other areas. Ideally, this should be filled out in consultation with the TSC via your business relationship manager (BRM).

DISCLAIMER Any articles, templates, or information provided by Smartsheet on the website are for reference only. While we strive to keep the information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability with respect to the website or the information, articles, templates, or related graphics contained on the website. Any reliance you place on such information is therefore strictly at your own risk.