<Project Name>

Post Implementation Plan

(Maintenance Plan)

Post Implementation (Maintenance) Plan Template Instructions

(Please remove this section before completion of template)

The Post Implementation will identify the scope of the project and the responsibilities of the participants for the staff maintaining the system post-project. The system and/or applications should be outlined in detail. The expectations for support services need to be identified and documented. Also, a detailed change management process needs to be developed for future change, maintenance, upgrades and customizations.

Be sure to maintain version control as the analysis is modified and/or edited.

All instructions within the template are italicized within the document.

Any examples are in a red font.

Any portion of the template that does not fit or pertain to your project should be documented that it was reviewed and is not relevant. See below for requirements for a project and deliverable approvals.

Be sure to unlock table of contents by selecting TOC then Ctrl-Shift-F11 to enable TOC updating in Word docx.

Project Deliverable	Requirements by Project Size
Planning/Development Phase	Large	Medium	Small	Requirements	Approvals
Post Implementation Plan (SDLC)	R	HR	O	The Post Implementation Plan is required for large scale projects, highly recommended for medium scale projects and optional for small scale projects unless requested by the Sponsor, Steering Committee or IT management.	The Post Implementation Plan should be approved by the Implementation Team and Steering Committee, at a minimum.

Table of Contents

1.	Introduction	2

1.1.	Purpose	2

1.2.	Assumptions	2

2.	Version Control	3

3.	Project Scope	4

4.	Project Team	5

5.	System Description	6

5.1.	Sub Section #1	6

5.2.	Sub Section #2	6

5.3.	Sub Section #3	6

6.	Support Services	7

6.1.	Hours of Use and Support	7

6.2.	Support	7

6.3.	Help Desk Support Plan	7

6.4.	Standard Maintenance Services	7

6.5.	Maintenance and Enhancements	7

6.6.	System Outages	7

6.7.	Disaster Recovery	7

6.8.	Policies and Procedures	7

6.9.	End of Life	8

7.	Change Management	9

8.	Future Phases & Enhancements	10

9.	Approval	11

Introduction

Purpose

This post implementation plan will outline how the system will be maintained, upgraded etc after the project life cycle. This plan will address support needs, help desk implementation, policy and procedures, along with end of live guidelines. Most importantly, this plan will determine how change management will be handled for system or application enhancements or changes.

Assumptions

This document assumes.....

Version Control

Version	Date	Person	Change
1.0	Initial Document Creation

Project Scope

Provide a summary of the project scope for the teams that will provide maintenance, support or services on the product of the project.

Project Team

Provide the names, departments and project roll for all project teams. You could insert the Project Contact List.

System Description

Outline the system or application components. Provide any diagrams that would show the systems integration, networking, etc. Also include user requirements, authentication process, password formatting, etc. Use the sub-sections for the different aspects of the system.

Sub Section #1

Sub Section #2

Sub Section #3

Support Services

Hours of Use and Support

Outline the hours support will be available and how to access the help.

Support

Outline who will be the support staff for the product of this project.

Help Desk Support Plan

Create call groups and procedures for the help desk, this will include scripts for the different possible scenarios.

Standard Maintenance Services

Outline what the standard maintenance will be for the different parts of the project, who is responsible and the schedule.

Maintenance and Enhancements

Define the process for patches, upgrades and/or enhancements. Include communication plan for scheduled downtimes, and outline any downtime procedures, if needed.

Budget

Identify budget for post-implementation annual maintenance costs as well as any projected software or hardware upgrades required for a minimum of five (5) years.

System Outages

Define the processes for scheduled downtime and unscheduled downtime. Include the communication plan for the scheduled downtime and the downtime procedures.

Disaster Recovery

Provide the reference materials for the disaster recovery for the project product.

Policies and Procedures

List procedures and policies required for the execution and support of this system and/or application.

End of Life

Outline the planned end of life timeframes and procedures.

Change Management

Provide the change management procedures for any upgrades, new programming, customizations, requests, etc. Along with developing the change management for the system or application, be sure to adhere to the IST Change Management Policy. The specific section is:

“Notify the UMDNJ IST community of any change to the production environment in accordance with the IST Change Management and Communication Policy. The policy states that "All computer and communications systems used for production processing at the University must employ a formal change control procedure used to ensure that only authorized changes are made. This change control procedure must be used for all changes to software, hardware, communications networks, and related procedures." (UMDNJ Policy on IST Change Management and Communication 95-01-04-01, Section V.A). Write to IST_CHG@umdnj.edu for specific instructions.”

Future Phases & Enhancements

If any future phase and enhancements have already been identified during the course of the project, outline and define them.

Approval

The individuals below agree that they have reviewed and approved the information documented in this Support Documentation.

APPROVED BY:
Function Role	Name and Title	Signature	Date

Project Management Office

EXAMPLE

Campus Hosts

Post Implementation Plan

Server Migration to new Infrastructure Project

TABLE OF CONTENTS

1.	Introduction	2

1.1.	Purpose	2

1.2.	Assumptions	2

2.	Version Control	2

3.	Project Scope	2

4.	Project Team	2

5.	System Description	2

4.1.	Campus Host Server List	2

4.2.	Supported Services/Software/Applications - Current	2

4.3.	Infrastructure Diagram	2

4.4.	System Admin Access	2

4.5.	User Access	2

5.	Support Services	2

6.1.	Regular Maintenance & Support	2

6.2.	End user support	2

6.3.	System Outages	2

6.4.	Disaster Recovery	2

6.5.	High Availability requirements	2

6.6.	Applicable policies & procedures	2

6.7.	End of Life	2

7.	Change Management	2

8.	Future Phases & Enhancements	2

9.	Approval	2

Introduction

Purpose

Purpose of this document is to detail the post implementation plan for the four campus hosts located at Newark, Piscataway, Camden and Stratford campuses.

Assumptions

None

Version Control

Version	Date	Person	Change
1.0	6/18/2010	Rema Chandrasekharan	Initial Document Creation

Project Scope

The scope of the project entailed replacing the 4 campus host servers nearing EOL with new servers. Effort entailed migration of all required applications/programs [DNS, NTP, Cronjobs etc.] to the new campus hosts and migration of the rest of the applications/ programs/ services/ accounts to other existing systems / units. All inactive applications/ programs have been decommissioned.

The project scope also entailed migration of all static websites hosted on the campus hosts to new redundant load balanced architecture in Montclair.

Project Team

Steering Committee
Name	Department/Unit	Project Role
Bill Lansbury	CA-CST	Project Sponsor
Steve Schladale	CA-CST	Co-Project Manager
Rema Chandrasekharan	CA-IST	Project Manager
Oscar West-Crews	CA-CST	Steering Committee member
Tom Minnefor	CA-IST	Steering Committee member
Joe Konopka	CA-BST	Steering Committee member
Vernon Cabalfin	SHRP-IST	Steering Committee member

Implementation Team
Name	Department/Unit	Project Role
Rema Chandrasekharan	IST-PMO	Project Manager, PMO-IST
Carl Hopf	BST	Implementation team member
Clifford Green	BST	Implementation team member
Lizhen Xu	BST	Implementation team member
Steven Schladale	CST-AS	Co-Project Manager, AST
Harry Namkoong	CST-AS	Implementation team member
Philippa Hodge	CST-AS	Implementation team member
Robert Field	CST-AS	Implementation team member
Edward Dumala	CST-IST	Implementation team member
Harriet Whitlock	CST-IST	Implementation team member
Pedro Fernandes	CST-IST	Implementation team member
Ronald Martens	CST-IST	Implementation team member
Uriah Queen	CST-IST	Implementation team member

System Description

Campus Host Server List

Server Name	Location	Purpose	HW	OS	Serial# & IP Address
RWJCAM	Camden [Telephone Closet, 1st flr, 401 Haddon Ave.]	Campus Host Production	X4150	Solaris 10	SN# 0923QAR060 130.219.11.100
PEARL	Stratford, [1 Medical Center Drive, AC24]	Campus Host Production	X4150	Solaris 10	SN# 0923QAR04E 130.219.69.100
RWJA	Piscataway [SB-11, RWJ Bldg, Hoes Lane]	Campus Host Production	X4150	Solaris 10	SN# 0924QARAB0 130.219.4.100
NJMSA	Newark [C631, MSB]	Campus Host Production	X4150	Solaris 10	SN#0924QARA9F 130.219.34.100
Support Validity	04/21/2014
End of Life	4/30/2015

Supported Services/Software/Applications - Current

Software/ Applications
Server Name	DNS	Print	Others
NJMSA	DNS – Master Server [Bind ver. 9.6.1-p3]	LPRNG [Print count –ver. 3.8.33]	Refer Campus Host Inventory for list of all software
RWJCAM	DNS – Slave Server	LPRNG [Print count – ver. 3.8.33]
PEARL	DNS – Slave Server
RWJA	DNS – Slave Server

Infrastructure Diagram

System Admin Access

Only CST- Academic Services [AS] team members will have root access to the campus hosts. The updated list of AS users who have root access is available as the “Key” file on respective campus hosts. The current list of AS team members includes Harry Namkoong, Philippa Hodge, Robert Field, Steve Schladale, Yan Su.

System admin password configuration follows the IST policy on Strong passwords.

User Access

Currently, Non-AS users DO NOT have access to the campus hosts, other than for the following exceptions:

Application Development team in BST will have access to specific production application accounts that they own and manage on NJMSA.

Print Queue – View access for Computer Lab personnel [UMDNJ Staff ONLY]

Refer Campus Host Access file for list of all users and access rights on Campus Hosts

Request for new access

Requests for new application new file systems or access to existing file systems will have to be submitted to the CST-AS team. Determination will be made if the request is justified OR if the nature of the request could be satisfied by granting access to a different process/system/server.

If the request is approved, the ID will be created on the campus host and the requester notified via email to contact the System Administrator for the password. The initial password will be configured to require that it be changed at first login.

Refer attached Request form

Support Services

Regular Maintenance & Support

Refer the enclosed “Hardware support process for Campus Hosts” document for the current maintenance and support processes.

End user support

User Access Support:

Contact IST Service center 7 A.M. to 5 P.M., Monday through Friday at 732-743-3200.

Requests for new login account:

Primary Contact: Steve Schladale: schladsb@umdnj.edu

DNS additions/deletions:

Primary Contact: Bob Field: field@umdnj.edu

Secondary Contact: Ryan Novoseilski: novosirj@umdnj.edu

Printing: Primary Contact: Lisheng Chen: chenl8@umdnj.edu

Secondary Contact: Ryan Novoseilski: novosirj@umdnj.edu

New Software/Tool installs:

Primary Contact: Steve Schladale: schladsb@umdnj.edu

Secondary Contact: Harry Namkoong: namkoohe@umdnj.edu

System Admin:

Primary Contact: Steve Schladale: schladsb@umdnj.edu

Access to HEAT: Harry Namkoong will have access to HEAT ticket system to resolve system admin and other issues related to Campus Host

System Outages

All planned outages will be notified to all users, through change requests. The schedule and periodicity of such planned outages is defined in the hardware support process document.

Emergency Outages:

In the event of Emergency outages, the downtime and impact will be communicated to the CST – Asst. Director. An emergency change request will be approved by CST – Asst. Director and published through Change Management board.

Disaster Recovery

Campus Hosts are covered by the IST UMDNJ Disaster Recovery contract managed by Sungard. In the event of a hardware failure, an equivalent server will be provisioned at Sungard. As per current contract, the Recovery Objectives are as under:

Mobilize Recovery teams within 4 hours of a declared disaster

Restore critical computing resources at the hot-site within 24 hours of the declaration

Restore to last backup, database vintage no greater than 1 day old

Backups of the Campus Hosts are performed daily by CST centralized backup and recovery group. On day one, there is a full backup followed by 6 days of incremental backups. The cycle starts over on day 8 with a full back up again followed by the 6 incremental backups. The backup tapes are also cycled through the backup process.

A One-time, Long-term backup for each of the campus has been taken and stored at VRI, in keeping with the decommissioning process.

High Availability requirements

Campus hosts are currently at 99.9% availability. No additional high availability setup is implemented for the four campus hosts.

Applicable policies & procedures

Policies

The only applicable policy for Academic Systems is “RIGHTS & RESPONSIBILITIES FOR THE USE OF UNIVERSITY-ACCESSED ELECTRONIC INFORMATION SYSTEMS” [Code: 00-01-10-40:00]

This policy has been recently amended [3/5/10] and is currently under review with D. Romano.

Server Decommissioning Procedures:

The Server Decommissioning procedure is approved by Compliance and governs the data backup plan, Plan for discard/Long term storage of Disks and server disposal process.

Refer attached Project Summary document [Page 3-4] for more details:

Provisioning process for Accounts and software requests:

A new provisioning process has been defined to handle provisioning requests for new file systems, provide access to existing file systems and to address requests for software installs on the campus hosts. Discussion is underway to make this an online web process.

[Refer provisioning process document for detailed workflow and steps request of accounts/ credentials]

End of Life

Campus Hosts:

Campus Host servers will reach end-of-life on 4/30/2015

Software/Applications:

No end-of-life dates have been identified for the external software packages installed on the campus hosts.

Change Management

All changes will follow the IS&T Change management communication policy 95-01-04-01:01.

Future Phases & Enhancements

Refresh DR List with new Server details:

Scope: The current CST DR contract covers the legacy campus hosts. The configuration details of the new campus hosts have been shared with the High Availability group to be updated when the DR list is refreshed, later this year [2010]

Effort: Minimal. Follow-up to ensure that the list is updated with the new server details

Timeframe: Q3-Q4 2010 [Calendar Year]

Cost: None

Disaster Recovery Test:

Scope: Test the Disaster Recovery setup for one or more campus hosts. Effort will entail setup of files/configuration required on the test server, testing and documenting the results of DR test.

Effort: 8-12 person-hours

Timeframe: Q3-Q4 2010 [Calendar Year], post DR list refresh

Cost: None. Two Tests are allowed per year at NO additional costs, as part of the DR contract.

Setup Redundancy for NJMSA [Master DNS Server]:

Scope: Setup redundancy for NJMSA, which is the Master DNS server. Currently in addition to being the master DNS server, NJMSA also hosts BST production applications. It is critical to have high availability on this server.

Effort: TBD

Timeframe: TBD

Cost: TBD

Approval

Name	Department/Unit	Designation	Signature
Bill Lansbury	CA-CST	Director – CST	Email approval: 6/29/10
Ron Martens	CA-CST	Asst. Director - CST	Implicit approval: 6/29/10
Steve Schladale	CA-CST	Manager – AS	Email approval: 6/29/10
Rema Chandrasekharan	CA-IST	Project Manager II - PMO	Email approval: 6/29/10