System Decommission Planning Guide

waxspadeManagement

Nov 18, 2013 (3 years and 8 months ago)

90 views

OSIAdmin # ____

<Project Name> Project



System Decommission
Planning Guide




















<Month Year>




Health and Human Services Agency, Office of Systems Integration

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
2

of
37









Revision History

R
EVISION
H
ISTORY

R
EVISION
/
W
ORK
S
ITE

#

D
ATE OF
R
ELEASE

O
WNER

S
UMMARY OF

C
HANGES

Initial Draft v1


June 26
, 2008

OSI
-
PMO

Initial Release




























<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
3

of
37



<PROJECT NAME> SYSTE
M DECOMMISSION

IS NOW

FULLY ENGAGED IN THE

EXECUTION PHASE OF T
HE WORKPLAN TASKS.
THE PLANS DOCUMENTED

HEREWITH ARE BEING M
ANAGED AT THE D
IRECTION OF THE
<PROJECT
NAME>

PROJECT DIRECTOR

AND THE SYSTEM DECOM
MISSION

PROJECT
MANAGER. OUR SIGNAT
URES BELOW REPRESENT

OUR
CONFIRMATION OF
THE ACTIVITIES AND A
PPROACHES DOCUMENTED

HEREWITH.




_______________________________________

_________________
________

<NAME>
,
<Project Name>

Project Director


Date



______________________________________
_________


_____________

<NAME>, <Project Name>

System Decommission

Manager


Date



<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
4

of
37



TABLE OF CONTENTS

1

BACKGROUND

................................
................................
................................
.......

9

2

PURPOSE

................................
................................
................................
...............

9

3

SCOPE

................................
................................
................................
....................

9

4

REFERENCES
................................
................................
................................
.......

10

5

ACRONYMS

................................
................................
................................
..........

10

6

SYSTEM DECOMMISSION
PLANS

................................
................................
......

10

6.1

A
PPLICATION
C
OMPONENT
D
EC
OMMISSIONING
P
LAN
(ACDP)
................................
........................

13

6.2

A
SSET
M
ANAGEMENT
P
LAN
(AMP)

................................
................................
...............................

13

6.3

A
PPLICATION
M
AINTENANCE
P
RIORITIZATION
P
LAN
(AMPP)

................................
..........................

13

6.4

C
ONTRACT
M
ANAGEMENT
P
LAN
(CMP)

................................
................................
........................

13

6.5

C
OMMUNICATIONS
P
ROCESS
P
LAN
(CPP)

................................
................................
....................

13

6.6

F
ISCAL
T
RANSITION
P
LAN
(FTP)

................................
................................
................................
...

13

6.7

I
NTERFACE
M
ANAGEMENT
P
LAN
(IMP)

................................
................................
..........................

13

6.8

M
AINFRAME
D
ECOMMISSIONING
P
LAN
(MDP)

................................
................................
...............

14

6.9

O
PERATIONS
S
HUTDOWN
P
LAN
(OSP)

................................
................................
.........................

14

6.10

P
ROJECT
P
ROCESSES
M
ANAGEMENT
P
LAN
(PPMP)

................................
................................
.....

14

6.11

R
ECORDS
M
ANAGEMENT
P
LAN
(RMP)

................................
................................
..........................

14

6.12

S
TATE
S
TAFFING
P
LAN
(SSP)

................................
................................
................................
......

14

7

PROJECT KEY DATES /
ACTIVITIES S
CHEDULE

................................
.............

15

8

APPLICATION COMPONEN
T DECOMMISSIONING PL
AN

................................

15

8.1

P
URPOSE

................................
................................
................................
................................
....

15

8.2

S
COPE

................................
................................
................................
................................
........

15

8.3

U
PDATE
T
RIGGERS

................................
................................
................................
......................

15

8.4

A
PPROACH

................................
................................
................................
................................
..

15

8.
4.1

(Project Name) Applications

................................
................................
................................
..

15

8.4.2

Service Delivery and Service Management Support Systems

................................
..............

16

8.4.3

Internal Business Appl
ications

................................
................................
..............................

16

8.4.4

WEB

................................
................................
................................
................................
......

16

8.5

R
OLES AND
R
ESPONSIBILITIES
:

................................
................................
................................
.....

16

8.6

R
ISK
I
DENTIFICATION AND
M
ITIGATION
S
TRATEGY
:

................................
................................
.........

16

8.7

R
EVIEW
,

A
PPROVAL AND
M
AINTENANCE
:

................................
................................
.......................

16

9

ASSET MANAGEMENT PLA
N

................................
................................
.............

17

9.1

P
URPOSE

................................
................................
................................
................................
....

17

9.2

S
COPE

................................
................................
................................
................................
........

17

9.3

U
PDATE
T
RIGGERS

................................
................................
................................
......................

17

9.4

A
PPROACH

................................
................................
................................
................................
..

17

9.4.1

Asset Validation

................................
................................
................................
.....................

17

9.4.2

Asset Disposition

................................
................................
................................
...................

18

9.5

R
OLES AND
R
ESPONSIBILITIES
:

................................
................................
................................
.....

18

9.6

R
ISK
I
DENTIFICATION AND
M
ITIGATION
S
TRATEGY
:

................................
................................
.........

18

9.7

R
EVIEW
,

A
PPROVAL AND
M
AINTENANCE
:

................................
................................
.......................

18

10

APPLICATION MAINTENA
NCE PRIORITIZATION P
LAN

...............................

19

10.1

P
URPOSE

................................
................................
................................
................................
....

19

10.2

S
COPE

................................
................................
................................
................................
........

19

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
5

of
37


10.3

U
PDATE
T
RIGGERS

................................
................................
................................
......................

19

10.4

A
PPROACH

................................
................................
................................
................................
..

19

10.5

R
OLES AND
R
ESPONSIBILITIES
:

................................
................................
................................
.....

19

10.6

R
ISK
I
DENTIFICATION AND
M
ITIGATION
S
TRATEGY
:

................................
................................
.........

19

10
.7

R
EVIEW
,

A
PPROVAL AND
M
AINTENANCE
:

................................
................................
.......................

19

11

CONTRACT MANAGEMENT
PLAN

................................
................................
..

20

11.1

P
URPOSE

................................
................................
................................
................................
....

20

11.2

S
COPE

................................
................................
................................
................................
........

20

11.3

U
PDATE
T
RIGGERS

................................
................................
................................
......................

20

11.4

A
PPROACH

................................
................................
................................
................................
..

20

11.5

R
OLES AND
R
ESPONSIBILITIES
:

................................
................................
................................
.....

20

11.6

R
ISK
I
DENTIFICATION AND
M
ITIGATION
S
TRATEGY
:

................................
................................
.........

21

11.7

R
EVIEW
,

A
PPROVAL AND

M
AINTENANCE
:

................................
................................
.......................

21

12

COMMUNICATIONS PROCE
SS PLAN

................................
.............................

21

12.1

P
URPOSE

................................
................................
................................
................................
....

21

12.2

S
COPE

................................
................................
................................
................................
........

21

12.3

U
PDATE
T
RIGGERS

................................
................................
................................
......................

21

12.4

A
PPROACH

................................
................................
................................
................................
..

21

12.5

R
OLE AND
R
ESPONSIBILITIES

................................
................................
................................
........

22

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
6

of
37


COMMUNICATION REQUEST PROCESS

Workgroup manager
emails CRF and
proposed communication
to COM Workgroup
mailbox
Com Workgroup
discusses
proposed
communication
Communication
Request Form
(
CRF
)
and
proposed
communication
Request
approved by
Com
Yes
Com Workgroup
formats
communication for
release
Prepared
communication
Com Workgroup
Manager distributes
communication via
appropriate vehicle
(
email
,
webmaster
,
newsletter editor
)
Com Workgroup
Manager updates status
on CRF
CRF and proposed
communication
CRF and proposed
communication
No
Yes
Com
Workgroup
Manager returns
request for content
modification
(
response due
from originating
Workgroup
Manager within
24
hrs
)
Com Workgroup
Manager provides
communication to
Project Lead for
approval
Approved
Prepared
communication
Final
communication
Auto response
generated
Log request into
Tracking Database
No
Monitor for response
/
need for follow up
22

12.6

R
ISK
I
DENTIFICATION AND
M
ITIGATION
S
TRATEGY
:

................................
................................
.........

25

12.7

R
EVIEW
,

A
PPROVAL AND
M
AINTENANCE
:

................................
................................
.......................

25

13

FISCAL TRANSITION PL
AN

................................
................................
.............

25

13.1

P
U
RPOSE

................................
................................
................................
................................
....

25

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
7

of
37


13.2

S
COPE

................................
................................
................................
................................
........

25

13.3

U
PDATE
T
RIGGERS

................................
................................
................................
......................

25

13.4

A
PPROACH

................................
................................
................................
................................
..

25

13.5

R
ISK
I
DENTIFICATION AND
M
ITIGATION
S
TRATEGY
:

................................
................................
.........

26

13.6

R
EVIEW
,

A
PPROVAL AND
M
AINTENANCE
:

................................
................................
.......................

26

14

INTERFACE MANAGEMENT

PLAN

................................
................................
.

27

14.1

P
URPOSE

................................
................................
................................
................................
....

27

14.2

S
COPE

................................
................................
................................
................................
........

27

14.3

U
PDATE
T
RIGGERS

................................
................................
................................
......................

27

14.4

A
PPROACH

................................
................................
................................
................................
..

27

14.5

R
OLES AND
R
ESPONSIBILITIES
:

................................
................................
................................
.....

27

14.6

R
ISK
I
DENTIFICATION AND
M
ITIGATION
S
TRATEGY
:

................................
................................
.........

28

14.7

R
EVIEW
,

A
PPROVAL AND
M
AINTENANCE
:

................................
................................
.......................

28

15

MAINFRAME DECOMMISSI
ONING PLAN

................................
.......................

29

15.1

P
URPOSE

................................
................................
................................
................................
....

29

15.2

S
COPE

................................
................................
................................
................................
........

29

15.3

U
PDATE
T
RIGGERS

................................
................................
................................
......................

29

15.4

A
PPROACH

................................
................................
................................
................................
..

29

15.5

R
OLES AND
R
ESPONSIBILITIES
:

................................
................................
................................
.....

30

15.6

R
ISK
I
DENTIFICATION AND
M
ITIGATION
S
TRATEGY
:

................................
................................
.........

30

15.7

R
EVIEW
,

A
PPROVAL AND
M
AINTENANCE
:

................................
................................
.......................

30

16

OPERA
TIONS SHUTDOWN PLAN

................................
................................
...

30

16.1

P
URPOSE

................................
................................
................................
................................
....

30

16.2

S
COPE

................................
................................
................................
................................
........

30

16.3

U
PDATE

T
RIGGERS

................................
................................
................................
......................

30

16.4

A
PPROACH

................................
................................
................................
................................
..

31

16.5

R
OLES AND
R
ESPONSIBILITIES
:

................................
................................
................................
.....

31

16.6

R
ISK
I
DENTIFICATION AND
M
ITIGATION
S
TRATEGY
:

................................
................................
.........

31

16.7

R
EVIEW
,

A
PPROVAL AND
M
AINTENANCE
:

................................
................................
.......................

31

17

PROJECT PROCESSES MA
INTENANC
E PLAN

................................
.............

32

17.1

P
URPOSE

................................
................................
................................
................................
....

32

17.2

S
COPE

................................
................................
................................
................................
........

32

17.3

U
PDATE
T
RIGGERS

................................
................................
................................
......................

32

17.4

A
PPROACH

................................
................................
................................
................................
..

32

17.5

R
OLES AND
R
ESPONSIBILITIES
:

................................
................................
................................
.....

32

17.6

R
ISK
I
DENTIFICATION AND
M
ITIGATION
S
TRATEGY
:

................................
................................
.........

32

17.7

R
EVIEW
,

A
PPROVAL AND
M
AINTENANCE
:

................................
................................
.......................

32

18

RECORDS MANAGEMENT P
LAN

................................
................................
....

33

18.1

P
URPOSE

................................
................................
................................
................................
....

33

18.2

S
COPE

................................
................................
................................
................................
........

33

18.3

U
PDATE
T
RIGGERS

................................
................................
................................
......................

33

18.4

A
PPROACH

................................
................................
................................
................................
..

33

18.5

R
OLES AND
R
ESPONSIBILITIES
:

................................
................................
................................
.....

34

18.6

R
ISK
I
DENTIFICATION AND
M
ITIGA
TION
S
TRATEGY
:

................................
................................
.........

34

18.7

R
EVIEW
,

A
PPROVAL AND
M
AINTENANCE
:

................................
................................
.......................

34

19

STATE STAFFING PLAN

................................
................................
..................

34

19.1

P
URPOSE

................................
................................
................................
................................
....

34

19.2

S
COPE

................................
................................
................................
................................
........

34

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
8

of
37


19.3

U
PDATE
T
RIGGERS

................................
................................
................................
......................

35

19.4

ISAWS

S
YSTEM
S
UPPORT
R
ESOURCE
P
LAN

................................
................................
................

35

19.5

S
TATE
S
TAFF
T
RANSITION
(R
OLLOFF
)

P
LAN

................................
................................
..................

36

19.6

R
OLES AND
R
ESPONSIBILI
TIES
:

................................
................................
................................
.....

37

19.7

R
ISK
I
DENTIFICATION AND
M
ITIGATION
S
TRATEGY
:

................................
................................
.........

37

19.8

R
EVIEW
,

A
PPROVAL AND
M
AINTENANCE
:

................................
................................
.......................

37



LIST OF FIGURES

Figure 1


System Decommission Organizational Chart

................................
......................
11

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
9

of
37


1

BACKGROUND

<Provide a brief history of the project and why the system is being decomm
issioned.
What is the projected date of completion?>

2

PURPOSE


The purpose of this

document

is

to

define
the
formal
approach that
<Project Name>

will
take to close the
various aspects of the
project
by

the use of industry standard project
management tools
and processes.

Th
e primary responsibility for

project closure
belongs to the
<Project Name> members

with direct interface and ownership with the
<User Group>
, OSI, state and federal
partners.

It is the intent of
the System Decommission Project
to rely
on fully documented existing
<Project Name>
policies and procedures to facilitate
and guide all activities
. The plans
and processes referred to within this document exist in the
project’s document
repository.


3

S
COPE

This
document

specifically addresses th
e following areas of
system decommission
:



Application Component Decommissioning Plan (ACDP)



Application Maintenance Prioritization Plan (AMPP)



Asset Management Plan (AMP)



Communications Process Plan (CPP)



Contract Management Plan (CMP)



Fiscal Transition Pl
an (FTP)



Interface Management Plan (IMP)



Mainframe Decommissioning Plan (MDP)



Operations Shutdown Plan (OSP)



System Decommission

Functional Organization



Project Governance and Communication Plan (PGCP)



Project Processes Management Plan (PPMP)



Records Mana
gement Plan (RMP)



State Staffing Plan (SSP)


Multiple processes have been defined to suppor
t
formal
system decommission.

Project Charter (
WorkSite

#
___
)

Project Closure Functional Organization (
WorkSite

#
___)

Governance and Communications Plan

(
WorkSite

#
_
___
)

Project Closure Workplan (
WorkSite

#
____
)

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
10

of
37


4

REFERENCES



Office of Systems Integration Best Practices Website:
http://www.bestpractices.osi.ca.gov/



Department o
f General Services (
DGS
)



Office of Technology Services (
OTECH
)

5

ACRONYMS


AppSrv

Application Services Workgroup

BusAdm

Business Administration Workgroup

COMREQ

Communications Request

ConFis

Contracts / Fiscal Workgroup

DGS

Department of General Servic
es

DoD

Department of Defense

OTECH

Office of Technology

Services

EMU

Enterprise Management Unit

ACDP

Application Component Decommissioning Plan

AMP

Asset Management Plan

AMPP

Application Maintenance Prioritization Plan

CMP

Contracts Management Plan

CPP

Communications Process Plan

FTP

Fiscal Transition Plan

IMP

Interface Management Plan

MDP

Mainframe Decommissioning Plan

OSP

Operations Shutdown Plan

PGCP

Project Governance and Communication Plan

PPMP

Project Processes Management Plan

RMP

Recor
ds Management Plan

SSP

State Staffing Plan

IRS

Internal Revenue Service

IT

Information Technology

MCR

Maintenance Change Request

STD

State Standard Form

TecSrv

Technical Services Workgroup

UPS

United Parcel Service

6

SYSTEM DECOMMISSION

PLANS


The
S
ystem Decommission

Project Team has developed, adopted and implemented
a
specific methodology for governance, structure and communication in support of project
closure. The Project Governance and Communications Plan (PGCP
) describes

the
governance organiz
ation and the process used to focus internal and external
stakeholder resources on the human, budgetary, regulatory and physical aspects of this
<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
11

of
37


system decommission
. The organizational structure has been developed to plan and
execute a structured project
shutdown ensuring that all human and physical assets are
properly dispositioned.
T
he Communication Management Plan outlin
es

the exchange
of information amongst project stakeholders.
The
System Decommission

Management
Team is primarily responsible for the
management of the approach
outlined by these
documents
and
the
execution of
all associated
tasks
.

The
organizational and

functional
structure
(s)

for
system decommission

are

depicted in the following diagram
s:

SYSTEM DECOMMISSION ORGANIZATION CHART
State and Federal
Regulatory Groups
CDSS
/
DHCS
Joint Executive
Briefing Committee
(
Monthly
)
OSI

Executive
Briefing Committee
Oversight Mangement
<
Name
>
Regulatory and Governance Groups

Project Sponsor
<
Name
>
Health and Human
Services Agency
Office of Systems
Integration
.
Executive Offices
.
Budget Office

Enterprise Service Center
.
Administrative Services
.
Acquisitions
.
.
User Group Organization
User Groups
Project Director
<
Name
>
System Decommission
Project Manager
<
Name
>
Business Administration
Workgroup
<
Name
>
..
Budget Lead

-
<
Name
>
.
HR
/
Staffing Lead

-

<
Name
>
Workplan Manager
<
Name
>
Migration Workgroup
<
Name
>
Application Services
Workgroup
<
Name
>
Technical Services
Workgroup
<
Name
>
Communications

Workgroup
<
Name
>
Contract Management
/
Fiscal Impact Workgroup
<
Name
>

-

Migration Lead

-

<
Name
>

-

Business Analyst

-

<
Name
>
..

-

Quality Control Lead

-
<
Name
>
.

.


Technical Architecture

-

<
Name
>
.
-

Communications Lead

<
Name
>

..

.
.
-

Contracts Lead

-

<
Name
>
.
-

Records Lead

-

<
Name
>
.
-

Asset Mgmt Lead

-

<
Name
>

System Decommission
Project Lead
<
Name
>

Department of Technology
Services







Figure
1



System Decommission
Organizational Chart

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
12

of
37


Project Management
Workgroup
<
Name
>,
Project Lead
The Project Management Workgroup is responsible for the overall
success and closure of the project
.
Tasks include
:
1
)
Project Level Documents and Plans
(
Charter
,
Governance
,
PMP
,
etc
.)
2
)
Management of the Project Critical Path and Deliverables
3
)
Status Reports
4
)
Risk and Issues Management
SYSTEM DECOMMISSION WORKGROUP
DEFINITION TABLE
Business Administration
Workgroup
<
Name
>
This workgroup is tasked with
items relating to the human
resources and administrative
details of the project
.
Tasks
will include
:

1
)
HR
/
Staffing Plans

2
)
SETS
/
CalSTARS

3
)
Budget Interfaces

4
)
Bldg
&
Facilities Mgmt
Migration Workgroup
<
Name
>
Application Services
Workgroup
<
Name
>
Technical Services Workgroup
<
Name
>
This workgroup is tasked with
items relating to the migration
and conversion details in
support of the county efforts
.
Tasks include
:

1
)
‘Wave’ Progression

2
)
Data Conversion

3
)
<
Future Project
>
Team
Interface



This workgroup is tasked with
items relating to the ongoing
business and application
process during project closure
and migration
.
Tasks will
include
:

1
)
Application Maintenance

Prioritization Plan

2
)
Work Order Mgmt

3
)
Interface Mgmt Plan

Communications Workgroup
<
Name
>
Fiscal
/
Contract Management
Workgroup
<
Name
>

This workgroup is tasked with
items relating to accurate and
timely communication relevant
to all stakeholders
.
Tasks will
include
:

1
)
SPOC

2
)
Internal Communications

3
)
External Communications

4
)
Communications Plan



This workgroup is tasked with
items relating to the budget
and contracts associated with
the
<
Project Name
>
Project
.
Tasks will include
:

1
)
Records Management

2
)
Asset Management

3
)
Vendor Contracts

4
)
Procurement Activities


This workgroup is tasked with
items relating to the network
,
hardware
/
software and server
environment
.
Tasks will
include
:

1
)
DTS Interface

2
)
County IT Transition

3
)
IT Equipment Transition

4
)
OSI Consolidation Effort

WorkPlan Manager
<
Name
>
Project Manager
<
Name
>

Figure
2



System Decommission

Functional Organization

Chart





The Workgroups were formed in
__

quarter of
<Calendar Year>

and began to meet to
discuss the app
roach to shutdown including specific roles, responsibilities and
associated tasks.

During the
___

quarter of
<Calendar Year>
, workgroup members and
<Project Name>

Project Subject Matter Experts (SMEs) were tasked with development of the following
plans:

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
13

of
37


6.1


Application Component Decommissioning Plan (ACDP)

Identify application components that need to be decommissioned such as:
p
roduction,
t
esting and
t
raining Regions,
business

a
pplications,
a
pplication and
s
ystem
u
ser ID’s,
f
ile transmissions,
a
d
-
h
oc proces
ses,
and

b
atch processes. The workgroup will identify
decommissioning timeline, the validation criteria and which workgroup or individual is
responsible for the activity.

6.2


Asset Management Plan (AMP)

Identify
all hardware, software, network devices, and
non
-
IT equipment regardless of
location or ownership. Activities include: development and population of an asset
management database, inventory and validation of assets, development and
implementation of policies and procedures; and disposition of assets (
including the
decommissioning process)
.

6.3


Application Maintenance Prioritization Plan (AMPP)

T
he
A
MPP

will assist the
<Project Name>

Project in determining which requests for
changes to the application will be accepted and which will be rejected during pro
ject
closure. The plan will include
all
work efforts
(major work orders, minor changes, and
small production fixes).

The plan will govern
all <Project Name>

applications. The plan
will include additional activities such as software upgrades, existing su
pport end dates
,

communication outputs and exception criteria.

6.4


Contract Management Plan (CMP)

Identify
a
ll

written agreements with any non
-
<Project Name>

entity for products and/or
services (e.g.
OTECH
, Unisys,
Oracle,
and UPS). Activities include: iden
tification of all
contract terms and conditions; understand termination and/or amendment; fiscal
impacts, opportunities for ramp
-
down of services products and licensing; and assess
final disposition of contract
.

6.5


Communications Process Plan (CPP)

Communic
ations
d
evelopment and
d
issemination

includes the creation of
the

Communication Plan
for

gathering and facilitating the information share in a readily
accessible and timely fashion. Activities include the definition of the role as single point
of contact,

process, procedures and development of the format and templates
.

6.6


Fiscal Transition Plan (FTP)

Identify fiscal and budget components that need to be transitioned / decommissioned
including all expenditure tracking and interface applications. Activities
include
management and transition of all budgetary actions currently prepared and validated by
<Project Name>

staff (encumbrance, validation, payment and interface).

6.7


Interface Management Plan (IMP)

The Interface Management Plan will include all interface
s, test regions and
decommissioning timeline. Activities will include data retention requirements and
internal/external stakeholder communication activities.

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
14

of
37


6.8


Mainframe
Decommissioning

Plan (MDP)

The Mainframe Decommissioning Plan identifies tasks and res
ponsibilities associated
with the formal shutdown and decommission of the state
-
owned mainframe(s) and
peripherals currently operating at the
Office of

Technology Services (
OTECH
)

<location
name>

Campus
.

6.9


Operations Shutdown Plan

(OSP)

The

Operations Sh
utdown Plan identifies the tasks and responsibilities associated with
the formal shutdown and decommission of the
server infrastructure at OTECH facilities

and Project Management Office (PMO)

computing and network environment
. These
services include produ
ction control operations, servers, network connections and
technical processes.

6.10

Project Processes Management Plan (PPMP)

Activities will include the evaluation of current processes outlined in the
application
maintenance, deliverables management, quality m
anagement, and other project policy
and procedures to
identify changes

or tailoring

that will be required due to
system
decommission
.

6.11

Records Management Plan (RMP)

Identify and disposition all
<Project Name>

business data and information stored in all
fo
rms of media. Activities include: identification of federal and state regulations
regarding retention and disposition; development of plan, policies and procedures; and
identification and disposition of data and information. All Intellectual property right
s must
be reviewed and the proper disposition determined
.

6.12

State Staffing Plan (SSP)

A

collaborative effort coordinated with OSI Human
R
esources of an approved
administrative plan to address the “roll off” of
State
employees due to
system
decommission
. Acti
vities will focus on the identification of Office of Systems Integration
(OSI)/State Personnel Board (SPB) HR policies and procedures which guide and
facilitate the transition of State employees
and the
development of the
appropriate
communication
s
.

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
15

of
37



7

PRO
JECT
KEY DATES / ACTIVITI
ES
SCHEDULE


<Placeholder for graphic showing overall timeline and key milestones>





Figure
3



System Decommission

Key Dates / Activities Timeline


8

APPLICATION COMPONEN
T DECOMMISSIONING PL
AN

8.1

Purpose

The Application Component Dec
ommissioning Plan (ACDP) identifies the various
application components which need to be de
-
activated (decommissioned) as the
<Project Name>
counties migrate to
<Future System>
. This plan also includes the
approach and recommendations associated with the shu
t
-
down of
<Project Name>

Project Management Office specific applications (
e.g. Ticket and Issue Tracking, Time
Reporting, Employee Database,
WEB,
and Ad
-
Hoc).

8.2

Scope

This Plan identifies procedures used to govern and communicate with specific focus on
the f
ormal application component activities necessary to ensure all applications are
properly de
-
activated and/or disconnected on key action dates.

8.3

Update Triggers

The plan will be updated as required to support the timely inclusion of information
relating to S
tate/Federal mandates or policy interpretations as they relate specifically to
the
i
nterfaces
which interact with

the existing
<Project Name> a
pplication
s
.


In addition to the mandatory review and update with change in mandates, regulation or
interpretatio
n of policy, the plan will be reviewed on a quarterly basis to incorporate
lessons learned.

8.4

Approach

8.4.1


(Project Name)

Applications


<Describe the approach which is being taken for the system decommission of major
system(s) which have been developed and mai
ntain to benefit and serve the customers
or end users of the project.>




<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
16

of
37


8.4.2

Service Delivery

and Service Management

Support Systems

<Describe the
approach to decommissioning the systems which help manage work
orders, change requests, production tickets and i
ssues, and other activities directly
associated with maintaining and operating the systems in section 8.4.1 on behalf of the
end users.>

8.4.3

Internal Business Applications

<Describe the approach to decommissioning the systems which have created or
purchased fo
r the purpose of
internally supporting two ISAWS project processes.
Examples are:




A time reporting system
is used in support of vendor invoicing and staff time
reporting to
work order

activities



An employee database system used to s
upport new

and exiting
employee
processing, equipment requirements, and HR reporting compliance (form 700s,
etc.)
.



8.4.4

WEB

The WEB application is used primarily to communicate with external stakeholders.
T
he
workgroup recommends an incremental approach beginning with a freeze to t
he
application followed by a complete shutdown of access. The final disposition of the web
address will be determined by the TecSrv team with our Office of Systems Integration
(OSI) partners. The workgroup recommends application freeze as of
<date>

(unle
ss
federal, state or organizational mandates

otherwise
) with continuance of the activities
associated with web posting until it is deemed no longer required by the management
team as our external partners have migrated out of our operational environment.

8.5

Roles and Responsibilities:

The AppSrv Workgroup has the primary responsibility for communication of
decommissioning of application components. Once communicated, it is the
responsibility of the TecSrv Workgroup to ensure that the components have been
disa
bled appropriately and that the decommissioning is accomplished via instructions
defined in the
Operations Shutdown and Mainframe Shutdown Plans
.

8.6

Risk Identification and Mitigation Strategy:



8.7


Review, Approval and Maintenance:

The plan will be reviewed by

the AppSrv Workgroup, the AppSrv Workgroup Manager,
System Decommission

Management, and the
<Project Name>

Project Director.


It is the responsibility of the AppSrv Workgroup Manager to govern the maintenance
and execution of the components of this plan


<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
17

of
37


9

ASSET MANAGEMENT

PLAN

9.1

Purpose

The Contracts / Fiscal Workgroup is responsible f
or the disposition of all
<Project
Name>

State
-
owned IT and non
-
IT assets. This
plan

defines the process, responsible
parties, contact points, historical documentation, and ris
ks associated with the
disposition of
<Project Name>

assets.

9.2

Scope

This Plan identifies procedures used to govern and communicate with specific focus on
the formal processes necessary to ensure the final disposition of all State/
<Project
Name>

owned assets
.

9.3

Update Triggers

In addition to the mandatory review and update with change in state and/or federal
mandates, regulation or interpretation of policy, the plan will be reviewed on a quarterly
basis to incorporate lessons learned
.

9.4

Approach

The
<Name>

Unit h
as the responsibility within the existing environment to procure,
identify, track and report on the disposition of all I
<Project Name>

state
-
owned assets,
whether they are located in the main headquarters, adjacent OSI offices
,

<Project
Name>

County office
s

or
Office of Technology

Services (
OTECH
)

facilities
.
Existing
<Project Name>

M
aintenance and Operations (M&O)
procedures define procurement,
deployment,
tracking,
maintenance and d
isposition of

IT and
non
-
IT assets. The
<Name>

team maintains an access d
atabase which houses applicable serial numbers,
asset tags, location and current disposition information and will
rely on the existing
policies and procedures to systematical
ly disposition and decommission items as they
are deemed no longer necessary in su
pport of the
<Project Name>
Project.


<Further expand upon the approach with respect to specific project issues and
environmental factors>


9.4.1

Asset Validation


In preparation for project close and final disposition of all assets, the Asset Management
team
has been tasked with validation and baseline of all of t
he assets within the
database. This activity is being don
e in partnership with other System Decommission

Workgroups and external partners as defined below.

9.4.1.1

Non
-
IT Assets

The identification, asset tag
ging and scanning of the non
-
it assets was
assigned to the
BusAdm Workgroup.
<If co
-
located with contractors who own some non
-
IT assets,
discuss how ownership identification and tagging is to be documented and executed>.

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
18

of
37


Once tagged, the items
are
scanne
d and loaded into the Asset Management Tracking
System and
all state assets
will be managed
during

system decommission by
the Asset
Management Team using existing asset dispositioning procedures.


9.4.1.2

IT Assets

(State
-
Owned


Centrally Located
)

IT
-
Assets resi
de in various locations, all of which need to be validated to facilitate final
disposition.
<Unit Name>

staff, at the direction of the
<Unit>

Project Manager began
the validation process for IT
-
assets during the
___

quarter of calendar year
____
.
<Unit>
staff (in partnership with TecSrv) is actively engaged in validation of all IT
-
assets
located at
_______,
OTECH
, and OSI offices.
The results of this validation effort
were

loaded into the
Asset Management

database and will be maintained through dispositi
on
by the Asset Management Team using existing process and procedures.

9.4.1.3

IT Assets (State
-
Owned County
/User Site

Located)

[if applicable]

<This is an optional section for inclusion if the Project owns IT assets which have been
installed at user locations o
r coun
ty sites a
round the stat
e
. Describe the process for
validation and disposition of the inventory.
The activities associated with validation,
recovery and final disposition of county located IT assets will be tracked in the workplan
by
on a county by c
ounty or other logical basis
.
>




9.4.2

Asset Disposition

As defined in section 9.4, above, all assets will be dispositioned via existing process
and procedures. As changes in state and federal mandates are enacted, this procedure
will be updated and assets di
spositioned accordingly.


9.5

Roles and Responsibilities:

Asset Management is a fully documented function of an existing
unit

within
<Project
Name>

M&O. For purposes of
system decommission
, an Asset Manager w
as defined in
the Project Charter

and will serve as
a focal point in managing associated timelines and
critical functions, but does not alter the responsibility or reporting relationship within the
existing
organizational structure
.

9.6

Risk Identification and Mitigation Strategy:


9.7

Review, Approval and Maint
enance:

The plan will be reviewed by the ConFis Workgroup, the ConFis Workgroup Manager,
System Decommission
Management, and the
<Project Name>

Project Director.


It is the responsibility of the
ConFis

Workgroup Manager to govern the maintenance and
execu
tion of the components of this plan



<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
19

of
37


10

APPLICATION MAINTENA
NCE PRIORITIZATION P
LAN

10.1


Purpose

The
Application Maintenance Prioritization Pla
n (AMPP)

will identify the various
Application Maintenance components and the prioritization of the respective work e
fforts
within those components. This plan defines the structure, components, details and the
stakeholders.

10.2


Scope

This Plan identifies the approach to be used to prioritize work efforts such as Application
and Technical system changes
.
System changes are

initiated due to Cost of Living
Allowances (COLAs), enhancement requests and regulatory modifications.


The
<Project Name>

Project will use existing processes and procedures for all work
efforts. This plan will identify these existing processes and addr
ess gaps, if any, as they
relate to project closure activities
.

10.3


Update Triggers

In addition to the mandatory review and update with change in schedule, regulation or
interpretation of policy, the plan will be reviewed on a quarterly basis to incorporate

lessons learned.

10.4


Approach

The
<Project Name>

Project
will continue to use all documented processes and
procedures currently in place to prioritize all application and technical changes during
system decommission.
These processes are defined as follows:


Workgroup analysis
has concluded that anticipated change requests required in support
of
system decommission

can and will be

governed by an existing prioritization process

or procedure
.


10.5


Roles and Responsibilities:

The roles and responsibilities for e
ach of the internal and external stakeholders are
defined in the processes and procedures named in 10.4 above.
N
o modifications
are
required in support of
system decommission

activities
.


10.6


Risk Identification and Mitigation Strategy:


10.7


Review, Approval
and Maintenance:

The plan will be reviewed by the AppSrv Workgroup, the AppSrv Workgroup Manager,
System Decommission
Management, and the
<Project Name>

Project Director.


<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
20

of
37


It is the responsibility of the AppSrv Workgroup Manager to govern the maintenance
and execution of the components of this plan


11

CONTRACT MANAGEMENT

PLAN

11.1


Purpose

The purpose of the Contract Management Plan (CMP) is to manage the termination of
agreements with non
-
<Project Name>

entities in favorable terms and in accordance
with state
and federal contract code and policies.

11.2


Scope

This Plan will
identify

a
ll

<Project Name>

written agreements with any entity for
products and/or services (e.g.
OTECH
, Unisys). Activities include: identification of all
contract terms and conditions;
docu
mentation of

termination and/or amendment

terms
;
fiscal impacts, opportunities for ramp
-
down of services
,

products and licensing; and
assess final disposition of contract
.

11.3


Update Triggers

In addition to the mandatory review and update with change in
st
ate and/or federal
mandates, regulation or interpretation of policy, the plan will be reviewed on a quarterly
basis to incorporate lessons learned.

11.4


Approach

Since
<date>
, at the direction of the
<Project Name>

Project Director, procurement
activities
ha
ve been aligned

with
the scheduled system decommission date of <date.

Since that time, all procurement activities have initiated with an attempt to terminate
services associated with produce and/or services in terms allowing for a phased
approach to count
y migration and subsequent downsizing of associated services. Most
services have been procured with base and option periods sufficient to support
the
system decommission date.



All software, hardware and service contracts have been identified and loaded

into
WorkSite
. Workplan tasks
were created

to review each of these contracts and
categorize them into review cycles which will include extension and termination
alternatives.


11.5


Roles and Responsibilities:

The
Contract Manager, with input from
<Name>
U
nit
has the primary responsibility for
communication of
contract activities (procurement and termination)
.

Input for
termination of these services will be significantly impacted by the success of the Wave
approach to migration. It is the intent of the p
roject to discontinue services in direct
relation to the number of counties active within the
<Current System>

environment and
the number of clients remaining on the system.

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
21

of
37


11.6


Risk Identification and Mitigation Strategy:



11.7


Review, Approval and Maintenanc
e:

The plan will be reviewed by the ConFis Workgroup, the ConFis Workgroup Manager,
System Decommission

Management,
the
<
Project Name>

Contract Manager
and the
<Project Name>

Project Director.


It is the responsibility of the ConFis Workgroup Manager to g
overn the maintenance and
execution of the components of this plan

12

COMMUNICATIONS PROCE
SS
PLAN

12.1


Purpose

The purpose of the Communications Process

Plan

(CPP)

is to
define
the methodology
for sharing information in a
readily accessible and timely fashion.

Activities include the
definition of the role as single point of contact, process, procedures and development of
the format and templates


12.2


Scope


The
System Decommission

Project has a formal Project Governance and
Communications Plan (
WorkSite

#
___
).

The CPP determine
s

the tools and
responsibility associated with the dissemination of information specific to
system
decommission
.

12.3


Update Triggers

The CPP will be updated to support the ongoing distribution of project closure
information. Lessons learn
ed will be documented and incorporated on a quarterly
basis.

12.4


Approach

The CPP has been developed and approved for implementation by the
System
Decommission

Workgroup Managers. The process is fully documented including
templates, formal approval and su
bmission.
In addition to

the process defined in Figure
4
below, the following documents are available for reference:




Communications Request Cover Sheet Purpose and Direction (
WorkSite

#
___
)



Communications Request Template (
WorkSite

#
___
)







<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
22

of
37


12.5

Role and R
esponsibilities

COMMUNICATION REQUEST PROCESS

Workgroup manager
emails CRF and
proposed communication
to COM Workgroup
mailbox
Com Workgroup
discusses
proposed
communication
Communication
Request Form
(
CRF
)
and
proposed
communication
Request
approved by
Com
Yes
Com Workgroup
formats
communication for
release
Prepared
communication
Com Workgroup
Manager distributes
communication via
appropriate vehicle
(
email
,
webmaster
,
newsletter editor
)
Com Workgroup
Manager updates status
on CRF
CRF and proposed
communication
CRF and proposed
communication
No
Yes
Com
Workgroup
Manager returns
request for content
modification
(
response due
from originating
Workgroup
Manager within
24
hrs
)
Com Workgroup
Manager provides
communication to
Project Lead for
approval
Approved
Prepared
communication
Final
communication
Auto response
generated
Log request into
Tracking Database
No
Monitor for response
/
need for follow up
<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
23

of
37



COMMUN
ICATION REQUEST PROCESS (contin
ued)


Workgroup manager
emails CRF and
proposed communication
to Comm mailbox
Communication
Request Form
(
CRF
)
and
proposed
communication





Auto response
generated







Log request into
Tracking Database



Com Workgroup
discusses
proposed
communication
CRF and proposed
communication


Request
approved by
Com



Com
Workgroup
Manager returns
request for content
modification
(
response due
from originating
Workgroup
Manager within
24
hrs
)
CRF and proposed
communication


Proposed commun
ication, with complete
message, is passed from Workgroup via their
manager. The CRF (
WorkSite

doc#
___
) &
Communication Request Coversheet Purpose &
Directions (
WorkSite

doc#
___
) are the vehicle for
the request.

Access database named “Communications Reques
t Tracking” stored
on the
shared drive and viewable

by
System Decommission

Workgroup Managers
, their backups, and the Communications
workgroup members. The database is u
pdated as requested
communications are received, processed & released.




Email received in
<email box name>

mailbox will trigger an auto
-
response acknowledging receipt.


Workgroup (o
r subset of workgroup) review
proposed communication.
Determine if any
information requires confirmation; eg. Content,
distribution list, release timeframe
.

If
Yes
, assign to Com Workgroup member to format for release.
Coversheet updated by Approver.


If
No
, assign to Com Workgroup Manager for return to submitting
Workgroup Manager.

Update Tracking Database.

Skip if request was approved.

Coversheet update in
WorkSite
. Email with .nrl
From Com Workgroup Manager to submitting
Workgroup Manager, noting reas
on for return and
turnaround window.

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
24

of
37


COMMUN
ICATION REQUEST PROCESS (contin
ued)




Com Workgroup
formats
communication for
release
Prepared
communication




Com Workgroup
Manager provides
communication to
Project Lead for
approval
Prepared
communication



Approved





Com Workgroup
Manager distributes
communication via
appropriate vehicle
(
email
,
webmaster
,
newsletter editor
)
Final
communication


Com Workgroup
Manager updates status
on CRF


Monitor for response
/
need for follow up


Figure
4



Communication Request Process

Update Tracking Database to document release

Communication released from Comm mailbox.
Submitter included as a recipient of email
distribution. Read Re
ceipt Request to be applied
to communications that require response.

If
Yes
, Communication is released, including submitter in
distribution. Send with Read Receipt. Update Tracking Database.


If
No
, C
omm Workgroup Manager returns request to submitting
Workgroup Manager for necessary modifications. Comm Workgroup
Manager updates Tracking Database.

Electronic copy is forwarded to Project Lead for
approval prior to release.


Com assignee prepares letter or memo, as
appropriate, for email distribution; newsletter
article or FAQ for intranet posting. Submitting
Workgroup Manager to be identified as “Source”.
Electronic copy to be watermarked

“DRAFT” and
passed to Com Workgroup Manager
.

Based on presence of a Response Due date monitor for reply and
need for follow up. Record activity in Tracking Database.

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
25

of
37



12.6


Risk Ident
ification and Mitigation Strategy:


12.7



Review, Approval and Maintenance:

The plan was
reviewed by the
COM

Workgroup, the
COM

Workgroup Manager,
System
Decommission

Management, and the
<Project Name>

Project Director.


It is the responsibility of the
COM

Wo
rkgroup Manager to govern the maintenance and
execution of the components of this plan

13

FISCAL TRANSITION
PLAN

13.1


Purpose

The Business Administration Workgroup is responsible for the transition of the fiscal and
budget activities currently performed by
<Pro
ject Name> <Unit Name> Unit
. This plan
defines the process, responsible parties, contact points, historical documentation, and
risks associated with the transition of these activities.

13.2


Scope

Federal and state policies and mandates require that certain f
iscal activities remain
functional after formal project closure. This plan addresses the transition of activities to
ensure that all financial instruments are redeemed and archived.

13.3


Up
date Triggers

The plan will be updated to support the timely inclusi
on of information relating to all
state and federal mandates related to dispositioning financial records.


In addition to the mandatory review and update with change in mandates, regulation or
interpretation of policy, the plan will be reviewed on a quarte
rly basis to incorporate
lessons learned.

13.4


Approach

The fiscal and budget activities
are
performed
by the <Project Name>
Project in
partnership with parallel Office of Systems Integration (OSI) entities. The roles and
responsibilities associated with th
e transition of the fiscal and budget activities are
inherent within the definition of the existing structure and approach to transition and
termination. The OSI Budget Office

and
OSI Accounting Office will own fiscal and
budget responsibility at project c
lose. These entities will also ensure that the processes
continue as required in support of external mandates.


The
<Project Name>

Project Director is responsible for adherence to the
<Project
Name>

Project Budget spending authority. This is accomplishe
d by review and
approval of planned and actual expenditures.
The
Contract Manager and Fiscal Analyst
<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
26

of
37


maintain project level documents which provide for accurate management of budget line
items by
<Project Name>

Management.


The OSI Accounting Office is t
he recipient of all original invoices. Once received by
Accounting, invoices are logged and forwarded to
project staff

to facilitate project level
review and approval for payment. Approved documents are forwarded back to
Accounting and sent through for r
eview and approval and payment as required by OSI
Accounting policy and procedures.


The OSI Budget Office interfaces with
project m
anagement and
fiscal

staff to plan
monitor and maintain the
project budget
. OSI Management has the cost center signing
auth
ority for all procurement activities in concert with the Health and Human Services
Agency (HSA) and other state and federal partners. As such, the OSI Budget Office
manages the high level cost center activities and overhead providing guidance and
support
to the project level utilization of funds provided by the Governor’s budget.


The transition and discontinuance of fiscal processes relates specifically to those
activities currently performed by the
<Project Name>

Financial Analyst. The tasks
performed

by the
Financial Analyst

are defined in
Financial Analyst
Responsibilities List
(
WorkSite

#
___
).


Tasks to transition as fiscal staff leave or system decommission is completed includes
the following
:


o

OTECH

Invoice

processing

o

Monthly Budget Reports w/pro
jections

o

Memo Bill Processing

o

Consultant Services Invoice Processing

o

Premise Documents

o

Purchase Order Management

o

Expenditure Tracking


(CalStar
s

and SETS)


13.5


Risk Identification and Mitigation Strategy:

The workgroup has determined that any risk factor
s associated with the transition of
these activities will be mitigated by either 1) transition of state staff to augment the
transition of responsibility and 2) by accelerating the schedule to allow for execution of
activities with
<Project Name>

Managemen
t in an oversight role to ensure continuity
.

13.6



Review, Approval and Maintenance:

The plan will be reviewed by the
BusAdm

Workgroup

Manager
, the ConFis Workgroup
Manager,
System Decommission
Management, and the
<Project Name>

Project
Director.


It is the

responsibility of the ConFis Workgroup Manager to govern the maintenance and
execution of the components of this plan

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
27

of
37



14

INTERFACE MANAGEMENT

PLAN

14.1


Purpose

The Interface Management Plan (IMP) identifies the various interfaces with the other
California Sta
te agencies and 35 ISAWS counties. This plan defines the interfaces,
details, responsible parties, contact points, historical documentation and
decommissioning schedule.

14.2


Scope

This Plan identifies procedures used to govern and communicate with specific
focus on
the formal interface changes necessary to ensure all the
i
nterfaces with counties and
other agencies are properly deactivated / disconnected on key action dates.

14.3


Update Triggers

The plan will be updated as required to support the timely inclusi
on of information
relating to State/Federal mandates or policy interpretations as they relate specifically to
the
i
nterfaces executed by the existing
system(s)
.


In addition to the mandatory review and update with change in mandates, regulation or
interpre
tation of policy, the plan will be reviewed on a quarterly basis to incorporate
lessons learned.

.

14.4


Approach

This plan defines the approach for both batch and online interfaces.

The
“Application
Services Workgroup Interf
ace Management Worksheet” (
WorkSit
e

#
___
) is a
comprehensive list of all interface files, processes and transfer protocols by county.


The
<Project Name>

project intends to leverage existing processes to de
-
schedule, de
-
activate and reactivate (if required) application interfaces. The mai
n process to be used
is defined in the
<existing procedural document>

(
WorkSite

#
____
). The key factor for
de
-
activation of outgoing batch interfaces will be the delivery of a run schedule change.
Inbound interfaces are currently managed by a file monitor
ing process and will be
deactivated by delivering an FTP Registration Form, also defined in the
existing
procedures
.


14.5


Roles and Responsibilities:

The Interface Management Group

is responsible for the monitoring and reporting of key
dates and activitie
s associated with interface management components of
the system
decommission effort.


<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
28

of
37


AppSrv is responsible for the creation and submission of the interface deactivation
documents required to support the processing defined in the
existing project
procedure
s
.


AppSrv is responsible for developing the content of the communication to internal and
external stakeholders related to the deactivation of all interfaces.




60 days prior to deactivation,

a

generic letter to all stakeholders indicating the
timing associ
ated and stating that the interface will be discontinued



30 days prior to deactivation
, a
letter to

specific stakeholders indicating that
the interfaces (inbound and outbound) will be discontinued. This
communications needs to include instructions to the
entity

on
making a
file
recovery request for information retained with the
<current system>
prior to
‘go
-
live’



Within two (2) days after rollback/no rollback decision
a

follow
-
up letter to
external stakeholders that
<current system>

is no longer the ‘syste
m of
record’.


The
COM

Workgroup

will coordinate all
system decommission

communications via

in
accordance with the

CPP.


TecSrv will be responsible to ensure that modifications to daily processes are accurately
applied to disable/deactivate the in
t
erfaces.


ConFis will ensure that no fines are imposed by external partners once notified of the
discontinuance of the interfaces.


14.6


Risk Identification and Mitigation Strategy:



Unanticipated Costs
-

<Project Name>

needs to ensure that activities engaging
extern
al partners do not have fees associated. Mitigation will be accomplished
by early notification and consistent follow
-
up asking for early disclosure of
associated costs.



The workgroup has identified that there is a potential risk associated with the
schedu
le of the deactivation of the interfaces because it occurs prior to the
rollback/no rollback decision. The workgroup is anticipating that this risk will be
mitigated as part of the ‘rollback plan’ but encourages that the plan/impact be
reviewed upon compl
etion to reduce the probability of potential data loss.


14.7



Review, Approval and Maintenance:

The plan will be reviewed by the
AppSrv

Workgroup, the
AppSrv

Workgroup Manager,
System Decommission

Management, and the
<Project Name>

Project Director.


It is t
he responsibility of the
AppSrv

Workgroup Manager to govern the maintenance
and execution of the components of this plan

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
29

of
37


15

MAINFRAME DECOM
MI
SSIONING
PLAN


15.1


Purpose

The Mainframe Shutdown Plan (MSP) identifies how the
<Company>

Mainframe(s) and
peripherals
will be deactivated and decom
m
ission
ed

at project close.

15.2


Scope

This Plan identifies the tasks and responsibility associated with the formal disposition
and decommission of the
mainframes

owned by the
<Project Name>
Project at project
close
.

15.3


Update Tr
iggers

The plan will be updated as required to support the timely inclusion of information
relating to State/Federal mandates or policy interpretations as they relate to
decommissioning of state property.


In addition to the mandatory review and update wit
h change in mandates, regulation or
interpretation of policy, the plan will be reviewed on a quarterly basis to incorporate
lessons learned.

.

15.4


Approach


The project will engage the mainframe contractor
in the activities required at shutdown.
In general
, these services will include the deactivation of the mainframe partitioning,
shutdown of the service processors,
Single Point of Operator Services
(
SPOs
)
, and
disconnection of the mainframe from the DC and AC power source(s).
Contractor
services will also

include a certification process which will allow the State of California to
ship and/or res
ell

equipment. These activities include validation that:



equipment is operational and qualified for Certification;



equipment is clean, inside as well as outside,
and ready for packing;



equipment is packed in accordance with equipment specification;



all skins and panels are in place; and



the entire unit is properly wrapped in a protective cover.


In addition to the mainframe specific services, there are addition
al services which would
need to be managed in support of the shutdown. Mainframe
peripheral
components
such as the SUN, EMC and C
entera

systems need managed shutdown, as well the
disposition of tape storage. In preparation for the facilitation of activit
ies required in
support of shutdown, the following items must be researched, and documented:




<Project Name>

must reach out to
OTECH

and ask if they are interested in
the tapes currently used to support the
project

environment. Should they
want to retain
these tapes, activities would need to be added to the workplan
<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
30

of
37


to support the ‘dega
u
ssing’ of the tapes to ensure proper destruction of
information.



The formal shutdown and validation of the mainframe must be done by
the
contractor
. Activities for inclus
ion in a services request are documented as
XXXXXXX (
WorkSite

#
____

).


15.5


Roles and Responsibilities:

The
AppSrv

Workgroup has the primary responsibility for communication of schedule
associated with the disposition of the
<Brand>

Mainframes. TecSrv will

engage and
monitor the execution of the certification and decom
m
ission activities by the vendor and
ConFis will ensure that all contracts are properly terminated. The final
decommissioning of the hardware will be the responsibility of ConFis

in

partnersh
ip with
the
Department of General Services (DGS).

15.6


Risk Identification and Mitigation Strategy:


15.7



Review, Approval and Maintenance:

The plan will be reviewed by the
TecSrv

Workgroup, the
TecSrv

Workgroup Manager,
ConFis Workgroup Manager,
System Decom
mission

Management,
Contract Manager
and the
<Project Name>
Project Director.


It is the responsibility of the
TecSrv

Workgroup Manager to govern the maintenance and
execution of the components of this plan



16

OPERATIONS SHUTDOWN

PLAN

16.1


Purpose

The Techni
cal Services Workgroup is responsible for the shutdown of the
<Project
Name>

application
s

and associated network components. This plan defines the
process, responsible parties, contact points, historical documentation, and risks
associated with the structu
red shutdown of the IT infrastructure supporting the
p
roject

16.2


Scope

This Plan identifies procedures used to govern and communicate the activities and
responsibilities to ensure the
orderly and non
-
disruptive cessation of IT operations as
part of system d
ecommission.


16.3


Update Triggers

The plan will be updated as required to support the timely inclusion of information
relating to State/Federal mandates related to privacy and security.


<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
31

of
37


In addition to the mandatory review and update with change in manda
tes, regulation or
interpretation of policy, the plan will be reviewed on a quarterly basis to incorporate
lessons learned.


16.4


Approach


<Describe the project approach to shutting down the technical infrastructure. Describe
the request process for network

disconnection or change requests and the anticipated
timing in relation to migration or
system decommission. How will these requests be
coordinated with the OTECH Customer Request System (CSS)?


T
he team
recommends

the following discussions be held with
external partners to be
sure that the expectations by all are met and managed.




OTECH

o

Existing requests are by site, can we submit these requests by county
listing all sites on one form

o

Validate whether or not we can submit a conditional discontinuation an
d
what the variables would be (submission date, how many days notice to
cancel, cost associated with cancelling or extending the date for
implementation)

o

Funding


16.5


Roles and Responsibilities:

The AppSrv Workgroup has the primary responsibility for commun
ication of schedule
associated with the disposition of the network connections. TecSrv will initiate and
monitor the execution of the
OTECH

service requests and ConFis will ensure that all
contracts are properly terminated (including assessment of the imp
act to the MICS
Report). The final decommissioning of the hardware will be the responsibility of ConFis
in partnership with the Department of General Services (DGS).

16.6


Risk Identification and Mitigation Strategy:

The use of existing process and direct c
ommunication with our
OTECH

partner will
mitigate any risk which may be associated with this approach.

16.7



Review, Approval and Maintenance:

The plan will be reviewed by the
TecSrv

Workgroup, the
TecSrv

Workgroup Manager,
Management, and the
<Project Name>

P
roject Director.


It is the responsibility of the
TecSrv

Workgroup Manager to govern the maintenance and
execution of the components of this plan


<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
32

of
37


17

PROJECT PROCESSES MA
INTENANCE PLAN

17.1


Purpose

The purpose of the Process Maintenance Plan (PMP) is to review

the impact on project
closure to ongoing Maintenance and Operations (MO) policies and procedures.

17.2


Scope

Activities will include the evaluation of current processes outlined in the Application
Change Procedure, Deliverable Management Matrix, Software Qu
ality Assurance
Manual and any other Project Policy documentation. The plan will identify
an approach
for implementation of a change, should it be required, in support of project closure.

17.3


Update Triggers

In addition to the mandatory review and update wi
th change in mandates, regulation or
interpretation of policy, the plan will be reviewed on a quarterly basis to incorporate
lessons learned.

17.4


Approach

The existing
<Project Name>

o
rganization is formally documented and relies on the
adherence to project

level policies and procedures to ensure that Service Level
Objectives (SLOs) are maintained and the project vendors, resources, and application
components are effectively managed. The definition of these processes and
procedures exists in the
<Project ch
ange procedure documentation>
. A copy of this
document is available in the document management reposi
tory as
WorkSite

(#
____
).
The workgroup identified and listed existing policy and procedures and these are
available as AppSrv Project Process Document
List (
WorkSite

#
____
). Any
modification required to any of these processes will be communicated to All
-
Staff via
CPP initiated by
<Project Name>

Management.

17.5


Roles and Responsibilities:

The
AppSrv

Workgroup has the primary responsibility for
the communi
cation of changes
required to ongoing policies and procedures in support of project closure.
Once
communicated,
it is the responsibility of
<Project Name>

Management

to ensure that
the
policies and procedures being followed are in line with the currently
mandated
approach
.

17.6


Risk Identification and Mitigation Strategy:

This plan employs existing policy and procedures an
d

incorporates the benefits
associated with no risk identified.

17.7



Review, Approval and Maintenance:

The plan will be reviewed by the
AppSr
v

Workgroup, the
AppSrv

Workgroup Manager,
SD

Management, and the
<Project Name>

Project Director.


It is the responsibility of the
AppSrv

Workgroup Manager to govern the maintenance
and execution of the components of this plan

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
33

of
37


18

RECORDS MANAGEMENT P
LAN

18.1


Purpose

The Contracts/Fiscal Workgroup is responsible for the retention of all project records.
This plan defines the structure, components, details and the stakeholders associated
with the record retention process

18.2


Scope

This Plan identifies the approa
ch to be used to ensure the final retention of all project
records required support state and federal
information retention and security mandates.

18.3


Update Triggers

In addition to the mandatory review and update with change in schedule, regulation or
inte
rpretation of policy, the plan will be reviewed on a quarterly basis to incorporate
lessons learned
.

18.4


Approach

State and Federal policies will mandate the general terms for disposition of all
information
.

The
project

will develop and communicate a Recor
ds Management Policy
for implementation during project clo
sure. This policy will interpret and document the
Records Retention Guide located on the DGS website
http://www.osp.dgs.ca.gov/recs/rrhtoc.ht
m

.


The basic premise of records retention is the storage and access
of
original
documents
used to support fiscal elements of a state project.
The project

is not the recipient of
original documents. Partner offices within the OSI organization receive,
maintain and
account for original documents. The first task in Records Management will be to identify
the owners of original documents, and solicit acknowledgement from those owners of
such. A formal letter documenting our understanding of documents with
in each partner
organization will be finalize
d

and delivered for signature/acknowledgement. The
memorandum
resides in
WorkSite

(#
____
) and will be scanned in with original
signatures when complete.


The second step in development of a records retention po
licy/procedure is to solicit the
organization to gain an understanding of what is housed in each employees work
location to assess relevance and h
istorical impact.
The <Name> Unit will
solicit
information from
each project employee
. The results will be
c
ompiled and
evaluated
and a policy developed to assist the organization in the archive and/or destruction of
information.


A subset of this policy will address the disposition of employee workspaces as they
transition from the project. It will als
o define

a Single Point of Cont
act (SPOC)
whose

responsibility it will be to determine the final disposition of documents/materials not
covered by generic policies.


<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
34

of
37


All electronic data repositories will be archived, indexed and stored in accordance with
DGS elect
ronic media policy.




18.5


Roles and Responsibilities:

The ConFis Workgroup has the primary responsibility
for the formulation of policy and
disposition of records associated with the
p
roject. All policies will be reviewed with OSI
and
<Project Name>

manag
ement prior to introduction to staff.

18.6


Risk Identification and Mitigation Strategy:

Validation of policy

and review of
<Project Name>

interpretation and intent with OSI
Department Managers will reduce the risk associated with archive and storage of
proje
ct history.

18.7



Review, Approval and Maintenance:

The plan will be reviewed by the
ConFis

Workgroup, the
ConFis

Workgroup Manager,
SD

Management, and the
<Project Name>

Project Director.


It is the responsibility of the ConFis Workgroup Manager to govern th
e maintenance and
execution of the components of this plan


19

STATE STAFFING PLAN

19.1


Purpose

One of the key
System Decommission
tasks
is

the development of a plan which w
ill
address the transition of

OSI

State of California employees who currently support
va
rious functions within the maintenance and operation of
<Project Name>.

19.2


Scope

The
OSI

has made a commitment to sup
port the integration of
<Project Name>

State of
CA
employees

into other OSI divisions

or projects
. The State staff offer a variety of
knowl
edge, skills and abilities

that will
continue
to support OSI organizational goals and
operations. This document will outline a pla
n which will serve two purposes;



1)

Develop a resource plan which will ensure continued maintenance and
operation of
the projec
t

until the last wave of
counties

are migrated to the
<new
system>.


2)

Develop a “transition off” plan for
all

<Project Name>

State employees.



It is important to note for purposes of this document that one of the risk factors for
system decommission

is th
e
early departure of
State resources
to other State
employment opportunities. The impact of a reduction in State resources
which
currently
support various functions within the project

organization will be
continually

monitored
.
I
t
<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
35

of
37


is anticipated that State

staff will avail themselves to all opportunities for employment
within the State of CA
. The

strategies o
utlined

in this document are developed to
mitigate that risk and to address
contingency staffing plans which will serve as a
proposed solution until
co
mpletion of system decommission
.

19.3


Update Triggers

In addition to the mandatory review and update with change in mandates, regulation or
interpretation of policy, the plan will be reviewed on a quarterly basis to incorporate
lessons learned.

19.4


ISAWS Syst
em Support Resource Plan


The
project

organization is currently structured into
<number>

sections which are led by
a
Project Director
.


The sections are currently staffed as follows:


1)

<Section Name>

(
<units>)


-


<number> <classification>

-

<number> <class
ification>


2)

<Section Name>

(
<units>)



-


<number> <classification>

-

<number> <classification>


3)

<Section Name>

(
<units>)


-


<number> <classification>

-

<number> <classification>


4)

<Section Name>

(
<units>)


-


<number> <classification>

-

<number> <classifi
cation>



Until the end of
<month year>

project

maintenance and oper
ation functions will require
resources
to
provide ongoing support.

As
counties migrate to <new system>

various
operational support functions
and task
s

will be ramped down

by a phased appro
ach.


In addition to routine maintenance and operational support
functions
, the system
decommission

master project plan will
include

additional activities that need to occur
.


<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
36

of
37


Analysis has been completed on the bulleted items below
to identify

current

“Sta
te”
staff
supported
functions required for ongoing

maintenance an
d operation of the
systems

until
<month year>
.




Identification of operational functions support
ed by State resources



Identification of critical support ta
sks perform or supported by State res
ources

that provides

ongoing maintenance and operations

for the

c
ounties.



Formulation of resource contingency planning for State employee supported
functions.



As an initial strategy, as State positions are vacated they will not be re
-
advertised
. The
Proj
ect will

develop a plan to ensure appropriate cross training is instituted to provide
adequate support.
Also, an another contingency, various OSI
Centralized S
ervices
offices

and other OSI partners may be able to
support
some

State supported functions.
Le
ss desirable options for contingency plans include utilizing student assistants,
consultant resources or request
ing exemptions
to fill State vacated positions with

limited
term State resources.

19.5


State Staff Transition (Rolloff) Plan

The current staffing

transition pla
n calls for the transition of all

St
ate employees at
various classifications ranging from the DPM management series, IT analytical series to
O
ffice
T
echnician. OSI has made a commitment to evaluate opportunities to absorb all
project State

s
taff within current and future vacancies

within the various OSI Projects
and OSI Centralized Services
.


The following activities are being performed in a collaborative effort between
OSI
Human
R
esources
the
<Project Name>
Project Director and the
System De
commission

Project Management to assist
in the successful placement of
State

staff:




Ongoing evaluation and review of OSI vacancies



Mee
ting with OSI executive management and OSI Project Directors
to discuss
staff opportunities



Formulation of a
State
staff

“roll off” plan



Statement of qualifications completed by each State employee.



Each State employee has completed a Statement of Qualifications document which
outlines the
ir

knowledge, skills, abilities, goals and accomplishments. This document
will serv
e as a tool for OSI Executive management, OSI Project Director and OSI
Human resources to determine a “best fit” for State staff within the OSI organization.


The formulation of the “roll off plan” for State staff was determined by an evaluation of
each S
tate staff function and an assessment by the
S
tate management team of when
State supported function
s

could be “rolled off” during the migration of the. counties to
the
<new system>
.
Based upon
a
preliminary ass
essment

a plan has been developed
which identi
fies the transition of all ISAWS State Staff as summarized
below:

<Project Name>


Sy
stem Decommission Planning Guide

Office of Systems Integration


<Date>

OSIAdmin #____

Page
37

of
37




As system decommission proceeds,
revision
s

of the proposed “roll off” plan
and
schedule can be expected. T
he
<Project Name>
Project Director is aware that OSI
vacancies and opportunities
for State staff to transition off may not occur during the
desired planned “roll off” period
.
Opportunities may present themselves for
S
tate staff
at
any time.

The commitment to ensure State staff
secure another

State position prior to
completion of system

decommission

is of the utmost priority. An assumption is that OSI
Project Directors and the
<Project Name>
Project Director will negotiate to allow for
flexibility in a transition period or reach an agreement to allow “sharing” of State
resources for supp
ort of
migration and system decommission activities.

19.6


Roles and Responsibilities:

The
SD Management

Team

has the primary responsibility for communication
and
implementation of the SSP.

19.7


Risk Identification and Mitigation Strategy:

The
SD Management

Tea
m reviewed the components of this plan with the OSI Human
Resources (OSI HR) Department. Resources is a risk factor identified and managed at
the project level and mitigation factors are implemented at the direction of OSI HR in
concert with
state and fed
eral regulations.

19.8



Review, Approval and Maintenance:

It i
s the responsibility of the
SD Management

Team, at the direction of the ISAWS
Project Director

to govern the maintenance and execution of the components of this
plan