PRODUCTION SUPPORT STRATEGY [PROJECT NAME]

[Project NameProject Name]

Production Support Strategy

Document Overview
Prepared By: / Author’s Name
Prepared For: / Department Name
Date Created: / Month Day, Year
Last Updated: / April 5, 2011
RASCI Alignment
(R)esponsible
(A)uthority
(S)upport:
(C)onsult:
(I)nform:

<A member from the Operations and Maintenance or Production Supportteam, for the project’s output,should be involved in developing the support strategy for on-going operations>

Revision Log

Revision / Date / Initial / Name / Description of Revision
1.0 / 4/5/2011 / K. Abele / Initial Draft for M101

Table of Contents

1) Introduction...... 4

1.1) Production Support Strategy Overview...... 4

2) Scope Inclusions...... 4

2.1) Business Functionality...... 4

2.2) User Scope...... 4

2.3) Security Roles and Profiles...... 5

2.4) Software Scope...... 5

2.5) Hardware Scope...... 5

3) Scope Exclusion...... 5

4) Implementation and Production Support Schedule...... 6

5) Support Areas / Roles & Responsibilities...... 7

6) Support Strategy for Stabilization Period...... 9

6.1) Overall...... 9

6.2) Contacting Support...... 10

6.3) Tier 1 Support – Key Users...... 10

6.4) Tier 2 Support – Project Team...... 10

6.5) Tier 3 Support – Software/Hardware Vendors...... 11

6.6) Response Time Procedure, Priorities and Escalation Process...... 11

7) Support Strategy For On-Going Operations (After Stabilization Period)...... 11

7.1) Overview...... 11

7.2) Documentation...... 11

7.3) Team Call Out Tree...... 12

7.4) Response Time Procedures, Priorities and Escalation Process...... 12

7.5) Operational Requirements...... 12

7.5.1) Security...... 12

7.5.2) Configuration Control for Environments...... 12

7.5.3) Back-up Strategy for Environment(s)...... 13

7.5.4) Downtime Procedures...... 13

7.5.5) Disaster Recovery...... 13

8) Document Sign Off...... 14

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 newly-implemented 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 go-live. 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 On-Going 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

­[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]
  • Exclusion Area 3. [Provide description]
  • Exclusion Area 4. [Provide description]

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

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 / Dept / Group / Responsibility / Required Knowledge / Training
PS Manager/ Coordinator. / IT SERVICES / Ensure daily management of the Solution Center
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 / The PS Manager will have ultimate responsibility for ensuring production tickets are being resolved per the agreed upon SLA
Architecture and Specifications / IT SERVICES / Review all enhancement requests following the exist “IT request” process
Attend promote to prod reciprocal impacts with other applications / Understanding of the request process, promote strategy, and integration between systems
Database support / TMS / Identify & understand patches / hot fixes
Perform and validate back-ups
Resolve tickets/problems
Monitor environments / Technical and functional knowledge of supporting database software
Network and Desktop environment support / IT SERVICES / Identify & understand tickets / problems
Monitor environments
Resolve tickets/problems / Technical and functional knowledge of networks
Security support / IT SERVICES / Add / delete users
Reset passwords
Resolve tickets/problems / Technical knowledge of [software] with regards to security, and understanding of overall security strategy
Business owners / HR / Initiate enhancement requests / Business process knowledge
Deployment site coordinators / BUS / Manage and coordinate site support activities / Understanding of Production Support Detailed Plan
Key users / HR / Support users to answer questions at tier-1 level in order to minimize calls to the [software vendor] helpdesk / Application system proficiency and business process knowledge
Solution Center staff / ENT / Support users to answer questions at tier-2 level / Application system proficiency, business process, and incident management software competency
Master data team / NBS / Support users to answer master data questions
Ensure data integrity for all master data / Master data knowledge, application system proficiency, and business process knowledge
[Software Vendor] helpdesk / Oracle / Route [software]-related Support to appropriate solution center / High-level technical and functional [software] knowledge

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 / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F remote
Database support / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F remote
Network and Desktop environment support / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F remote
Security support / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F remote
Business owners / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F remote
Deployment site coordinators / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F remote
Key users / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F remote
Master data team / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F remote
[Software Vendor] helpdesk / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F onsite / 8AM – 5PM CST, M-F 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 / Who / What
Tier-1 / Key Users (Super Users) / Support of users by answering questions to minimize calls to the Project Team or Helpdesk – using application system proficiency and business process knowledge.
Tier-2 / Project Team / Support of users by addressing / resolving all questions / issues at tier-2 level (raised from tier-1 key users). Application system proficiency, business process knowledge, and Incident Management software competency is required.
Tier-3 / Software / Hardware Vendors / 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:

Support Site / Supports…
[List all functions via on-site solution center staff ]
[List All functions via on-site solution center staff ]

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.

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

[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: