eCIO PPT Sunsetting strategy v 3 general distribution

DEVELOPING AN APPLICATION RETIREMENT AND
DECOMMISSIONING STRATEGY FOR A LARGE-SCALE PROJECT
PRIMER OVERVIEW AND FRAMEWORK PAPER
(DOC #: PROJECT-ARD.001 V 0.3 DRAFT FOR DISCUSSION PURPOSES
CONFIDENTIALLY: GENERAL RELEASE
IT 2700-XX V 0.1
PRESENTATION
IT Project Control Office (PCO)
As of Date: <date>
Prepared for:
• Project IT OCI’s
• Those interested in understanding the Application Retirement/
Decommissioning process
Prepared By:
David Niles; Program Manager: Systems Integration
Wednesday, October 28, 2015ECIO EXECUTIVE WORKBENCH Page: 1

VALUE PROPOSITION/PROBLEM STATEMENT/
TAKEAWAYS
• What is a successful plan of action (POA) to decommissioning an application?
• What are the various committee structures to be put in place for this type of
project?
• What type of documentation is typically delivered in support of a application
retirement?
• Can we illustrate how a large scale systems integration and applications retirement
efforts can work hand-in-hand?
• What requirements need to be addressed with an applications retirement
process?

OVERVIEW
1. Objectives and topics to be covered in this framework paper.
2. Introduction & Purpose
3. Overview & Approach
– Applications scheduled for applications retirement
4. Assumptions and Constraints
5. Tasks and Deliverables
• Appendices & Supporting Profiles
– Overviews of Artifacts & Deliverables
– Detail Timelines & Schedules
Intended Audience:
– Project Team
– OCI Committee membership
Contributors:

OVERVIEW OBJECTIVES
The objectives of this overview, cover two main focuses, to:
1. Understanding the background and efforts surrounding application
retirement
2. Illustrate the steps for retirement of the relevant applications for Project
Topics we will cover.
– What is the approach and methodology to accomplish applications retirement
for Project
– What are the expected deliverables?
– What roles are required?
– What is the timeline and schedule?

INTRODUCTION
• This overview outlines the approach we are planning to undertake for sun setting the
applications scheduled for decommissioning under a project.
• The systems decommissioning phase of the Systems Development Life Cycle (SDLC) is
initiated through the deployment of the SAP application “Tax & Revenue Management
(TRM) system (includes the PSCD component)”. This has resulted in a consolidation of
several vertical applications with varying degrees of automation and architectures that
are not longer required or supported.
• Systems decommissioning requires a strict adherence to mandates and regulations
related to contract terminations, disposition of assets, coordination's with various
OGD’s, records managements (including retention), transitions of fiscal management
duties and the placements of staff.
• To begin the process, a series of meetings will be scheduled to set the foundations of
the detail work activities for each of the applications. Irrespective of the final
decommissioning dates, the strategy and activities should remain the same, and getting
an early start on this should be beneficial. To assist others in subsequent efforts, we will
produce a System Decommissioning guidebook as an initial step.

• At the end of systems decommissioning, a phase review is conducted and lessons
learned for subsequent considerations of the other applications.
• The next pages present explanations and background on the various model’s,
processes and deliverables.
• Next, is a short descriptions from Wikipedia that explains the philosophy behind
applications sun setting.

SUN SETTING DEFINITION
• “Application retirement, also called application decommissioning and application
sun setting, is the practice of shutting down redundant or obsolete business
applications while retaining access to the historical data. Legacy applications are
often maintained solely to provide infrequent or sporadic access to the data within
the application database for regulatory or business purposes. With organizations
spending upwards of 75% of their application software budgets on ongoing
maintenance, application retirement can deliver significant cost savings.
• The act of application retirement usually involves relocating data from the legacy
application database to another data repository or archive store that can be
accessed independently using industry standard reporting or business intelligence
tools. Application retirement allows IT departments within companies to reduce the
software, hardware and resources required to manage legacy data.”
– Wikipedia (2013)

APPROACH & METHODOLOGY
• Our approach will follow a typical project life cycle dealing with applications
decommissioning and utilize standard projects artifacts in support of those
decommissioning efforts.
• For each release of the functionality delivered by Project we will have a “wave” of
applications scheduled for decommissioning. For each “wave”, we will undergo a set of
activities for each of the applications, but coordinated by each set of wave. For those
activities that cross applications suites e.g. contracts, infrastructure, we should be able
to maximize our efforts. Each effort should begin no later than 6 months prior to the
Project release. This will ensure we have enough time to make adjustments for staff,
contracts et al.
– Series of meeting for discovery per individual application
– This effort will be replicated by applications scheduled for decommissioning
– Execution
– Checklists
– Approach from the “Office of Systems Integration” as some other government
agencies have done.

APPLICATION RETIREMENT TOUCH POINTS:
CONTEXT DIAGRAM

EARLY REQUIREMENTS COLLECTION
• Some of the early requirements as suggested include:
– Decommissioning documentation must be easily assessable to all staff involved in
the activities.
– Standard format and content guides will be developed.
– Individual application level schedules and an overall schedule of activities will be
developed.
– Activities and documentation must cover:
• Internal Audit Requirements
• Application Component Retention Requirements
– Programs [On-line, batch, RJE]; Job Streams; Security Files [sub-X, system
controller]; Documentation [directories, program folders, production
instructions]; Training Material
– Determine Data Retention Requirements (DSS, Back-ups, Archives,
Production Files, Test Files)
– Identify locations of all data (production, training, quality assurance,
developer, end user)
– Identify Data Archiving Alternatives

COLLECTION (CONTINUED)
– Determine disposition of all legacy application data. (Should include data plans
from Enterprise Reporting.)
• Determine Final Production and Existing Report Retention (Paper, GcDocs,
Fiche)
– Plan for Final Production Runs Including:
• Interface Requirements
• Conversion Requirements
• Business Cycle Requirements
– Determine all system level software that can be retired as a result of the
decommissioning
– Application Access Requirements beyond Project Implementation dates
– Data Access Requirements beyond Project Implementation dates

APPLICATIONS SCHEDULED FOR DECOMMISSIONING
The following slides outline the applications scheduled for decommissioning. This is still
very much of a work-in-progress, and the final IT roadmap remains to be determined.
The business roadmap illustrates 4 components as follows:
– Component 1: Accounts Receivable Ledger (Project)
– Component 2: Client Identification
– Component 3: Assessment and Reassessment
– Component 4: Trade Modernization
Within each of these components, the tentative dates of each application set scheduled for
decommissioning, as of the date of this overview, are:
– Wave 1 - March YYYY
– Wave 2 – September YYYY
– Wave 4 – March YYYY

APPLICATIONS BY FUNCTION

1ST – 5TH WAVE SET OF APPLICATIONS
DECOMMISSIONED
1st Wave
The functionality expected to be delivered prior to these applications being
decommissioned include:
• Project PSCD Implemented which includes the functionality of:
– <functionality>
– By delivering this functionality, the applications that can be scheduled for
decommissioning are:
• <Systems/Applications>
• To be determined (not shown on the bz roadmap)
– <Systems/Applications>
– Additional application background information, interfaces under consideration and
points-of-contact are located in the appendices.
• 2nd Wave … (Concepts TB Duplicated from above)
• 3rd Wave …
• 4th Wave …
• 5th Wave …

HIGH LEVEL SCHEDULE

PROJECT BACKGROUND & LOGISTICS
The following slides outline some of the assumptions, caveats and scope implications
for this project. It also outlines, some aspects of progress reporting and tracking.

SCOPE, ASSUMPTIONS AND CONSTRAINTS
• Out of Scope of this decommissioning strategy
– This addresses only the sun setting of applications.. The ongoing process of
releases prior to sun setting, is covered under systems Integration plan of
action.
– Performance and capacity planning will be addressed in the operational
applications standards activity list.
– HR and staff plan of actions for transition is handled under systems
integrations or the projects/functional managers.
• The critical success/failure factors (CSF’s/ CFF’s) factor for this include:
– Communications, communications, communications
– …
• The KPI’s KGI’s are:
– <KPI’s>

ASSUMPTIONS:
• The following are some of the assumptions
– Individuals from client areas, EA, ITI, IA and Project will be available for decommissioning
activities.
– Decommissioning activities/tasks can only be identified and carried out by knowledgeable
existing employees.
– Decommissioning activities will continue beyond the Project implementation date for the
corresponding functionality.
– Decommissioning plans will be developed by Project release by application (or application
set). Decommissioning will also be coordinated across all applications by Project release.
– Decommissioning activities must be coordinated with Project implementation activities.
– Some applications may require partial or staged decommissioning.
– All data feeds in and out of the application have ceased.
– Business functionality has been replaced or eliminated.
– Data has been converted, archived in an application-neutral format, or destroyed.
– Data required for continuing analysis is available to users.
– Audit trails exist to ensure any data transformations can be identified so as to recreate the
original data values.

CONSTRAINTS:
• The implementation schedule (Applications decommissioning) will be managed in
the same fashion and principles as the general schedules.
• Hardware, software and data storage available to support access to historic data
• Resource availability

APPLICATION RETIREMENT PROJECT WEB SITE

COMMUNICATIONS REQUEST PROCESS

PLANNING MILESTONES
The planning milestones within each “retirement wave” are:
– PROJECT CHARTER
– PROJECT GOVERNANCE AND COMMUNICATION PLAN (PGCP)
– DEPARTMENTAL STAFFING PLAN (DSP)
– FISCAL TRANSITION PLAN FTP
– APPLICATION MAINTENANCE PRIORITIZATION PLAN AMPP
– PROJECT PROCESSES MANAGEMENT PLAN PPMP
– INTERFACE MANAGEMENT PLAN IMP
– APPLICATION COMPONENT DECOMMISSIONING PLAN ACDP
– ASSET MANAGEMENT PLAN AMP
– CONTRACTS MANAGEMENT PLAN CMP
– RECORDS MANAGEMENT PLAN RMP
– MAINFRAME DECOMMISSIONING PLAN MDP
– OPERATIONS SHUTDOWN PLAN OSP
– COMMUNICATIONS PROCESS PLAN CPP

HIGH LEVEL PROCESS DIAGRAM

KEY TASKS
• There are 5 key management stages associated with the sun setting of applications. They are:
– Initiation and Planning
– Execution
– Migration
– Monitor and Control
– Closure
• Within the management stages, the major discussions threads include:
– Application Decommission
– Asset Management
– Contract Management
– Interface Management
– Fiscal Transition
– Operations Shutdown
– Staffing, and,
– Records Management.
• These are outlined in detail later

SYSTEMS DECOMMISSIONING ARTIFACTS
The following will be produced to assist in the overall logistics of the decommissioning
efforts.
– SYSTEMS DECOMMISSIONING GUIDEBOOK
– SYSTEMS DECOMMISSIONING SCOPE AND GOVERNANCE PLAN OVERVIEW
– GOVERNANCE AND COMMUNICATIONS PLAN FOR SYSTEMS DECOMMISSIONING
– CUTOVER ACTIVITIES CHECKLIST REFERENCE GUIDE
– SYSTEM DECOMMISSION RECORDS MANAGEMENT OVERVIEW AND TRANSITION DOCUMENT
• In addition to the above project overview deliverables, the deliverable's for each
phase of the decommissioning efforts are illustrated on the following slides.

INITIATION & PLANNING DELIVERABLES
The deliverables for the “Initiation and Planning” activity include the following:
– PROJECT CHARTER
– INTRODUCTION TO SYSTEMS DECOMMISSIONING WORK PLAN
– SYSTEMS DECOMMISSION WORK PLAN SHELL
– INTRODUCTORY LETTER TO USER GROUPS
– GOVERNANCE AND COMMUNICATIONS PLAN
– PLANNING SESSION GROUND RULES
– SCOPE AND GOVERNANCE PLAN OVERVIEW
– WORKGROUP SCOPE AND PLAN OVERVIEW
– SYSTEMS DECOMMISSIONING PLANNING GUIDE.
The templates for each are located on the Systems Integrations retirement web site.

EXECUTION DELIVERABLES
• The following are the deliverables from the “execution” phase.
– FUNCTIONAL; AREAS RESOURCE SUPPORT THROUGH SYSTEMS DECOMMISSIONING
– ‘NO LONGER SYSTEMS OF RECORD (SOR)” NOTICE TO CONSTIUITIENTS
– “NO LONGER SOR” NOTICE TO INTERFACE PARTNERS
– 60 DAY DEACTIVATIONS NOTICE TO INTERFACE PARTNERS
– ACQUISITIONS DOCUMENTS ACKNOWLEDGEMENT LETTER
– BUDGET DOCUMENTS ACKNOWLEDGEMENT LETTER
– CONSULTING SERVICES CONTRACT TERMINATIONS LETTER
– MAINTENANCE CONTRACTS TERMINATIONS LETTER
– CONTRACT MANAGEMENT MATRIX

MIGRATION DELIVERABLES
• The following lists the the deliverables from the Migration phase:

MONITOR & CONTROL DELIVERABLES
• The following are the deliverables from the Monitor and Control activity:
– SYSTEMS DECOMMISSIONING – PERIODIC INTERNAL STATUS REPORT

CLOSURE DELIVERABLES
• The following are the deliverables from the “closing” activity:
– RECORDS MANAGEMENT EVALUATIONS AND RECOMMENDATIONS (RMER)
– RECORDS MANAGEMENT OVERVIEW AND TRANSITIONS
– SYSTEMS DECOMMISSIONING CLOSE-OUT REPORT
– OPERATIONS SHUTDOWN PLAN.

ROLES & RESPONSIBILITIES
• The following outlines, the concepts behind each of the roles and responsibilities
surrounding applications retirement. In some cases, individuals can wear several
hats in the fulfillment of the functions.

WORKING GROUPS TO BE ESTABLISHED
Working Groups that are recommended to be created to support each “wave” include:
– Business Administration
– Migration (if applicable)
– Applications Services
– Technical Services
– Communications
– Contract/Fiscal management
– Asset Management
– Records Management
• The following chart explains the structure

WORK GROUP DETAILS

SYSTEMS DECOMMISSIONING ORGANIZATIONAL
CHART (E.G.)

SYSTEMS DECOMMISSIONING PLANNING GUIDE: TABLE OF
CONTENTS

RISK AND ISSUES
• The risk and issues will follow the overall approach as outlined by the Project PCO,
and specifically the Risk Manager. For more information, please refer to that
process (separate Presentation).
• Some of the typical risks and issues associated with initiates of this type include:
– Legislative compliance, labour laws, contacts cancellations
– Availability of staff currently assigned to legacy financial and human resource
applications for training and new assignments
– How to handle security in the interim
– Support for systems during the interim

NEXT STEPS & ACTIVITIES
The next steps following general acceptance of this Plan of Action include:
– Continue to update “migrations strategy”
• identify interfaces (Current & Future state)
• Diagram “waves” and roll-out strategy
• Establish CI Dictionary
• …
– Validate approach with all constituents
– Development of the Systems Integrations Guidebook
– Setup templates of all activity deliverables.
– Produce, confirm and approval of the Project Charter
– Begin preliminary schedule of meetings with the constituents of Wave 1

TIE-IN TO SYSTEMS INTEGRATION
• Stewart & governance
• Functions
• Requirements
• For more information, please review the presentations on SI.

<SYSTEM/APPLICATION> INTERFACES &
RELATED APPLICATIONS

DELIVERABLES & ARTIFACTS
DETAIL SCHEDULES

Application Component Decommissioning Plan (ACDP)
• Identify application components that need to be decommissioned such as: production, testing and
training Regions, business applications, application and system user ID’s, file transmissions, ad-hoc
processes, and batch processes. The workgroup will identify decommissioning timeline, the
validation criteria and which workgroup or individual is responsible for the activity.
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).
Application Maintenance Prioritization Plan (AMPP)
• The AMPP will assist the Project in determining which requests for changes to the application will
be accepted and which will be rejected during project closure. The plan will include all work efforts
(major work orders, minor changes, and small production fixes). The plan will govern all
applications. The plan will include additional activities such as software upgrades, existing support
end dates, communication outputs and exception criteria.

Contract Management Plan (CMP)
• Identify all written agreements with any non- entity for products and/or services (e.g.
Unisys, Oracle, and UPS). Activities include: identification 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.
Communications Process Plan (CPP)
• Communications development and dissemination 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.
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 staff (encumbrance, validation, payment and interface).

Interface Management Plan (IMP)
• The Interface Management Plan will include all interfaces, test regions and
decommissioning timeline. Activities will include data retention requirements and
internal/external stakeholder communication activities.
Mainframe Decommissioning Plan (MDP)
• The Mainframe Decommissioning Plan identifies tasks and responsibilities associated
with the formal shutdown and decommission of the federal-owned mainframe(s) and
peripherals currently operating at the corporate Data Center.
Operations Shutdown Plan (OSP)
• The Operations Shutdown Plan identifies the tasks and responsibilities associated with
the formal shutdown and decommission of the server infrastructure at corporate
facilities and Project Management Office (PMO) computing and network environment.
These services include production control operations, servers, network connections and
technical processes.

Project Processes Management Plan (PPMP)
• Activities will include the evaluation of current processes outlined in the application maintenance,
deliverables management, quality management, and other project policy and procedures to
identify changes or tailoring that will be required due to system decommission.
Records Management Plan (RMP)
• Identify and disposition all business data and information stored in all forms 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 rights must be reviewed and the proper disposition
determined.
Departmental Staffing Plan (DSP)
• A collaborative effort coordinated with corporate Human Resources of an approved administrative
plan to address the “roll off” of Departmental employees due to system decommission. Activities
will focus on the identification of Office of Systems Integration (OSI)/Departmental Personnel Board
(DPB) HR policies and procedures which guide and facilitate the transition of departmental
employees and the development of the appropriate communications.

DECOMMISSIONING CHECKLIST (EXAMPLE)

MILESTONES CHART

SCHEDULE

PRESENTERS BACKGROUND
• David Niles (djn_bus@msn.com)
– Director, Systems Development
• USA Federal Government Health Care, Washington DC
– Director Enterprise Infrastructure
• Sanmina-SCI Contract Manufacturing, San Jose CA, Huntsville AL
• Largest Oracle ERP instance in the world… HSV Z series, Superdomes
– Director, Project Control And Service Management
• Sanmina-SCI, Chennai India Guadalajara MX
• Mergers and Acquisitions, DRP, SOX, GSC, PMO
– Sr. Director Support Services
• Burlington Coat Factory, Philadelphia PA
• Change Control, GSC, Asset Management, Field Services, Technical Services,
PMO
– Program Director, Day 2 Wipro
– Special advisor, CIO/COO Macmillan Publishing NYC
Page: 48Wednesday, October 28, 2015ECIO EXECUTIVE WORKBENCH

APPENDICES & SUPPORTING INFORMATION

SUPPORTING INFORMATION & CONTRIBUTORS
• IBM Literature
• …

TO DO’S FOR FUTURE ADDITIONS
• To do/Action Items
– Include RACI chart for overview
– Move web site to confluence

PROJECT & <SYSTEM/APPLICATION> TOUCH POINTS

INTERFACES UNDER CONSIDERATION INCLUDE:
• The interfaces to be reviewed for inclusion in the new system are:
– <interface touch points>
• The principle contacts and representative ownership is:
– IT
– Bz identified

TOOLKITS USED IN THE ASSISTANCE FOR COLLECTION OF
INFORMATION
• Mindmap
• eCIO Executive Workbench
– Toolkit and examples for all facets of the
workplace for managers, executives and
the individuals contributor
– Leave your card and I’ll get you a copy

Icons used in this presentation;
As you review this presentations, you will see icons that are designed to call your attention to specific pieces
of information. Here they are with descriptions:
When you see this icon, you know you’re about to get helpful tips and practical advice to
help
The text next to this icon typically contains important information that helps you stay on
track
I use this icon as a red flag. It draws your attention to items that could sidetrack your
progress.
This icon highlights technical material, which you can use for further investigation
END OF PRESENTATION
…

eCIO PPT Sunsetting strategy v 3 general distribution

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (12)

Similar to eCIO PPT Sunsetting strategy v 3 general distribution

Similar to eCIO PPT Sunsetting strategy v 3 general distribution (20)

More from David Niles

More from David Niles (7)

eCIO PPT Sunsetting strategy v 3 general distribution

Editor's Notes