[Project Name]
Production Support Strategy
Prepared By:
Prepared For:
Date Created:
Last Updated:
Document Overview
Author’s Name
Department Name
Month Day, Year
April 5, 2011
RASCI Alignment
(R)esponsible
(A)uthority
(S)upport:
(C)onsult:
(I)nform:
<A member from the Operations and Maintenance or Production Support team, for
the project’s output, should be involved in developing the support strategy for ongoing operations>
PRODUCTION SUPPORT STRATEGY
[PROJECT NAME]
Revision Log
Revision
Date
Initial / Name
1.0
4/5/2011
K. Abele
Description of Revision
Initial Draft for M101
Table of Contents
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 2 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
[PROJECT NAME]
1) Introduction
1.1) Production Support Strategy Overview
This is an IT SERVICES template for the PRODUCTION SUPPORT STRATEGY
document. Please tailor this template to suit the project’s needs. Some content is already
included in this document as reference. Please remove this paragraph prior to starting work
on this template.
The Production Support Strategy document defines, at a high-level, how a newlyimplemented system will be supported post-go-live for the [project name] at the University
of Chicago. A separate document, Production Support Guide, will elaborate on detailed
plans, processes and procedures for post-implementation production support.
For the [project name] project, this Production Support Strategy describes a two-phased
approach for post-implementation production support:
During the first, stabilization phase, the [project name] project team, will provide all
production application and user support 24x7 for a stabilization period of one month after golive. For all rollouts, the one-month ‘clock’ will begin ticking for implemented system
components upon each go-live date. This support period is fully described later in this
document – ‘Support Strategy for stabilization period’.
Finally, following each stabilization period, production support will be turned over to the
[Support Team name]. This support phase is described in the ‘Support Strategy for OnGoing Operations’ section of this document.
2) Scope Inclusions
At a high level, the [Project name and/or Software Name] scope includes:
2.1) Business Functionality

[Enter Business Area and Functionality 1 here…]

[Enter Business Area and Functionality 2 here…]
2.2) User Scope
Impacted user communities are being identified and will be appropriately trained. These
include:

For Rollout 1
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 3 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
[PROJECT NAME]
- [Enter User Type] Users: [Number of users] [Enter Department] [Enter hours of
operation]
- [Enter User Type] Users: [Number of users] [Enter Department] [Enter hours of
operation]

For Rollout 2 (if applicable)
- [Enter User Type] Users: [Number of users] [Enter Department] [Enter hours of
operation]
- [Enter User Type] Users: [Number of users] [Enter Department] [Enter hours of
operation]
2.3) Security Roles and Profiles
As part of the [PROJECT NAME] engagement, several new role profiles have been created.
The following are in scope for Production Support:

[Enter role/profile name]

[Enter role/profile name]

[Enter role/profile name]
2.4) Software Scope

[Example: Cognos / Informatica (data warehouse tools)]

[Example: Oracle (database for Cognos)]

[Example: AIX Operating System]
2.5) Hardware Scope

[Example: Oracle Financials, SAP].

[Example: Desktop and Networks: The desktop hardware, printers and private IP
network are managed by IT SERVICES Operations.]
3) Scope Exclusion
In citing the inclusions to [PROJECT NAME] Production Support scope it is also important to
highlight those areas that fall outside its scope.

Exclusion Area 1. [Provide description]

Exclusion Area 2. [Provide description]
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 4 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY

Exclusion Area 3. [Provide description]

Exclusion Area 4. [Provide description]
[PROJECT NAME]
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 5 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
[PROJECT NAME]
4) Implementation and Production Support Schedule
Within each delivery cycle, end user support will go through several key stages. Specifically,

Go Live Date: The first date that the new application/solution is turned on in a production
environment

Initial Support Period. This period represents the first three weeks, post go-live. This stage
represents onsite, 24X7 support to users

Stability Period: This represents a 2-month period (or period as defined by the project) in
which the system is live and continues to be supported. Onsite and page-out support will vary
between 24X7, weekday/day shift, depending on the operation area, number of users and issue
complexity, to name a few

Ongoing Support. This period is beyond the stabilization period and includes Monday – Friday
page out support for ongoing application and emergency issues.
As it specifically relates to project phases, the following production support schedule will be utilized
to ensure proper end user coverage:

Phase 1
Go Live Date: Month Day, Year
Initial Support Period: Month Day, Year
Stability Period: Month Day, Year
Ongoing Support: Month Day, Year

Phase 2
Go Live Date: Month Day, Year
Initial Support Period: Month Day, Year
Stability Period: Month Day, Year
Ongoing Support: Month Day, Year

Phase 3
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 6 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
[PROJECT NAME]
Go Live Date: Month Day, Year
Initial Support Period: Month Day, Year
Stability Period: Month Day, Year
Ongoing Support: Month Day, Year
5) Support Areas / Roles & Responsibilities
To ensure that post-implementation support is adequate, it is intended that each of the roles below be
filled with a person who has the required knowledge and has completed required training.
[Example: The following chart is a suggested format and can be tailored for the project’s need.]
Support
Area/Role
PS Manager/
Coordinator.
Dept /
Responsibility
Group
IT
 Ensure daily management of
SERVIC
the Solution Center
ES
 Coordinate daily activities
such as monitoring overall
metric tracking and resolution
rate
 Ensure the schedule allows for
the needs of the users to be met
 Ensure Solution Center is
equipped with required
supplies, equipment, etc
Architecture
IT
 Review all enhancement
and
SERVIC
requests following the exist
Specifications
ES
“IT request” process
 Attend promote to prod
reciprocal impacts with other
applications
Database
TMS
 Identify & understand patches
support
/ hot fixes
 Perform and validate back-ups
 Resolve tickets/problems
 Monitor environments
Network and
IT
 Identify & understand tickets /
Desktop
SERVIC
problems
environment
ES
 Monitor environments
support
 Resolve tickets/problems
Security support IT
 Add / delete users
SERVIC  Reset passwords
ES
 Resolve tickets/problems
Required Knowledge /
Training
The PS Manager will have
ultimate responsibility for
ensuring production tickets are
being resolved per the agreed
upon SLA
Understanding of the request
process, promote strategy, and
integration between systems
Technical and functional
knowledge of supporting
database software
Technical and functional
knowledge of networks
Technical knowledge of
[software] with regards to
security, and understanding of
overall security strategy
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 7 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
[PROJECT NAME]
Business
HR
owners
Deployment site BUS
coordinators
Key users
HR
 Initiate enhancement requests
Business process knowledge
Understanding of Production
Support Detailed Plan
Application system proficiency
and business process knowledge
Solution Center
staff
ENT
 Manage and coordinate site
support activities
 Support users to answer
questions at tier-1 level in
order to minimize calls to the
[software vendor] helpdesk
 Support users to answer
questions at tier-2 level
Master data
team
NBS
[Software
Vendor]
helpdesk
Oracle
Application system proficiency,
business process, and incident
management software
competency
 Support users to answer master Master data knowledge,
data questions
application system proficiency,
 Ensure data integrity for all
and business process knowledge
master data
 Route [software]-related
High-level technical and
Support to appropriate solution functional [software] knowledge
center
In addition to understanding the support components and their purpose, it is also important to
understand the support guidelines for each as they cross over the various production support stages.
By doing so, the user experience can be better enhanced through the minimization of failed attempts
to receive timely support. Below represents the support area matrix:
Support Area/Role
Initial Support
Stability Period
Ongoing Support
Architecture and
Specifications
Database support
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
M-F onsite
8AM – 5PM CST,
8AM – 5PM CST, M-F
remote
8AM – 5PM CST, M-F
remote
8AM – 5PM CST, M-F
remote
8AM – 5PM CST, M-F
remote
8AM – 5PM CST, M-F
remote
8AM – 5PM CST, M-F
remote
8AM – 5PM CST, M-F
remote
8AM – 5PM CST, M-F
remote
8AM – 5PM CST, M-F
Network and Desktop
environment support
Security support
Business owners
Deployment site
coordinators
Key users
Master data team
[Software Vendor]
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 8 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
[PROJECT NAME]
Support Area/Role
Initial Support
Stability Period
Ongoing Support
helpdesk
M-F onsite
M-F onsite
remote
6) Support Strategy for Stabilization Period
6.1) Overall
For the [Project Name] project, the first phase of support will cover a temporary stabilization
period of one month after go-live.
[Indicate the type of support that will be provide by the project team and the vendors for both
software and hardware. State any additional activities that will be fulfilled by the
implementation team.]
[Example: The [Project name] implementation team will provide 24x7 production
application and all user support.]
In addition to application and user support, a number of other activities will be fulfilled by
the implementation team:
 [Example: Informally cross-train long-term [project team] Team staff ]
 [Example: Maintain documentation of support topics / status / resolutions via a dedicated
queue within the incident management database used by the [project] Team]
 [Example: Maintain metrics / measurements of support topics / resolution rates]
 [Example: Develop a ‘Frequently Asked Questions’ list]
[Include details on the plans for training, error-logging and/or change control activities. If
they are not stated here, point out where this information can be found.]
[Example: Elaboration on plans for those training, error-logging, and change control
activities will be included in the Production Support Guide. ]
[Indicate the go-live date(s) and the begin date(s) of the 1-month clock for the Stabilization
period. ]
During the one month stabilization period, a three-tier support approach will be utilized:
Tier
Tier-1
Who
Key Users
(Super Users)
Tier-2
Project Team
What
Support of users by answering questions to minimize calls to
the Project Team or Helpdesk – using application system
proficiency and business process knowledge.
Support of users by addressing / resolving all questions /
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 9 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
Tier-3
Software /
Hardware
Vendors
[PROJECT NAME]
issues at tier-2 level (raised from tier-1 key users).
Application system proficiency, business process knowledge,
and Incident Management software competency is required.
Contractually-bound provision of support on external
products purchased / provided as components of [Project
Name].
6.2) Contacting Support
[During the one month Stabilization period, state the procedures to report issues and how to
obtain support for business process. Include escalation details. Include a process flow and
associated table with process steps]
6.3) Tier 1 Support – Key Users
During the one month Stabilization period, what team(s) will provide the Tier-1 support?
Are there more than one functional areas involved? If yes, list the support teams that are
assigned to each functional area/site? Include the responsibility of the support team(s) and
the types of support provided. Do these support teams have the sufficient knowledge and/or
training to handle this task? Are reference materials available?
Example:
As examples, a key user would be responsible for answering questions like:
 How do I perform transaction X in the new system?
 Why does this transaction need to be performed?
 What upstream / downstream impacts will this transaction have?
 Who are the other users that depend upon the information that is being input in
transaction X?
Because a key user is not expected to be able to answer every question or resolve every
problem, he / she may have additional primary accountabilities:
 Escalate unanswered support calls to tier-2 support
 Document escalated support calls
 Understand and communicate resolution to user
 Ensure closure of escalated support calls ]
6.4) Tier 2 Support – Project Team
[During the one month Stabilization period, what team(s) is going to provide the Tier-2
support? If there is more that one Support Site, list the Support team. What are the schedules
and staffing for these support sites? Also, include the support team’s training, travel and
other relevant details. ]
Support sites include:
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 10 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
Support Site
[PROJECT NAME]
Supports…
[List all functions via on-site solution center staff ]
[List All functions via on-site solution center staff ]
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 11 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
[PROJECT NAME]
6.5) Tier 3 Support – Software/Hardware Vendors
[During the one month Stabilization period, what team(s) and/or vendor(s) are going to
provide the Tier-3 support? List the software vendors of purchased/provided external
products, or include them in the Production Support Guide. Has the contract(s) been
reviewed to ensure adequate coverage? ]
6.6) Response Time Procedure, Priorities and Escalation Process
[Identify the Response Time Procedure, Priorities and Escalation Process for ongoing
operations. Is a Service Level Agreement available? List the directories or webpage URLs
where these information can be found. ]
[Example: For ongoing operations, a service level agreement will cover the following:
 Response time procedure & priorities
 Service response and support time procedure
 Approved escalation process ]
7) Support Strategy For On-Going Operations (After Stabilization Period)
7.1) Overview
[Provide an Overview of the Support Strategy for On-Going Operation, after the
Stabilization Period. Will the support transition from the project-support team to an ongoing
production support team? What are some the processes in place? Will there be changes to
these processes, or will they remain the same?
List some of the transition activities, such as resources changes, contact methods, open
issues handling, etc.
If there is a freeze period during the Stabilization Period, will new release or enhancement
be scheduled after the ‘unfreeze’? What are the steps? It is best to document these with a
process flow and associated table with steps]
7.2) Documentation
[List the location in which the project documentations can be found. Is it a shared device?
Does it have web access? If yes, include the URL. Provide information on how to obtain
access, if special authentication is required.
Include User documentation, training documentation and training-related details here.
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 12 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
[PROJECT NAME]
Is any Production Support Guide and Frequently Asked Questions documentations made
available? ]
7.3) Team Call Out Tree
[For ongoing operations, the call out tree will be utilized. Describe the Team Call-out Tree,
or may be further defined within the Production Support Guide. ]
7.4) Response Time Procedures, Priorities and Escalation Process
[Identify the Response Time Procedure, Priorities and Escalation Process for ongoing operations.
Is a Service Level Agreement available? List the directories or webpage URLs where these
information can be found. ]
[Example: For ongoing operations, a service level agreement will cover the following:
 Response time procedure & priorities
 Service response and support time procedure
 Approved escalation process ]
7.5) Operational Requirements
For ongoing operations, the following requirements will apply across all environments
(DEV, QA, and PROD):
7.5.1) Security
[Explain the procedures of creating and submitting security requests. Who will
provide the Security support? What are the Security procedures? ]
7.5.2) Configuration Control for Environments
[Explain the Change Control Procedures to support the system. Describe the
procedures at a high level for different scenarios. ]
[Example: In essence, a change request will be initiated; the change request will be
approved or denied. Approved changes will be developed and unit tested in
development. Once satisfied that development is complete (code review, and unit test
review), changes will be migrated to test for integration, regression, and user
acceptance testing. The change request will then be ready to be moved to Production.
Prior to migrating to PRD, it will need to be approved by a Change Control Board
Member. Upon approval, the change will be migrated to Production. ]
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 13 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
[PROJECT NAME]
[Example: The above procedure is required for:
 Hot fixes/patches
Update environments with patches per software vendor guidelines. Administrator
/ support point person holds responsibility to request and implement updates.
 System Upgrades
System upgrades required by vendor guidelines and IT SERVICES strategy. It is
the responsibility of system administrator to request and implement the upgrade.
 Enhancement Requests
Configuration/parameter and customization changes will be determined by
enhancement requests submitted through the Incident Reporting Tool request
process.]
7.5.3) Back-up Strategy for Environment(s)
[Include the Back-up Strategy for the Environments. How is it determined? And, by
whom? How often does Back-up occur? ]
7.5.4) Downtime Procedures
[What are the Downtime Procedures? List the procedures or links to these
procedures for “Scheduled” and “Unscheduled” Downtime? ]
Downtime procedures depend on whether the outage is scheduled or unplanned:
 Scheduled Downtime Procedures
[List procedures here]
 Un-scheduled Downtime Procedures
[List procedures here]
7.5.5) Disaster Recovery
[What is the Disaster Recovery plan for this system? Does one exist? If not, has it
been addressed? Or, a Disaster Recovery Plan in progress? ]
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 14 of 15
Last saved: 3/16/16
PRODUCTION SUPPORT STRATEGY
[PROJECT NAME]
8) Document Sign Off Page
Phase: Test and Final Prep
This Production Support Strategy document [Version x.x] has been reviewed and found to be consistent
with the specifications and/or documented project requirements. The signature below documents
acceptance of this document and/or work product by the signing authority
Organization: University of Chicago________________
Contractor________________
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
Organization: University of Chicago________________
Contractor________________
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
Organization: University of Chicago________________
Contractor________________
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
This document is a copy, effective only on the downloaded date. The official, updated template always resides on the PM101 site.
File Name: Document1
Page 15 of 15
Last saved: 3/16/16