Systems Implementation Plan

Systems Implementation Plan
<Project Title>

Date
<YYYY-MM-DD>
Initiated:
Project
Sponsor:
Project Title:
Project
Manager:
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

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
require substantially more planning around design, construction and testing.
This page should provide hyperlinks to all plans, whether in this document or
elsewhere.
Delete this box after reading.
Last Updated: 2013-04-05
<Project Title>
Implementation Strategy
Components to be Implemented:
Component
Description of Function
Name
<Application>
<A brief description of what the
components does>
Source
<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. Describes the
overall approach. 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. Covers activities, tools, locations, people, etc>

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.
<Project Title>
Testing Strategy
Deployment Environments:
Name
Technical Description
Development
<Hardware, software, CPUs,
etc>
Functional Testing
Usage Description
<Purpose, frequency of updates,
stability, etc>
User Acceptance
Testing
Production
<Other
Environments>
Environment Control Approach:
<This section describes how the various environments will be updated and used. Covers
deployment tools, schedules, etc>
Planned Testing Activities:
Type of Test
Description
Unit Testing
<Describe method, tools, people involved,
effort, etc>
Frequency
<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.>

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.
<Project Title>
Knowledge Transfer and Training Plan

Knowledge Requirements:
Knowledge Area
Knowledgeable Group
<Technical
knowledge>
<System knowledge>
<Application
knowledge>
<Other areas>
<Who, on the implementation

team, knows about this area?>
Required Operational
Groups
<Who, on the operational team,
needs to know this area?>
Knowledge Transfer Plan:

Transfer Activity
<Produce Operations
Manual>
Audience
<Who, on the
operational team, is this
activity intended for?>
Person
Responsible
<Who, on the
implementation
team, is
responsible for this
activity?>
Timeframe
<Dates, times,
frequency, etc
>
<Conduct Workshop>
Training Requirements:
User Group
<Admins>
<Users>
Training Needs
<Roles, modules, functions>
Size of
Group
<# people>
Location of Group
<HQ, communities>
<Other Groups>
Training Plan:
Training Activity
<Production
Guide>
Audience
<Who is this activity
intended for?>
Training Team
<Who is involved in
delivering this
training?>
Timeframe
<Dates, times,
frequency, etc>
<Workshop>

The Knowledge Transfer and Training Plan describes 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 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.
<Project Title>
Operational Impact Specification

Operational Profile:
Operating Hours:
Expected Availability:
<7 days - 24 hours per day, 6 days - 22 hours per day>

<high availability: 99.5%>
Expected Reliability:
Peak Busy Hours:
<fault tolerance: 99.9%>

<09:30 - 10:30 hrs, 13:00 - 14:00 hrs;>
Maximum Tolerable
Outage:
Backup Window:
Backup Requirements:
<e.g. how long can the system be offline: 2 hrs, 24 hrs, 48 hrs;>
<daily between 23:00 - 24:00 hrs, weekend availability;>
< full back up 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 Reqs (GB)
<Other Estimates>
Integration Points:
System to be
Integrated
<Financial System>
Approach
<Technique, tool, etc>
Frequency
<Real-time, daily,
weekly>
<Other Systems>

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).

Systems Implementation Plan

Uploaded by

Copyright:

Available Formats

Systems Implementation Plan

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Systems Implementation Plan

Uploaded by

Copyright:

Available Formats

What components will be implemented as part of the system?

What components will be implemented as part of the system?

How will testing of the system be conducted?

How will testing of the system be conducted?

Systems Implementation Plan