Executive Sponsor – Sean Pearson, CIO · Web view2020/07/23 · To address this issue, NM CSES...

NEW MEXICO CHILD SUPPORT ENFORCEMENT SERVICES REPLACEMENT

PROJECT MANAGEMENT PLAN

EXECUTIVE SPONSOR – SEAN PEARSON, CIOBUSINESS OWNER – JEREMY TOULOUSE

CSES PROJECT MANAGER – RUSS ILLICH, PAUL GOSNELL

DELOITTE PROJECT MANAGER – YIHONG ZENG

ORIGINAL PLAN DATE: APRIL 24, 2020REVISION DATE: 06/12/2020

REVISION: VERSION 3.1

PROJECT MANAGEMENT PLAN FOR CSES REFACTORING (TRANSFORMATION) PROJECT

REVISION HISTORY............................................................................................................................................ IV

1.0 PROJECT OVERVIEW................................................................................................................................... 1

1.1 EXECUTIVE SUMMARY -RATIONALE FOR THE PROJECT...................................................................................................11.2 FUNDING AND SOURCES..........................................................................................................................................2

APPROPRIATION HISTORY (INCLUDE ALL FUNDING SOURCES, E.G. FEDERAL, STATE, COUNTY, MUNICIPAL LAWS OR GRANTS)....................................................................................................................................................... 2

1.3 CONSTRAINTS........................................................................................................................................................21.4 DEPENDENCIES......................................................................................................................................................21.5 ASSUMPTIONS.......................................................................................................................................................31.6 INITIAL PROJECT RISKS IDENTIFIED...........................................................................................................................4

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE.............................................................................5

2.2 PROJECT GOVERNANCE STRUCTURE...........................................................................................................................62.2.1 Describe the Role and Members of the Project Steering Committee.........................................................62.2.2 Organizational Boundaries, Interfaces and Responsibilities......................................................................9

2.3 EXECUTIVE REPORTING..........................................................................................................................................11

3.0 SCOPE......................................................................................................................................................... 12

3.1 PROJECT OBJECTIVES............................................................................................................................................123.1.1 Business Objectives.................................................................................................................................123.1.2 Technical Objectives................................................................................................................................12

3.2 PROJECT EXCLUSIONS............................................................................................................................................123.3 CRITICAL SUCCESS FACTORS...................................................................................................................................12

4.0 PROJECT DELIVERABLES AND METHODOLOGY.............................................................................................13

4.1 PROJECT MANAGEMENT LIFE CYCLE........................................................................................................................134.1.1 Project Management Deliverables..........................................................................................................154.1.2 Deliverable Approval Authority Designations..........................................................................................164.1.3 Deliverable Acceptance Procedure..........................................................................................................16

4.2 PRODUCT LIFECYCLE.............................................................................................................................................174.2.1 Technical Strategy...................................................................................................................................194.2.2 Product and Product Development Deliverables.....................................................................................194.2.3 Deliverable Approval Authority Designations..........................................................................................264.2.4 Deliverable Acceptance Procedure..........................................................................................................26

5.0 PROJECT WORK........................................................................................................................................... 26

5.1 WORK BREAKDOWN STRUCTURE (WBS)..................................................................................................................265.2 SCHEDULE ALLOCATION - PROJECT TIMELINE.............................................................................................................295.3 PROJECT BUDGET.................................................................................................................................................30

FY19 & Prior.....................................................................................................................................................305.4 PROJECT TEAM....................................................................................................................................................31

5.4.1 Project Team Organizational Structure...................................................................................................315.4.2 Project Team Roles and Responsibilities..................................................................................................31

5.5 STAFF PLANNING AND RESOURCE ACQUISITION.........................................................................................................355.5.1 Project Staff.............................................................................................................................................365.5.2 Non-Personnel Resources........................................................................................................................36

5.6 PROJECT LOGISTICS...............................................................................................................................................385.6.1 Project Team Training.............................................................................................................................38

6.0 PROJECT MANAGEMENT AND CONTROLS....................................................................................................38

REVISION: 3.1 DOIT-PMO-TEM-020 ii OF vi


6.1 RISK AND ISSUE MANAGEMENT..............................................................................................................................386.1.1 Risk Management Strategy.....................................................................................................................386.1.2 Project Risk Identification........................................................................................................................396.1.3 Project Risk Mitigation Approach............................................................................................................406.1.4 Risk Reporting and Escalation Strategy...................................................................................................426.1.5 Project Risk Tracking Approach...............................................................................................................446.1.6 Issue Management..................................................................................................................................46

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V...............................................................................................506.3 SCOPE MANAGEMENT PLAN..................................................................................................................................51

6.3.1 Change Control........................................................................................................................................516.4 PROJECT BUDGET MANAGEMENT............................................................................................................................57

6.4.1 Budget Tracking......................................................................................................................................576.5 COMMUNICATION PLAN........................................................................................................................................57

6.5.1 Communication Matrix............................................................................................................................576.5.2 Status Meetings.......................................................................................................................................606.5.3 Project Status Reports.............................................................................................................................60

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)..................................................................................................616.6.1 Baselines.................................................................................................................................................616.6.2 Metrics Library........................................................................................................................................62

6.7 QUALITY OBJECTIVES AND CONTROLS......................................................................................................................626.7.1 Quality Standards....................................................................................................................................626.7.2 Project and Product Review and Assessments.........................................................................................626.7.3 Agency/Customer Satisfaction................................................................................................................626.7.4 Product Deliverable Acceptance Process.................................................................................................63

6.8 CONFIGURATION MANAGEMENT.............................................................................................................................646.8.1 Version Control........................................................................................................................................646.8.2 Project Repository (Project Library).........................................................................................................64

6.9 PROCUREMENT MANAGEMENT PLAN.......................................................................................................................64

7. 0 PROJECT CLOSE........................................................................................................................................... 64

7.1 ADMINISTRATIVE CLOSE........................................................................................................................................647.2 CONTRACT CLOSE.................................................................................................................................................65

ATTACHMENTS................................................................................................................................................. 66

A. Refactoring Project Methodology................................................................................................................66B. Project Work Plan Approach........................................................................................................................67C. Project Deliverable Management Plan.........................................................................................................69D. Action Item Management............................................................................................................................73E. Project Decisions..........................................................................................................................................75F. Project Document Management Plan...........................................................................................................78G. Project Tools Plan........................................................................................................................................81H. Deliverable Cross-Walk to SOW...................................................................................................................82I. Deliverable QA Checklist................................................................................................................................83J. Glossary........................................................................................................................................................86

REVISION: 3.1 DOIT-PMO-TEM-020 iii OF vi


REVISION HISTORY

REVISION NUMBER DATE COMMENT

0.1 March 19, 2020 Initial Draft

0.2 March 20, 2020 Second Draft

1.0 March 20, 2020 Initial Submission

1.1 April 8, 2020 Revised Submission

1.2 April 20, 2020 Month 2 Initial Draft

2.0 April 24, 2020 Month 2 Initial Submission

2.1 May 21, 2020 Month 3 Initial Draft

3.0 May 21, 2020 Month 3 Initial Submission

3.1 June 12, 2020 Month 3 Revised Submission

REVISION: 3.1 DOIT-PMO-TEM-020 iv OF vi


1.0 PROJECT OVERVIEW

The purpose of this project is to assist The State of New Mexico’s Human Services Department in migrating the Child Support Enforcement System (CSES) system to a modern platform; to convert the existing mainframe CA Gen/COBOL/Rexx/Assembler code to a java-based/Oracle database solution; and to deliver a migrated system that is functionally equivalent to the current production version of CSES. This document will cover the following key aspects to ensure a migration of the CSES system:

Overview- To include, but not limited to, the scope and purpose of the document, an introduction of sections and key assumptions.

Communication Management – Describe how project communications are planned, structured, monitored, and controlled

Scope Management - Includes processes and procedures to ensure that all scope updates are escalated appropriately and addressed in a timely manner.

Risk Management - processes and procedures to ensure that important risks are monitored, have a corresponding mitigation strategy, are monitored for escalation to an issue and resolved in a timely manner.

Issue Management – Discusses escalation processes and procedures of issues to ensure that important issues are escalated appropriately and resolved in a timely manner.

Quality Management - Quality policies and procedures for project deliverables and project processes and to ensure continuous improvement

Change Management - Define processes and procedures to manage and control changes.

1.1 EXECUTIVE SUMMARY -RATIONALE FOR THE PROJECT

The Human Services Department mission is: To transform lives by working with partners. HSD designs and delivers innovative, high quality health and human services that improve the security and promote independence for New Mexicans in their communities.

More specifically, the purpose of the Child Support Enforcement Division is to establish and enforce the support obligations owed by parents for their children, thereby reducing the number of families reliant on public assistance.

The New Mexico Child Support office uses the CSES application to assist with collecting the child support on behalf of New Mexico’s children. CSES allows the state to conduct automated matches with numerous data sources, and it automatically generates income withholding notices, driver’s license suspensions notices, and numerous other notices to custodial parents, non-custodial parents and employers without requiring caseworker intervention.

PAGE | 1


Due to its age, in recent years, the CSES system has become more difficult to maintain. To address this issue, NM CSES has enlisted Deloitte’s Application Modernization studio to convert CSES to a more maintainable, modern platform using their proven migration approach. The migration approach uses a Refactoring Methodology to migrate the existing CSES system from the current set of technologies (DB2 and COBOL/CA GEN) to the unified target technologies (Oracle DB and Java). The new system will fully replace the CSES functionality with a one-to-one migration strategy.

1.2 FUNDING AND SOURCES

APPROPRIATION HISTORY (INCLUDE ALL FUNDING SOURCES, E.G. FEDERAL, STATE, COUNTY, MUNICIPAL LAWS OR GRANTS)

Fiscal Year Amount Funding Source

SFY15-SFY16 $ 527,300 Laws of 2014, Chapter 63, Section 7, Item 17

SFY15-SFY16 $1,023,700 Federal Appropriation Approved June 1, 2014

SFY16-SFY21 $3,400,000 Laws of 2015, Chapter 101, Section 7, Item 19 (Federal Incentive)

SFY20-SFY21 $5,245,800 $1,783,600 – NM Laws of 2019, Chapter 271, Section 7, Item 21$3,462,200 – Federal Financial Participation

SFY21-SFY22 $8,330,900 $2,009,256– NM Laws of 2020, Chapter 271, Section 7, Item 22$7,255,056– Federal Financial Participation

1.3 CONSTRAINTSThe following constraints are factors that restrict the project schedule and scope.

NUMBER DESCRIPTION

1. The project schedule is dependent on timely review of deliverables by NM CSES.

2. Project testing is dependent on the timely procurement of necessary project hardware and set up of environments.

1.4 DEPENDENCIES The section below briefly discusses how the CSES Project plans to manage dependencies across the project. As a part of the CSES project, Deloitte was required to submit a Deliverable Dependency Plan at the end of Month 1 which identifies and sets a plan for dependencies across teams. For a detailed account of all project dependencies, please reference the NM CSES Refactoring Project Deliverable Dependency Plan.

The Deliverable Dependency Plan deliverable is intended to identify and plan for dependencies across teams to provide smooth execution and delivery. Deloitte deliverables may be dependent on deliverables produced by the New Mexico Child Support Enforcement Services (NM CSE) PAGE | 2


and NM CSE’s third parties, each of which will need to provide accurate inputs to Deloitte in a timely manner. If the dependent tasks and/or deliverables are late, the project timeline will be impacted. The Deliverable Dependency Plan Deliverable contains descriptions of each dependency, its project impact and the dependency owner.

A Deliverable Expectation Document (DED) is a template for a deliverable that also contains CSES Refactoring (Transformation) Project defined review and/or acceptance criteria for the deliverable. Each DED will define deliverable contents and organization and be published in Microsoft PowerPoint. Most deliverables will utilize a DED.

The Deloitte project team assigned to the deliverable creates the draft deliverable using the appropriate template. This deliverable development step is not expected to start until the template (and any applicable review criteria) has been signed-off, and the reviewers for the deliverable review(s) have been defined. Hence, timely approval of the DED is key to maintaining deliverable production and project schedule.

CSES project team participation in the “Draft Deliverable” step is important. The CSES project team will participate actively in the development of deliverables.

NUMBER DESCRIPTION

1. For a detailed account of all project dependencies, please reference the NM CSES Refactoring Project Deliverable Dependency Plan.

1.5 ASSUMPTIONS A list of assumptions for the project are detailed below:

NUMBER DESCRIPTION

1. The NM CSES team will provide guidance and input in the drafting of project deliverables.

2. NM CSES is responsible for all procurement activities.

3. NM CSES will provide necessary assets along with secure onsite and remote access to the development and testing environments in a timely manner as to not affect the implementation schedule.

4. The parties will agree on applicable Deliverable acceptance criteria at the start of the Project which will be documented in the Project Plan. Initial deliverable acceptance criteria is documented in the contract with stipulation that it will be further defined in the Deliverable Expectation Document of the deliverable.

5. NM CSES’ resources with accurate knowledge of the legacy system will be available to participate in the appropriate activities as identified in the work plan.

PAGE | 3


NUMBER DESCRIPTION

6. NM CSES’ resources, including full time and part time, allocated to this project will be identified at the commencement of the project in order to facilitate continuity.

7. NM CSES will be responsible for the performance of its third-party contractors or vendors it utilizes with respect to NM CSES’ obligations under this project.

8. Deloitte will not be responsible for the performance or management of any third-party vendors associated with the project which are not employed by Deloitte.

1.6 INITIAL PROJECT RISKS IDENTIFIEDPlease reference the CSES Refactoring (Transformation) Project Issues and Risk Log for more information about initial project risks and mitigation strategies to minimize the probability and impact of these risks.

Resource Considerations

There are many parallel project efforts ongoing at CSES utilizing the same project resources on the HSD side.

Probability – n/a Impact – 50%

Mitigation StrategyResource bandwidth and support will need to be monitored and adjusted accordingly. Contingency Plan HSD to add an additional project manager who can gear their focus on the CSES Refactoring project. HSD has added Paul Gosnell to the Project Management team to assist Russ Illich with all PMO related tasks.

Architecture Lead

NM CSES architecture lead resource has not been identified. (Closed)


Mitigation Strategy. HSD will split the responsibility of an architect across multiple leaders (Lisa Jaramillo, Patrick Durkin and Sean Curry). Deloitte will conduct weekly architecture calls to keep all parties involved and informed.Contingency Plan N/A

Interim Hardware

Lack of Virtual Machine remote access and initial environments (DevOps Server, Dev Env, etc.) will impact the overall project timeline.

(Closed)


Mitigation StrategyHSD has provided the all VMs to Deloitte as of 05/26/2020. NMHSD is looking at provisioning Dev/DevOps Servers on AWS. No Interim solution will be required as a full solution will be provided on the cloud via AWS.Contingency Plan N/A

PAGE | 4


2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE

2.1 Please insert the Org Chart

PAGE | 5


NAME STAKE IN PROJECT ORGANIZATION TITLE

Kari Armijo Champions the project New Mexico Human Services Department

HSD Deputy Secretary

Sean Pearson Champions the project New Mexico Human Services Department

CIO

Jeremy Toulouse Champions the project New Mexico Child Support Enforcement Division

Director

Russ Illich Primary liaison with platform refactoring contractor

New Mexico Information Technology Division

Project Manager

RESPEC Staff Independent project review RESPEC IV&V

Deloitte Staff Implement Deloitte Project Team

Child Support Enforcement Division Staff

Users of the system New Mexico Child Support Enforcement Division

Various staff

2.2 PROJECT GOVERNANCE STRUCTUREDifferent levels of meetings and associated reporting will be incorporated to help set up regular and transparent communication between the Deloitte and NM HSD project teams. The communication matrix represented below describes the formal internal and external documents that will be produced by the Deloitte team for communication purposes. The matrix identifies the intended audience and the staff responsible for originating the item, as well as the frequency, format and method of delivery.

Standard formats (provided in the Appendices – section 10) will be applied to documents to provide a consistent look and feel.

2.2.1 DESCRIBE THE ROLE AND MEMBERS OF THE PROJECT STEERING COMMITTEE

PAGE | 6


TITLE, NAME, ESC ROLE RESPONSIBILITIES

HSD Director Sean Pearson CIOExecutive Steering Committee Voting Member

Champions the Project

Communicates with respective Division staff regarding progress and escalations

Reviews and accepts initial risk assessment, project management plan, project schedule and budget

Casts the deciding vote where a consensus cannot be reached by the Executive Steering Committee

HSD Deputy DirectorAnthony WebbVoting Member





HSD Deputy SecretaryKari ArmijoVoting Member





CSES Project ManagerRuss IllichNon-Voting Guest

Primary liaison with Platform Refactoring Contractor

Assigns project resources

Manages vendor contract deliverables

Manages budget and costs

Communicates with ESC regarding progress and escalations

CSES Project ManagerPaul GosnellNon-Voting Guest

Supports the ESC by preparing meeting agendas, reports, documentation and minutes

Assigns project resources

PAGE | 7



HSD IT Business Bureau ChiefJeff CreecyNon-Voting Guest

Approves and guides the technology solution

Primary liaison with CSES Project Manager

Balances larger picture versus details of project

Manages vendor contract deliverables as needed


Child Support Director Jeremy ToulouseVoting Member




Casts the deciding vote where a consensus cannot be reached by the ESC

CSED Deputy DirectorBetina McCrackenVoting Member





HSD Deputy CIOJames LillyNon-Voting Guest






HSD Deputy CIOSean CurryNon-Voting Guest






PAGE | 8



Independent Validation and Verification (IV&V) ContractorJoel Matek and Glenn Young, RESPECNon-Voting Guest

Independent project review

Report on project health to the Department of Information Technology (DoIT)

Participates in ESC meetings and reviews ESC artifacts

Principal, Project Advisor

Mike Phelan, Deloitte

Non-Voting Guest

Serves as a liaison between Deloitte and NM CSES

Provides direction to the Deloitte project team

Principal, Lead Engagement Partner

Rachel Frey

Non-Voting Guest

Executive liaison between Deloitte and NM CSES

Provides direction to the Deloitte project team

Empowers the Project Manager

Senior Manager, Project Manager

Yihong Zeng

Non-Voting Guest

Primary liaison between Deloitte and NM CSES

Communicates with CSES PM about project progress and escalations

Manages project deliverables

2.2.2 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES

ROLE RESPONSIBILITY

CSES CIO Directs the project and reports to CSES Executives. Manages IT environment, budget and human resources.

CSES Project Manager

Plans and manages the project. Develops contracts and manages contractors. Facilitates procurement. Track and report on cost, schedule, and scope progress; manage change; escalate issues for resolution; manage risk; manage contractors. Report to the Executive Steering Committee on project progress, risks, issues and matters requiring Executive Steering Committee action. Prepare presentations and documentation required for the certified project.

CSES Business Lead Plan and coordinate activities with business Subject Matter Experts (SMEs).

PAGE | 9


ROLE RESPONSIBILITY

CSES Test Manager Identify, document and validate user acceptance test cases; schedule control.

CSES Technical Lead

Assign resources for discovery sessions, unit testing, data migration activities, technical activities, system integration testing and user acceptance testing; identify and prioritize future system enhancements; escalate concerns.

CSES Technical Team

Support effort in technical discovery, analysis, migration and database activities. Support with unit, system integration and user acceptance testing; identify and prioritize future system enhancements; escalate concerns. Support effort in defining business rules and identifying technical specs.

CSES Business LeadAssign resources for unit, system integration and user acceptance testing; identify and prioritize future system enhancements; escalate concerns.

CSES Testing Team

Support effort to capture and define business rules. Review draft test plan and test cases. Validate data during refactoring, conversion and migration. Support effort to assess and inventory mainframe data assets, and to catalog system inputs and outputs, including data exchanged with external systems. Support effort to identify and prioritize future system enhancements.

Deloitte Project Manager

Collaborate with CSES PM as required on PM artifacts, including:

Project Management Plan, including project management approach, communication plan, program functional overview, escalation paths, and change management process

Issues Log Risk Register Work Plan

Produce status report. Collaborate with the Procuring Agency as required on technical artifacts. Provide quality assurance and technical coordination on all deliverables submitted. Obtain approval or iterate to secure approval on all work product.

Deloitte Technical Team

Perform code migration and platform conversion work; system test; provide recommended architecture for future phases; train CSES Technical team on maintenance of converted code, tool use, and operationalization.

PAGE | 10


ROLE RESPONSIBILITY

IV&V Contractor

Evaluate project management plans, processes, and procedures. Monitor project activities and the project schedule to assess the progress of the project. Identify key areas that pose potential risk to the project and recommending mitigation strategies to reduce those risks. Evaluate and verify all system development and data management configuration and processes. Verify quality assurance approach and progress. Evaluate training and knowledge transfer activities from Platform Modernization Contractor to CSES technical and business staff

2.3 EXECUTIVE REPORTINGBoth the CSES and Deloitte Project Manager will maintain timely project communications. Report NM CSES and meetings will include the following:

Weekly project status report

Steering Committee meetings monthly or as directed

Change Control Board meetings as needed (cadence to be defined by executive steering committee)

Technical Review Board meetings semi-monthly (cadence to be defined by executive steering committee)

Immediate notification of critical issues impeding project progress (see the escalation process below for more details)

Figure 2.3: Communication Pyramid for the CSES Refactoring Project

PAGE | 11


3.0 SCOPE

3.1 PROJECT OBJECTIVES3.1.1 BUSINESS OBJECTIVES

NUMBER DESCRIPTION

Bus. Objective 1 Convert the mainframe CSES system to a more maintainable, modern platform capable of supporting integration with modern interfaces and technologies.

3.1.2 TECHNICAL OBJECTIVES

NUMBER DESCRIPTION

Tech. Objective 1 Migrate legacy CSES to an N-tier, client-server architecture with full functional equivalency.

Tech. Objective 2 Migrate the existing CSES system from the current set of technologies (DB2 and COBOL/CA Gen) to the unified target technologies (Oracle DB and Java).

3.2 PROJECT EXCLUSIONSAnything not specifically listed in the deliverables section as being within the scope of implementation services is out of the scope. Out of scope items for this project include but are not limited to:

Enhancements: improvements or changes required for existing systems owned by the Procuring Agency.

Non-Automated Refactored Modules: all Modules that cannot be refactored using automation.

3.3 CRITICAL SUCCESS FACTORS

NUMBER DESCRIPTION

QUALITY METRIC 1

No delay in disbursements or collections.

*The future state system will be functionally equivalent to the mainframe system. The amount and rate of collections, disbursements and all other financial transactions produced by the future system will match that of the current system. A baseline comparison will be established for accurate comparison.

QUALITY METRIC 2Tune the performance of the batch within the existing batch window (batch window to be confirmed) and online assets to perform at the industry standard level (to the extent applicable) for N-tier architecture.

PAGE | 12


In addition to these quantifiable metrics, we have defined the following Critical Success Factors for the CSES Refactoring Project:

Regular communication cadence and clear communication channel.

Early and full engagement of CSES SMEs on test case development and test script recording.

Adopt One Team approach where NM CSES and Deloitte team members work side by side and communicate freely.

Clearly defined test entry and exit criteria.

Clearly defined and agreed upon bug severity level.

Clearly defined change management process.

Full configuration management to promote environment consistencies.

Consistent Gold Copy used to compare test results on both mainframe and the new system.

One time set up of needed environments per sizing requirements.

NM CSES to take ownership of the environment early on to gain hands on experience and to facilitate and to facilitate smoother transition.

4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE

PHASE SUMMARY OF PHASE KEY DELIVERABLES

Initiation Coordinate project logistics, meetings, communication, work spaces and accesses, and work product to support project planning.

Confirm resources, roles, and responsibilities with CSES.

Conduct kick off sessions for project planning, architecture, technical, and testing work streams.

Conduct discovery sessions with CSES to assess current state.

1.1_A Project Ramp Up and Discovery Documentation

Planning Create and maintain a Deliverable Dependency Plan to plan for dependencies across

1.1_C Deliverable Dependency Plan

1.1_D Work Plan

PAGE | 13



teams to provide smooth execution and delivery.

Create and maintain a Work Plan to track project tasks, deliverables, and milestones.

Create and maintain a Project Management Plan, providing details about project management approach, communication plan, program functional overview, risk and issue management, escalation paths, and change management processes.

1.1_E Project Management Plan

Controlling Provide weekly status report to entire project team.

Track risks and issues and escalate items as needed.

1.1_B Weekly Project Status Report

Execution Continue to maintain project management deliverables.

Provide weekly status report and escalate issues as needed.

Support project teams in completing deliverables as needed.

N/A

Close Coordinate with CSES to complete standard project close out activities.

Provide CSES with documentation of all Scope of Work (SOW) deliverables and request sign-off.

Conduct a lesson learned session.

Notice of Acceptance of CSES Deliverables (For retainages)

4.1.1 PROJECT MANAGEMENT DELIVERABLES

Project Deliverables are work products or artifacts that are driven by the project management methodology requirements and standard project management practices regardless of the product requirements of the project. The following deliverables and descriptions are taken directly from the contract.

PAGE | 14


4.1.1.1 DEL 1.1_A Project Ramp Up and Discovery DocumentationDescription – As part of the project ramp up, the Deloitte project team will coordinate project logistics for project meetings, communication, work spaces and accesses, and work product to support project planning and confirm resources, roles, and responsibilities with CSES. The Deloitte project team will conduct kick off sessions for project planning, architecture, technical, and testing work streams and facilitate required discovery sessions to assess CSES ’s current state. The Deloitte team will also submit a deliverable dependency plan to CSES for review and acceptance.

Deliverable Acceptance Criteria – Must meet acceptance of designated CSES reviewersStandards for Content and Format – Signed Deliverable Expectation Document(DED) and Quality Assurance (QA) ChecklistQuality Review – Will be reviewed and approved by designated CSES reviewers

4.1.1.2 DEL 1.1_B Weekly Project Status ReportDescription – The Deloitte project team will provide weekly status report to CSES. This report will include: Overall Status, milestones and accomplishments, issues, risks log, and current and upcoming activities.

Deliverable Acceptance Criteria - Must meet acceptance of designated CSES reviewers

Standards for Content and Format - Signed DED and QA ChecklistQuality Review - Will be reviewed and approved by designated CSES reviewers

4.1.1.3 DEL 1.1_C Deliverable Dependency PlanThe Deliverable Dependency Plan deliverable is intended to identify and plan for dependencies across teams to provide smooth execution


Standards for Content and Format - Signed DED and QA Checklist

PAGE | 15


and delivery. Deloitte deliverables may be dependent on deliverables produced by the New Mexico Child Support Enforcement System (NM CSES) and NM CSES ’s third parties, each of which will need to provide accurate inputs to Deloitte in a timely manner. Deliverable dependencies need to be established to confirm project critical activities can be completed on time and lower the risk of not meeting project milestones.

Quality Review - Will be reviewed and approved by designated CSES reviewers

4.1.1.3 DEL 1.1_D Work PlanDescription – The Deloitte project team will present to CSES a Work Plan for the Deliverables in the SOW. This Work Plan will include: project activities and tasks, project schedule, timelines, and dependencies, major milestones, and deliverables.



4.1.1.4 DEL 1.1_E Project Management PlanDescription – The Deloitte project team will create a document providing details about the project management approach, communication plan, program functional overview, risk and issue management, escalation paths, and change management process.



4.1.2 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS

The CSES Project Manager will review the completed deliverable and the documentation supporting the review activities for acceptance.

4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE

Deliverable acceptance will be governed in accordance with Article 4 of the Contract. During the sign-off process, the reviewer may provide additional feedback which will be documented and addressed. The reviewer will sign-off or provide feedback on the deliverable within the time documented in the table in section below. Upon completion, the reviewer will document deliverable sign-off by completing the Deliverable Sign-off Form located on the project SharePoint site and send to the Deloitte Project Management Office (PMO) via e-mail.

PAGE | 16


Once a deliverable is signed off, the Deloitte PMO will archive the approved deliverable (along with the completed Deliverable Sign-off Form) in the appropriate repository, and any additional changes to the deliverable will need an approved change request.

DELIVERABLE DELIVERABLE REVIEW – SIGN-OFF OR FEEDBACK

DELOITTE ADDRESSES FEEDBACK

ACCEPTANCE OR FEEDBACK

All Sign-off should occur as early as possible, not to exceed ten business days unless agreed upon in advance. If deemed unacceptable, feedback should be given as early as possible, not to exceed ten business days from deliverable submission. If no sign-off or feedback is provided, Deloitte may consider a Deliverable deemed accepted as-is.

As early as possible, not to exceed ten business days unless agreed upon in advance.


4.2 PRODUCT LIFECYCLE


Initiation Conduct kick off sessions for project planning, architecture, technical, and testing work streams.

Conduct discovery sessions with CSES to assess current state.

1.1_A Project Ramp Up and Discovery Documentation

Plan Create documents detailing the approach, criteria, and timeline for all testing, trainings, and implementation.

1.3_A Test Plan

1.13 Implementation Plan

Define Create a future state architecture diagram and document defining the end state for CSES ’s consideration for the refactored solution.

1.3_B Future State Architecture

Design Assist CSES in installing multiple environments to support platform migration.

Provide one innoWake Enabler train-the-trainer training to record automated test scripts on mainframe for Base Online testing.

Set up required Deloitte tools to support platform migration.

1.3_C innoWake Enabler: test Training

1.2_A Development and Test Core Environments Installation

1.6_B Performance Environment Installation

1.11_A SIT Test Environment

PAGE | 17



Installation

1.12_A User Acceptance Testing (UAT), Pre-Production (as needed) and Production Environments Installation

2.1 Contractor Tools Setup

Build (& Test) Perform migration activities including: analyzing parser output, refactoring assets, and migration CSES Data.

Perform parser error remediation.

Perform unit testing activities.

Perform remaining testing activities.

Generate a testing completion report at the end of each testing phase.

Provide input into the development of the pilot program that includes the scope, participants, and timeline. Pilot period and user base to span up to 60 calendar days.

Deliver trainings documented in the training plan.

Generate a training completion report at the completion of each training.

1.4_A Test Report Template

1.6_A Training Plan

1.17_A Training Completion Report

2.2 Migrated Application Assets (Online)

3.1 Migrated Application Assets (Batch)

3.2 Parser Error Remediation

3.3 Base Unit Tested Application

4.1 Pilot

5.1 Optimized/Tested Applications and Infrastructure

5.2 Developer and Administrator Training

5..3 User Acceptance Test Training

5.4 End User Training

Deploy Support CSES in completing tasks itemized in the Implementation Plan.

Provide Go-Live and post-implementation support for the CSES application.

5.5 Implementation Support

5.6 Go Live Support

Close Provide technical support for the CSES application for 182 calendar days after Go-Live.

6.1 Production Support

4.2.1 TECHNICAL STRATEGY

The migration approach uses a Refactoring Methodology to migrate the existing CSES system from the current set of technologies (DB2 and COBOL/CAGEN) to the unified target technologies (Oracle DB and Java). At a high level, the approach consists of three parallel

PAGE | 18


transformations: data, code, and screens. Please refer to the appendix for a discussion of the Refactoring Methodology and its guiding principles.

Data is migrated in a one-to-one approach from DB2 to Oracle DB. That means that all structures contained in the mainframe DB2 database are migrated to Oracle DB wherever possible. Code is prepared for automated transformation from COBOL/CAGEN to the target language Java. After the refactoring, the team uses automated tools to assess the code quality and the new Application Lifecycle Management (ALM) build processes to coordinate delivery of functionality for testing and deployment. Screens are migrated similarly to render using HTML5/Angular JS in a web browser.

A migration project to transition a legacy system using Refactoring Methodology translates into a project experience that is quite different than what might be encountered in a traditional system development lifecycle. Time emphasis is shifted from sequential requirements and design processes to an agile and model-driven testing and validation process. This translates into project teams that have a unique skill composition and structure, employ techniques and tools unique to a refactoring effort, and proceed along a compressed timeline.

4.2.2 PRODUCT AND PRODUCT DEVELOPMENT DELIVERABLES

The following is a list of Product Deliverables that are driven by the product management methodology requirements and standard project management practices regardless of the product requirements of the project.

4.2.2.1 DEL 1.1_A Project Ramp Up and Discovery DocumentationDescription – The Deloitte project team will conduct kick off sessions for project planning, architecture, technical, and testing work streams and facilitate required discovery sessions to assess CSES ’s current state.

Deliverable Acceptance Criteria – Must meet acceptance of designated CSES reviewersStandards for Content and Format - Signed DED and QA ChecklistQuality Review – Will be reviewed and approved by designated CSES reviewers

4.2.2.2 DEL 1.3_A Test PlanDescription – Deloitte will document the testing approach, criteria, and timeline for Unit Test, System Integration Test, Performance Test and User Acceptance Test. The test plan shall cover the following topics: Testing Approach, Timeline, Entry/Exit Criteria, Roles and Responsibilities, Defect Severity Definition, Testing Tools, and Defect Management.



PAGE | 19


4.2.2.3 DEL 1.2_A Core Environments InstallationDescription – Deloitte will assist CSES to install multiple environments (Development and Test) to support platform migration.



4.2.2.4 DEL 1.3_B Future State Architecture (with sizing recommendation)

Description – Deloitte will create a future state architecture diagram that details the proposed end state for the State’s consideration for the refactored solution.



4.2.2.5 DEL 1.3_B innoWake Enabler: test TrainingDescription – Deloitte will work with the Procuring Agency to provide one Contractor Tool innoWake Enabler train-the-trainer training to record automated test scripts on mainframe for Base Online testing.



4.2.2.6 DEL 1.4_A Test Report TemplateDescription – Deloitte will generate a testing completion report during Unit Test, System Integration Test, and Performance Test phases that details the outcome of the tests performed, the report shall entail: Overall Test Completion Report, Job Processing Time, Screens, Scenarios, and Exit Criteria Compliance



4.2.2.7 DEL 1.6_A Training PlanDescription – Deloitte will produce a training plan that includes the


PAGE | 20


following: Training Approach, Location of the training session(s), Audience, Pre-requisites, Duration, Content/Curriculum, Evaluation Criteria


4.2.2.8 DEL 1.6_B Performance Environment InstallationDescription – Deloitte will assist CSES to install the Performance environment to support platform migration.



4.2.2.9 DEL 1.11_A SIT Test Environment InstallationDescription – Deloitte will assist CSES to install the SIT environment to support platform migration.



4.2.2.10 DEL 1.13_A Implementation PlanDescription – Deloitte will develop a CSES Implementation Plan that includes the following: Implementation cutover schedule for the cutover period, Itemization of the implementation cutover resource requirements and activities / tasks and Go/No-Go Decision Criteria in collaboration with the Procuring Agency and the Contractor leadership.



4.2.2.11 DEL 1.12_A User Acceptance Testing (UAT), Pre-Production (as needed) and Production Environment Installation

Description – Deloitte will assist CSES to install the Performance environment to support platform migration.



PAGE | 21



4.2.2.12 DEL 1.17_A Training Completion ReportDescription –Deloitte will generate a Training Completion Report that provides the details about the number of sessions, attendance, and lessons learned from each training session.



4.2.2.13 DEL 1.2_A Development and Test Core Environments Installation

Description – Deloitte will assist CSES to install multiple environments (Development and Test) to support platform migration.



4.2.2.14 DEL 2.1 Contractor Tool SetupDescription – Deloitte will setup Enterprise Engine, Batch, Legacy DevOps - Development, innoWake Enabler to support migration activities.



4.2.2.15 DEL 2.2 Migrated Application Assets (Online)Description – Deloitte will perform the software configuration, application migration, and data migration for Online in Development and Test environments. This consists of the following task: analyze parser output, refactor assets, and migrate CSES Data.



4.2.2.16 DEL 1.1_A SIT Test Environment InstallationDescription – Deloitte will install and configure the defined software components within the provisioned


PAGE | 22


4.2.2.17 DEL 3.1 Migrated Application Assets (Batch)Description – The Contractor shall further perform the software configuration, application migration, and data migration for Batch in Java in the Development and Test environments. This consists of the following tasks: analyze parser output, refactor assets, and migrate CSES Data.



4.2.2.18 DEL 3.2 Parser Error RemediationDescription – Deloitte will make configuration changes to the Migration Tool and update the refactoring engine to resolve parsing errors identified in CSES ’s code during the build and unit test phase.



4.2.2.19 DEL 3.3 Base Unit Tested ApplicationDescription – Deloitte will perform the following tasks to test the stability and responsiveness of the software application: develop automated test scripts and execute base-level unit testing.



4.2.2.20 DEL 1.12_A User Acceptance Testing (UAT), Pre-Production (as needed) and Production Environments Installation

Description – Deloitte will assist CSES to install multiple environments (UAT, Pre-Prod, Prod) to support platform migration.



4.2.2.21 DEL 5.1 Optimized/Tested Application and InfrastructureDescription – Deloitte will perform the following tasks to maintain the stability and responsiveness of the software application:



PAGE | 23


systems/integration testing, develop automated performance scripts, and limited optimization to meet specified design requirements.


4.2.2.22 DEL 5.2 Developer and Administrator TrainingDescription – Deloitte will deliver training sessions specifically for CSES Developers and system administrators. This will be limited to 10 developers up to 10 consecutive days at a single location and 10 system administrators up to 5 consecutive days at a single location.



4.2.2.23 DEL 5.3 User Acceptance Test TrainingDescription – Deloitte will conduct train-the-trainer sessions focused on assisting CSES ’s system users designated as UAT leads to perform UAT of the CSES application



4.2.2.24 DEL 5.4 End User TrainingDescription – Deloitte will create a basic system user training guide in PowerPoint that provides high-level system information to daily end users of the system.



4.2.2.25 DEL 5.5 Implementation SupportDescription – Deloitte will support the CSES Production Readiness Review including: packaging approved Test Plans and Results,



PAGE | 24


verifying data migration result from UAT conduction by CSES, and reviewing and providing feedback on CSES application operationalization and support plan including support tiers, roles, and responsibilities.

Deloitte will coordinate with and support CSES in completing tasks listed in the Implementation Plan.

Deloitte will facilitate two scheduled Mock Cutovers per approved Implementation Plan.

Deloitte will prepare for, conduct, and document the Go/No-Go Decision Meeting per the work plan schedule for CSES review and acceptance.


4.2.2.26 DEL 5.6 Go Live SupportDescription – Deloitte will provide Go Live and post-implementation support for the Refactored CSES application as detailed in the SOW.

Deloitte will document defects and defect fixes in a Defect Log for submission to CSES.



4.2.2.27 DEL 6.1 Production SupportDescription – Deloitte will provide technical support for the Refactored CSES application for 182 calendar days after Go-Live. The technical support includes: CSES application severity 1 production defect remediation and CSES application severity 2 to 4 production defect remediation.



4.2.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS

The NM CSES Project Manager will review the completed deliverable and the documentation supporting the review activities.

PAGE | 25


4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE

Deliverable acceptance will be governed in accordance with Article 4 of the Contract. During the sign-off process, the reviewer may provide additional feedback which will be documented and addressed. The reviewer will sign-off or provide feedback on the deliverable within the time documented in the table in section below. Upon completion, the reviewer will document deliverable sign-off by completing the Deliverable Sign-off Form located on the project SharePoint site and send to the Deloitte Project Management Office (PMO) via e-mail.


5.0 PROJECT WORK

5.1 WORK BREAKDOWN STRUCTURE (WBS)The WBS structure for the CSES Refactoring (Transformation) Project Work Plan will have five levels and organizes work effort for the project as shown below:

Figure 5.1: WBS Structure

Each element in the WBS structure is represented in hierarchical form by a series of numbers that uniquely identify it from the other elements.

The meaning of each level in the WBS is described below.

WBS Level Description

0 – Project CSES Refactoring (Transformation) Project

1 - Cross Functional The cross-project thread

PAGE | 26


WBS Level Description

Activities

2 – Phase The associated project phase

3 – Task The associated activity (e.g. Develop Project Management Plan)

4 - Deliverable/Step The work product subject to review and acceptance (e.g., Project Charter) and/or step to complete the task

Please refer to Attachment C for more details related to the CSES Refactoring (Transformation) Project Work Plan.

Identifier Work Package Description Definition/Objective Milestone/Deliverable

1 Project Management Establish project controls DEL1.1_A Project Ramp Up and Discovery DocumentationDEL1.1_B Weekly Status Report

2 Project Planning Determine project scope and plan project resources, costs, and timeline

DEL 1.1_C Deliverable Dependency PlanDEL 1.1_D Work PlanDEL1.1_E Project Management PlanDEL 1.13_A Implementation PlanDEL 1.3_A Test PlanDEL 1.6_A Training Plan

3 Requirements and Design Determine any updates or changes that may be needed to be made to system functionality

DEL 1.3_B Future State Architecture

4 Infrastructure and Environments

Setup necessary tooling and testing environments

DEL1.11_A SIT Environment InstallationDEL1.12_A UAT, Pre-Prod, Prod Environment InstallationDEL 1.2_A Development and Test Core Environments InstallationDEL1.6_B Performance Environment Installation

5 Refactoring Prep Prepare legacy code for refactoring

DEL1.3_C innoWake Enabler: test TrainingDEL2.1 Contractor Tools Setup

PAGE | 27


Identifier Work Package Description Definition/Objective Milestone/Deliverable

6 Develop Make any required changes to system functionality and reconcile all third-party interfaces

DEL2.2 Migrated Application Assets (Online)DEL3.1 Migrated Application Assets (Batch)DEL3.2 Parser Error Remediation

7 Unit Test Test to determine whether functionality of the refactored system matches that of the legacy CSES system

DEL3.3 Base Unit Tested ApplicationDEL1.4_A Test Report Template

8 System Test End to end testing including interface testing

DEL1.4_A Test Report Template

9 UAT Testing completed by end users

DEL 5.3 User Acceptance Test Training

10 Performance Test Testing used to determine whether performance of the refactored system matches if not exceeds that of the legacy CSES system

DEL 5.1 Optimized Tested Applications and InfrastructureDEL1.4_A Test Report Template

11 Training Provide CSES resources with trainings and training materials as determined in the SOW for the newly refactored system

DEL5.2 Developer and Administrator TrainingDEL 5.3 User Acceptance Test Training DEL 5.4 End User TrainingDEL1.17_A Training Completion Report

12 Knowledge Transfer Provide CSES resources with knowledge necessary to own the newly refactored system

13 Deploy Conduct the pilot per the identified pilot strategy.Deploy the newly refactored system to the production environment

DEL4.1 PilotDEL5.5 Implementation SupportDEL5.6 Go-Live Support

14 M&O Provide support to CSES post-deployment

DEL 6.1 Production SupportDEL 7.1 Application Maintenance and Operations Support

15 All Phases Provides Ad-Hoc Support as required by HSD

DEL 7.2 Ad-Hoc Support

PAGE | 28


5.2 SCHEDULE ALLOCATION - PROJECT TIMELINEEach phase of the project has certain deliverables associated to it which are dependencies to begin the next phase. The schedule will be managed in detail using DEL 1.1_D Work Plan.

Figure 5.2: Project Timeline

5.3 PROJECT BUDGET

ESTIMATED PROJECT BUDGET (DO NOT INCLUDE MAINTENANCE AND OPERATIONS.)

COMMENTS: 1 THIS BUDGET IS BASED ON THE NEED FOR FULL CSES REPLACEMENT AS DETERMINED IN THE FY21 C2 REQUEST AND WOULD REQUIRE ADDITIONAL REQUESTS FROM FY22 TO FY24

Description FY19 & Prior

FY20 FY21 FY22 FY23 FY24 Total

PAGE | 29


Staff – Internal $3,067 $99,481 $1,402,750 $1,377,880 $2,883,179

Consulting Services

Staff Augmentation $152,265 $129,920 $1,822,601 $425,700 $2,530,487

Contracted Services IV&V $42,071 $129,450 $1,385,549 $1,169,533 $643,33

9 $3,369,943

Contracted Services

Contracted PMO $2,514,181 $2,514,181

Contracted Services

Feasibility Study $39,038 $30,418 $69,456

Contracted Services

Implementation Vendor $675,000 $4,050,000 $19,275,000 $22,000,000 $46,000,00

0

Training $11,590 $105,000 $116,590

Hardware $113,054 $1,241,592 $1,275,278 $1,155,000 $3,784,924

Software $699,789 $2,005,933 $1,607,500 $4,313,222

TOTAL $2,705,484 $1,005,121 $8,147,914 $25,770,2101 $27,309,913 $643,339 $65,581,982

5.4 PROJECT TEAM

PAGE | 30


5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE

Figure 5.4.1: Deloitte Project Team Org Chart

5.4.2 PROJECT TEAM ROLES AND RESPONSIBILITIES

For a full list of responsibilities, please refer to the RACI chart in section C2 of the Appendix.

NM CSES Team

PAGE | 31


Figure 5.4.2: Deloitte Project Team

Deloitte Team

ROLE RESPONSIBILITY NAME FUNCTIONAL AREA

Project Principal Senior Deloitte Executive responsible for the overall relationship between Deloitte and NM CSES

Commits Deloitte resources to the CSES Refactoring (Transformation) Project

Serves as the final escalation point for Deloitte

Member of the Executive Steering Committee

Rachel Frey Executive

Project Manager Responsible for the successful completion and delivery of the project

Directs project teams, workstreams, and project management disciplines

Works closely with team managers to see that the solution meets business, functional and technical requirements

Serves as a liaison between NM CSES and Deloitte

Member of the Executive Steering Committee and Change Control Board

Yihong Zeng PMO

PAGE | 32



Project Advisor Provides subject matter expertise on Child Support business processes and technology

Mentors Deloitte and NM CSES team members on project issues and decision analysis based on experience

Participates in requirement verification and design activities

Translates client vision to actionable tasks by the project team

Mike Phelan Gordon Aspin

Executive

PMO Staff Prepares status report CSES

Plans meetings and captures minutes

Provides PM tool support

Performs administrative functions

Prepares project bills and performs reconciliation

Support NM CSES procurement management

Parag BaralMatthew Alan Golden

PMO

Technical Lead/ Data Architect

Responsible for all technical deliverables

Plans, controls, and executes tasks related to migrating CSES and enterprise reporting

Manages Online, Batch/TPP, and Data team members and directs work related to automated conversion of legacy CSES system

Plans and directs the pilot and rollout of refactored systems

Report status of technical activities

Prakash Chidambaram

Jagadish Siddaramegowda

Technical

PAGE | 33



Test Lead Responsible for planning, managing, directing, and coordinating the test phase of the project

Works across works streams to verify the system meets business and technical requirements

Identifies and implements tools to support test effort

Works with team managers to develop test cases and execute system testing

Abhishek Upadhyay Testing

Online/

Batch/TPP Developers

Designs, builds, and tests batch programs according to requirements

Monitors and report on batch performance

Tests online screens according to requirements

Durga GuttulaJagriti DasBella ShahShravya KalvalaAvik DasSwapnil KharcheShalin Sawant

Technical

Infrastructure Architect

Sets up and maintains the technical aspects of the system configuration

Performs software installation and software license application

Defines environment management activities (job definition, workstation setup, printing setup)

Applies patches and upgrades

Performs object promotion (migration of development and configuration across the systems landscape)

Executes performance tuning and monitoring

Jagadish Siddaramegowda

Infrastructure

PAGE | 34



Dev-Ops Integrating Dev Ops tools and processes for technical and testing team.

Yogesh BhandariKidane Yosief

Dev-Ops

Subject Matter Experts (SMEs)

Project staff with specific subject matter expertise and knowledge that can provide input to the project as needed.

Stefan MichaelsenRavindra Bhai ShethAnkur Srivastav

GeneralOracle DB

5.5 STAFF PLANNING AND RESOURCE ACQUISITIONThe following table covers what roles are required to complete the Future State Architecture Deliverable. The Future State Architecture has been accepted by HSD.

5.5.1 PROJECT STAFF

RESOURCE COST ESTIMATE

ESTIMATED HOURS AVAILABILITY SKILL SET

WORK PRODUCT/

DELIVER-ABLE

CSES Security SME n/a n/a n/a Networks, Security and Interfaces


CSES Lead Architect n/a n/a n/a System Architecture


CSES Oracle DBA n/a n/a n/a Oracle Database Administration


CSES Linux Administrator

n/a n/a n/a Linux Administration


5.5.2 NON-PERSONNEL RESOURCES

The following table covers all non-personnel resources for the project and who will be providing said resources when present at HSD’s worksite.

RESOURCE COST ESTIMATE

ESTIMATED UNITS/HOURS AVAILABILITY SOURCE

WORK PRODUCT/

DELIVERABLE

12 VMs and VPN Tokens

N/A N/A Yes CSES N/A

X printers N/A N/A Yes CSES N/A

PAGE | 35


Cubicles N/A N/A Yes CSES N/A

Offices N/A N/A Yes CSES N/A

Chairs N/A N/A Yes CSES N/A

Desks N/A N/A Yes CSES N/A

Meeting rooms


Break room N/A N/A Yes CSES N/A

Bathrooms N/A N/A Yes CSES N/A

Server room N/A N/A Yes CSES N/A

Copier room N/A N/A Yes CSES N/A

Mechanical room


Reception area


Projectors N/A N/A Yes CSES N/A

Screen for Projector


Phones N/A N/A Yes CSES N/A

Badges N/A N/A Yes CSES N/A

Polycom N/A N/A Yes CSES N/A

Whiteboard N/A N/A Yes CSES N/A

Office Supplies


Shredder N/A N/A Yes CSES N/A

Paper N/A N/A Yes CSES N/A

Locked Cabinets


Water N/A N/A Yes CSES N/A

PAGE | 36


5.6 PROJECT LOGISTICS 5.6.1 PROJECT TEAM TRAINING

Please refer to the CSES Refactoring (Transformation) Project Training Plan for more details on formal project trainings.

Deloitte will produce a training plan as a deliverable for month 6 that includes the following: Training Approach, Location of the training session(s), Audience, Pre-requisites, Duration, Content/Curriculum, Evaluation Criteria. The training plan is currently being developed and will be submitted to HSD for approval by 8/21/2020.

RESOURCECOST ESTIMATE

ESTIMATED HOURS AVAILABILITY SKILL SET

WORK PRODUCT/

DELIVERABLE

N/A

6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT6.1.1 RISK MANAGEMENT STRATEGY

The flow-chart below summarizes the project’s risk management process:

PAGE | 37


Figure 6.1.1: Risk Management Process Flow

6.1.2 PROJECT RISK IDENTIFICATION

At the beginning of the project and then during weekly risk review meetings (see Risk Meetings below), project leadership (i.e., project managers and team leads) will identify risks that can negatively impact project outcomes. The CSES – Refactoring Project Issues and Risks Log will be maintained on SharePoint.

Risks are identified during risk meetings organized by the project manager (see Risk Meetings section below).

Initial project risks that were identified as part of upfront project planning and documented in the CSES Refactoring Project Issues and Risks Log are reviewed during the initial risk review meeting.

As risks are identified, the following information will be captured:o Risk No. – Unique identifier for the risko Created By – Name of user who created the risko Created On – Date the risk was created

PAGE | 38


o Assigned To (“risk owner”) – the project team member responsible to develop and implement the risk mitigation strategy

o Type - a means for categorizing risks (see subsequent section)o Probability – the likelihood of the risk occurringo Impact – the overall impact if the risk does occuro Score – Risk score, calculated as the product of risk probability x impact o Description – a high-level description of the risko Identified on – date the risk was identified, which may be prior to the current dateo Due date – Risk mitigation target dateo Source – Origin of the risko Stakeholders – Names of project stakeholders who are actively involved or

interested in this risko Escalation level – Engagement level or group to address risko Risk Response – Response strategy selected for the risk, which is required to

close a risk (see subsequent section)o Response Plan – Response plan details required to close a risk o Risk Contingency Plan – Description of the risk contingency or backup plano Status – the status of the risk as it flows through the process

New – The risk has been created but not started In Progress – The risk is in Progress Pending Approval – The risk is awaiting approval Escalated – The risk has been escalated to a higher approval body Closed – The risk has been closed and all required fields have been

updated Cancelled – The risk was no longer required, and no action was taken

o Risk closure date – Date when risk was closed o Risk remarks – to track the status or history of the risko Reference materials – Links to any reference materials related to the risk

6.1.3 PROJECT RISK MITIGATION APPROACH

Develop Risk Response

For “High” severity risks, the assigned team member(s) (i.e., risk owner(s)) will analyze the risk in more detail, determine the appropriate risk mitigation strategy and if necessary, develop the risk response plan:

Risk response – Proposed risk mitigation strategy o Accept— accept the risk, but monitor ito Avoid— perform impact analysis and devise a strategy to avoid the risko Mitigate— perform impact analysis and determine actions to eliminate or reduce

the risko Transfer— transfer the risk responsibility to another group

Response plan – Developed by the risk owner if necessary and details the risk mitigation strategy selected. The plan is maintained in SharePoint.

Contingency Plan – Identify actions to take as a backup plan if the initial risk response PAGE | 39


plan does not work. The plan is maintained in SharePoint. Update CSES Refactoring Project Work Plan if required.

Once the risk owner completes his/her risk assessment and proposed risk response strategy and response plan, the risk meeting team needs to review and approve the plan, which may not occur until the next risk review meeting, unless the risk’s priority is “Critical” or “High,” in which case a special risk meeting may be organized to review and finalize the risk mitigation strategy, response plan, and contingency (i.e., “backup”) plan for the risk.

Risks will have “In Progress” status during this process. Where needed, the risk will be escalated to the appropriate project level for review and analysis, per the levels defined in Section 2.3 of the Project Management Plan.

For “Medium” severity risks and lower, the assigned team will analyze and determine if the risk needs to be addressed or can be deferred. The process outlined below will be followed to determine the action taken on the risk.

Monitor Risk

The Project Management Office (PMO) monitors the risk throughout the life of the project, for as long as the risk remains in active (i.e., “In Progress”) status.

Determine the appropriate new risk owner(s) if the risk assignment needs to change Where necessary, update the risk assessment, response, or other details Determine if or when a risk needs to be escalated to the next project level

Determine if Risk is Realized

As part of risk monitoring, the PMO determines whether the risk has been realized on the project.

For realized risks, follow the risk mitigation strategy steps included in the approved risk response plan (where applicable), and log a new issue in the CSES Refactoring Project Issues Log for the realized risk.

o Once the issue record is created, cross-reference the new Issue # in the CSES Refactoring Project Risks Log before closing the Risk.

If the risk has not been realized, continue monitoring it throughout the project, for as long as the risk is active or “In Progress.”

Realized Risk Conversion to Issue

For a realized risk that converts to a project issue, address it using the project’s standard issue management process.

Enter the issue cross-reference number in the CSES Refactoring Project Risks Log before closing it.

Determine if Risk is still Active

Determine the status of the risk:

PAGE | 40


If the risk is no longer active, proceed to close the risk. If the risk is still active, continue monitoring the risk, escalating when necessary.

Close Risk

With the agreement of NM CSES, set the risk status to “Closed” in the CSES Refactoring Project Risks Log located on SharePoint.

High, Medium High, and Medium risks will be discussed at the weekly status meeting to determine any updates to status.

Team leads can close low priority risks by updating text in the CSES Refactoring Project Issues and Risks Log before closing it.

6.1.4 RISK REPORTING AND ESCALATION STRATEGY

Active risks will be tracked and published in the weekly Project Status Report and the monthly Project Status Report as seen in the figure below. A risk that is realized will either: (1) Initiate the approved response plan defined for the risk; or (2) Be logged as a new issue to be addressed by the project’s defined issue management process.

PAGE | 41


Figure 6.1.4: NM CSES Project Team Status Report

The effectiveness of risk mitigation can be measured by the success of the response strategy. How many risks were avoided, mitigated, accepted or transferred? Were there any downstream impacts? Being able to answer these questions will help determine effective risk mitigation.

Risk Meetings

Project leadership (i.e., project managers and team leads) will meet weekly to review and add/update risks. This meeting will be scheduled by the Deloitte Project Manager. The table below describes additional details regarding the weekly risk review meeting.

MEETING LOGISTICS PROJECT PLAN

Meeting Frequency and Weekly as part of Weekly Client Status Meeting

PAGE | 42



Schedule

Participants Project managers, team leads, and PMO staff

Attendees needed for a Quorum 3 people with a NM CSES representative majority

Meeting Agenda Review active risks to determine if probability or impact has changed, or whether any risks can be closed

Identify new risks (and determine probability and impact)

Assign an owner for creating a risk mitigation strategy, for inclusion in the risk response plan in JIRA, for any “High” severity risks that don’t currently have a mitigation strategy (could be an existing risk with a changed assessment and severity score or a new risk)

Review drafts of any new mitigation strategies

Determine if any risks need to be escalated

After each risk review meeting, the Deloitte PMO team has the following responsibilities:

Update Project Issues and Risks Log to record risk changes and additions

Communicate the updated risks

6.1.5 PROJECT RISK TRACKING APPROACH

The following risk types will be used to categorize identified risks in the CSES Refactoring (Transformation) Project Issues and Risks Log.

RISK TYPE RISK TYPE DESCRIPTION

Contract Any risk related to the contracts of the project (such as a signed agreement between Deloitte and NM CSES or subcontractors).

External Any risk related to environmental factors largely outside the control of the project (such as cultural, legal, or regulatory).

Financial Any risk related to the budget or cost structure of the project (such as increase or decrease in the project-related budget).

Functional Any risk related to the overall function of the product (such as requirements or design) being developed by the project.

Quality Any risk related to the quality requirements of the project.

PAGE | 43


RISK TYPE RISK TYPE DESCRIPTION

Organization Any risk related to internal, NM CSES, or third-party organizational or business changes (such as executive leadership role changes).

Performance Any risk associated with the performance of the application (such as response time, stress testing, and development environments).

Project Management Any risk related to the management of the project (such as communications, status reporting, and issues management).

Resource Any risk related to project resources (such as the addition or removal of resources).

Schedule Any risk related to the Work Plan and related tasks (such as extensions or reductions of the project timeline).

Scope Any risk related to project scope (such as process, module, and development objects).

Technical Any risk related to software or hardware, including infrastructure related to the project.

General Any risk that cannot be categorized into one of the above categories.

Risk Severity Scoring Matrix

When risks are identified, they will be qualitatively analysed in terms of impact and probability. Impact and probability will both be assessed on a range of 1 – 5, with 1 being Low and 5 being High. The two values will then be multiplied to compute an overall risk severity. The table below outlines the complete set of values and the severity level for each combination.

The determination of severity will be done collaboratively during the risk review meetings (see subsequent section for risk meeting planning). The project team will create a formal risk mitigation strategy for risks that are determined to be High severity. Other risks will be monitored and reviewed but will not have risk mitigation strategies. Risk mitigation planning will be a joint responsibility between the Deloitte and HSD project teams.

PAGE | 44


Levels 1-5 Range:

IMPACT PROBABILITY

1-Low 2-Low/Medium 3-Medium 4-Medium/High 5-High5-High Low (5) Medium (10) High (15) High (20) High (25)4-Medium/High Low (4) Medium (8) Medium (12) High (16) High (20)3-Medium Low (3) Medium (6) Medium (9) Medium (12) High (15)2-Low/Medium Low (2) Low (4) Medium (6) Medium (8) Medium (10)1-Low Low (1) Low (2) Low (3) Low (4) Low (5)

SCORE SEVERITY

1-5 Low6-12 Medium13-25 High

6.1.6 ISSUE MANAGEMENT

6.1.6.1 Internal Issue Escalation and Resolution ProcessThe following flow chart summarizes the Change Control Process for Change Control Board (CCB).

PAGE | 45


6.1.6.2 External Issue Escalation and Resolution Process

This section documents the process, templates, and tools that the project will use to identify, evaluate, and manage issues throughout the life of the project. An issue is an event that has occurred that will impact the project schedule, scope, budget, or quality.

Process SummaryThe flow-chart below summarizes the issue management process:

1. Create Issue 2. Resolve Issue

Legend

StepSupporting

Output DecisionTask ProcedureInputs / Outputs

Project Management

Plan

3. Change Request?

5. Close Issue

4. Manage Change

RequestsYes

No

Issues Log

Figure 6.1.6.2: Issue Management Process Flow

Create IssueProject team members identify issues impacting the project and document them in the CSES Refactoring Project Issues and Risks Log in SharePoint, the project’s issue logging and management tool.

Using the CSES Refactoring Project Issues and Risks Log, any project team member can identify a project issue at any point in the project lifecycle.

The person identifying and logging the issue needs to provide the available information regarding the new issue. Required fields include:

o Issue No.o Issue Sourceo Issue Description

PAGE | 46


o Priorityo Reported Byo Open Dateo Responsibilityo Statuso Closed Date

The CSES Refactoring Project Issues and Risks Log tracks the status of an issue as it flows through the process.

The joint Deloitte/NM CSES PMO will review and validate “New” issue status records from the project team, removing issue entries that are not valid.

A joint PMO designee will then confirm or re-assign valid issues to the appropriate project team member(s) (issue owners) for detailed analysis and resolution planning.

The assigned team member(s) will confirm or define the following fields for an issue record after completing the necessary due diligence and analysis on the issue:

Priority – the priority issue ratings for the project are as follows:o Critical— the issue is jeopardizing overall project objectives and must be

addressed immediatelyo High— the issue is negatively impacting the project significantly (for example,

cost overruns or milestone delays) and must be addressed as soon as possibleo Medium— the issue is negatively impacting the project and should be addressed,

monitored, and controlled using regular project issue management processeso Low— the issue has minimal impact and should be addressed as cost and

schedule permits Type – Issue types are defined in a table in a later section Project areas and stakeholders impacted: Schedule, Scope, Budget, Release, Team, Phase,

Thread, Stakeholder(s) Resolution plans, including:

o Escalation Levelo Resolutiono Whether a change request (CR) needs to be created to close the issueo Other closure criteria

The appropriate project manager should review and approve the proposed issue resolution.

Resolve IssueThe issue owner works to manage the issue to a successful close.

Implement the resolution actions to close the issue. o Determine whether the resolution actions require a Change Request (see next

step) Document the resolution results. If the issue cannot be resolved, escalate the issue.

Change Request Required to Resolve IssueThe issue owner determines whether a change request is required to perform the issue resolution steps.

PAGE | 47


If an issue’s resolution actions require work outside the defined scope for the project or changes to signed-off project documents, the issue owner needs to create a change request to resolve the issue.

Manage Change Requests Perform the Manage Change Requests task to see if the change request to resolve the issue is approved.

No work on the issue resolution steps can be performed until the associated change request (CR) for the issue is approved by the project’s joint Deloitte/NM CSES Change Control Board (CCB).

Issue CRs that are not approved by the joint CCB will need to be set to “Closed” or “Cancelled” status, as appropriate. The definition of “Closed” is that the change has been implemented and all required fields have been updated. No further action is required. The definition of “Cancelled” is the change request is no longer required and no action was taken. No further action is required.

Close Issue Confirm that the resolution steps completed resolved the issue successfully.

The appropriate stakeholder(s) identified for the issue should help confirm the issue resolution.

For issues where resolution is confirmed, a designated project team member (i.e. PMO designee, Project manager, or Program Manager) will set the issue record status to “Closed.”

Issues where the resolution results were not confirmed will remain in “In Progress” status until they can be successfully confirmed.

Issue TypesThe following issue types will be used when logging issues.

ISSUE TYPE ISSUE TYPE DESCRIPTION

Contract Any issue related to the contracts of the project (such as a signed agreement between Deloitte and the NM CSES or subcontractors).

External Any issue related to environmental factors largely outside the control of the project (such as cultural, legal, or regulatory).

Financial Any issue related to the budget or cost structure of the project (such as increase or decrease in the project-related budget).

Functional Any issue related to the overall function of the product (such as requirements or design) being developed by the project.

Quality Any issue related to the quality requirements of the project.

Organization Any issue related to internal, NM CSES, or third-party organizational or business changes (such as executive leadership role changes).

Performance Any issue associated with the performance of the application (such as response time, stress testing, and development environments).

PAGE | 48


ISSUE TYPE ISSUE TYPE DESCRIPTION

Project Management Any issue related to the management of the project (such as communications, status reporting, and issues management).

Resource Any issue related to project resources (such as the addition or removal of resources).

Schedule Any issue related to the Work Plan and related tasks (such as extensions or reductions of the project timeline).

Scope Any issue related to project scope (such as process, module, and development objects).

Technical Any issue related to software or hardware, including infrastructure related to the project.

General Any issue that cannot be categorized into one of the above categories.

Issue MonitoringCSES Refactoring Project issues will be monitored by using the CSES Refactoring Project Issues and Risks Log. Authorized team members will have access to the log to enter issues and monitor them.

Issue MeetingsIssue identification and resolution is an ongoing process. Identifying and resolving issues in a timely manner is a critical success factor for the project, and both CSES Refactoring Project team and Deloitte staff need to commit to supporting timely issue resolution. Held in conjunction with the Risk Meeting, the issue portion of the meeting plan is described in the table below to address project issues:


Meeting Frequency and Schedule Weekly as part of the Weekly Client Status Meeting

Participants Project managers, team leads, and PMO staffAttendees needed for a Quorum 3 people, with a NM CSES representative

majorityMeeting Agenda Announcements

Review “New” issuesReview any “In Progress” issues that need attentionDetermine if any issues need to be escalated

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&VNM CSES has executed a contract for IV&V services for support. IV&V adds quality to the project by helping the project principals keep the project on schedule and within budget, and by providing oversight for the vendor’s contractual compliance. IV&V also assists by reviewing

PAGE | 49


technical plans and methodologies, data migration and validation effort, and data management processes.

IV&V will provide accountability for the following areas:

Evaluate client and vendor project management plans, processes, and procedures;

Evaluate stakeholder involvement, ensuring that stakeholders are senior enough within the agency to make resource and budget decisions;

Monitor project activities and the project schedule to assess the progress of the project;

Document and deliver clear, factual analysis of project deliverables;

Identify key areas that pose potential risk to the project and recommending mitigation strategies to reduce those risks;

Evaluate and verify all data migration configuration and processes.

Provide verification that all user acceptance testing documentation is clear and that testing issues are documented, tracked, and fixed;

Evaluate end user training plans for readability, clarity, and completeness;

Monitor end user acceptance of the product;

Evaluate technical, project management and other project-related documents for quality, completeness, clarity and accuracy;

Review CSES architecture, code refactoring and testing processes; and

Evaluate knowledge transfer activities from vendor to Procuring Agency technical and business staff.

The IV&V contractor will produce an initial assessment, followed by monthly assessments throughout the duration of the project. Finally, the IV&V contractor will submit a Project Close-Out Report.

The IV&V contractor shall submit the monthly report to the Department of Information Technology (DoIT), Project Oversight and Compliance Division ([email protected]), the CSES IT Project Manager, the CSES CIO and Executive Steering Committee.

6.3 SCOPE MANAGEMENT PLANDescribe the process that is going to be used to manage the scope of the project. Make sure to address managing stakeholder expectations.

6.3.1 CHANGE CONTROL

6.3.1.1 Change Control ProcessThis section documents the change control process, tasks, and tools the project will use to identify, analyze, prioritize and implement change requests that can impact the project scope, budget, quality, or schedule. The change control process and strategy followed by the project is tentatively documented below. Finalization of the change control process will be finalized at a later date.

PAGE | 50


Process Summary

The flow-chart below summarizes the change control process:

1. Identify and Document

Change Request

2. Perform Impact Analysis

4. Cancel or Reject Change

Request

Legend

StepSupporting

Output DecisionTask ProcedureInputs / Outputs

Project Management

Plan

No,Cancel

OrReject

3. CCB Review and Approval?

Change Requests Log

No, Rework

Yes

Figure 6.3.1.1: Change Control Process Flow

Identify and Document Change Request

Change requests can be identified throughout the life of the project. Changes that affect the scope, budget, schedule, and/or effort or requested changes to signed-off deliverables of the project are formally documented, prioritized, analyzed, reviewed, and approved before implementation.

Identification is the first step of the change control process, and project stakeholders are encouraged to identify and log change requests (CRs). Any project stakeholder can create a “New” change request.

Minor revisions to the management plans (project and quality management) that address usability or personnel changes (e.g., a new team lead) will not require a change request. For these minor revisions the change will be documented in version notes. Both the CSES and Deloitte Project Manager will review and approve minor revisions made in this manner. Any disagreement about the need for or nature of a minor revision will be addressed using the change control process.

The priority level assigned to a CR reflects the criticality and urgency of the CR:

PAGE | 51


Critical— the change request is addressing a problem that can negatively impact overall project outcomes, timeline or objectives and will be addressed immediately

High— the change request is addressing a problem that can negatively impact the project significantly (for example, cost overruns or milestone delays) and will be addressed as soon as possible

Medium— the change request is addressing a problem that can negatively impact the project or parts of the project. The change request should be addressed, monitored, and controlled using regular project change control processes

Low— the change request is addressing a problem with minimal negative impact and will be completed as cost and schedule permits

The project manager(s) will validate each “New” change request and prioritize and assign each valid CR to the appropriate team member for impact analysis on scope, budget, quality and schedule, information that will be presented to the CCB for their review and approval for implementation. Each valid CR will have a status of “In Analysis.” If project leadership collaboratively determines that a change request at this stage should be “Cancelled,” the status of the CR record will be updated accordingly, and the CR will not be assigned for impact analysis.

The project will use SharePoint to document and manage all project change requests throughout the life of the project.

Perform Impact Analysis

All change requests need to be analyzed for impact to project scope, budget, quality and schedule, as well as for clarity, accuracy, and relevance. All impacts of the change request are documented in the Change Request in SharePoint. Feasible options to address the change request should be summarized in the Detailed Description and Justification fields of the CR record. This can also include a description of the impact when the change request is not implemented.

The impact analysis should be reviewed and incorporate the input of each of the primary teams on the project (e.g., the technical team lead determines the technical impact; the organizational change management (OCM) team lead determines the change impact, etc.).

When determining impact, both the estimated effort and the overall schedule impact will be evaluated. If a change request will impact the critical path of the project, then the cost of that change request will include both the incremental effort plus the cost impact of maintaining other essential resources through the extended duration. The Deloitte Project Manager is responsible for determining the cost of any change requests, based upon the impact determined by the various team members.

If a CR estimate requires material effort outside the SOW, Deloitte will work with CSES to determine the approach to provide the estimate.

Each impact analysis includes:

The project work products affected by the proposed change

The impact of the proposed change on project size, deliverables, and requirements

The impact of the proposed change on existing assumptions and constraints

The impact of the proposed change on schedule, including milestones and dependenciesPAGE | 52


The impact of the proposed change in terms of effort and cost

The result of this impact analysis is a recommendation on disposition of the change request. Because changes made earlier in the project lifecycle typically have less impact than changes that occur later, each change request impact analysis will be assigned an expiration date. This is the date by which the CR must be approved. If a CR is not approved by this date, it will either be “Cancelled,” or a new impact analysis will be required.

Once the assigned team member(s) complete their analysis and submit it to the Change Control Board (CCB) for review and approval, the change request status will move to “Pending Approval.”

Approve Change Requests

The information collected for a change request (CR) is reviewed for approval for implementation. The information should be captured in the respective CR record in SharePoint.

Prior to bringing a completed CR to the Change Control Board, the project managers should jointly review the completed documentation. Any questions or issues regarding the CR should be addressed, so that the documentation is complete, clear, and accurate. Once the CR documentation is complete, the Project Management Office will schedule the CR for the next change control board (CCB) meeting. The CCB is the formal committee that evaluates change requests impacting the project.

The project’s Change Control Board (CCB) was previously defined in Section 3 of the Project Management Plan.

The CCB will review “Pending Approval” CRs with complete analysis and justification, and determine the appropriate change control decision:

Approve the CR, changing its status to “Pending Implementation”

Defer the CR, marking its status as “Deferred”

Reject the CR, marking its status as “Rejected”

Request more analysis, changing status of the CR back to “In Analysis”

A change request is not approved until it has been printed and signed by both the designated CSES Project Manager and the Deloitte Lead Engagement Partner/Director.

Implement Approved Change Requests

The final CR documentation, including formal approval, will be retained. No CR will be worked on beyond the impact assessment without first obtaining formal approval in this manner, and the CR record status has been moved to “Pending Implementation.”

Once a CR is approved by the CCB, the Deloitte Project Manager is responsible for adjusting the Work Plan to incorporate the tasks required to implement the approved change request. For smaller CRs, the CSES Project Manager and the Deloitte Project Manager can choose to implement the CR using the action item process defined previously. Regardless, the Deloitte Project Manager is responsible for implementing the approved change by the due date specified; including changing the CSES Refactoring (Transformation) Project Charter if an approved CR impacts end-product scope.

PAGE | 53


The CSES Project Manager and the Deloitte Project Manager communicate the status of the change requests being implemented on a regular basis. The status of every valid change request identified for a project is maintained in SharePoint. Once an approved CR is implemented, the CCB reviews the updates to confirm that the approved change was successfully implemented, and the CR can be “Closed” with no further action required, or “sent back” for further modifications to successfully implement the change.

Close Change Requests

Once the approved CR implementation updates have been reviewed and approved by the CCB, the status of the CR can be set to “Closed.”

Communicate the results of implemented (i.e., “Closed”) or “Rejected” change requests to the project team and internal stakeholders. Update the project’s SharePoint change request record accordingly. Refer to the project’s Status and Stakeholder Communications section for appropriate distribution of information.

Change Request Monitoring

Change requests can be monitored in the Jira Executive Steering Committee Page.

6.3.1.2 Change Control Board (CCB) Change Control Board (CCB)

MEMBERS

HSD Director Sean Pearson

Deputy CIO - Applications Sean Curry

Child Support Director Jeremy Toulouse

CSESR Project Manager Russ Illich

Deputy CIO – Systems & Help Desk Shilo Stewart

CSES Refactor Project Manager Paul Gosnell

CSED Information Support Bureau Chief

Jeff Creecy

Project Advisor Mike Phelan

Lead Engagement Partner Rachel Frey

Deloitte Project Manager Yihong Zeng

ACCOUNTABILITIES

Review project change requests in terms of their impact to the baseline schedule, cost, scope, and quality versus their expected benefits or necessity to stay aligned with the project’s business objectives

Recommend disposition of change requests to the project sponsor

Quorum for voting requires a NM CSES majority

PAGE | 54


RELATIONSHIPS

Change control authority for the project

Communicate to the project through the project manager and PMO

Meets monthly (or ad-hoc for urgent change requests)

Escalates change requests as needed to the steering committee

Change control is an ongoing process. Identifying and qualifying changes in a timely manner is a critical success factor for the project, and both CSES and Deloitte staff will apply appropriate effort to support timely change request disposition. To support this process, the following Change Control Board (CCB) meeting plan will be used to address change requests and change control.

1.) Anyone can add a JIRA issue type of CSES: CCB.2.) Initial assignment of all items to Deloitte PMO.3.) Deloitte PMO will review, request additional information from requester, add watchers,

schedule to CCB agenda.4.) Once all information has been added, Deloitte PMO will change status to Submitted and

owner to CSES PM.5.) CSES PM will approve, delay, cancel, move to “In Review” or request additional

information.6.) Bi-Weekly meeting will be to review any open items (not in approved, denied or

cancelled status) based on priority.7.) All updates will be done in JIRA – not email.8.) Communication of statuses of request will be via JIRA filter that can be distributed as

needed.9.) If member of groups is unable to attend, they can send proxy, or add input/concerns to

JIRA item for review at meeting. 10.) Only voting member is CSES PM – others provide input/recommendations.

MEETING LOGISTICS DESCRIPTION

Meeting Frequency and Schedule

Bi-Weekly, as needed.

Participants Change Control Board Members.

Attendees needed for a Quorum Quorum for voting requires a NM CSES majority.

Meeting Agenda Announcements

Review “New” and “In Analysis” CRs and determine which ones are ready to be submitted to the CCB for approval

Review CRs that have been successfully implemented to verify that the updates are satisfactory

Review any “Deferred” CRs that should be re-considered

Determine if any CRs need to be escalated

PAGE | 55


6.4 PROJECT BUDGET MANAGEMENT6.4.1 BUDGET TRACKING

The CSES PM will present the project budget to the ESC and the CSES Chief Financial Offiicer for review and approval at least monthly, and more often as required.

6.5 COMMUNICATION PLANThe purpose of the Communication Management Plan is to identify the methods of exchanging information between the Deloitte and NM HSD project teams and other project stakeholders. The Communication Plan identifies formal communication approach and protocols that will be employed to keep all stakeholders informed throughout the duration of the project.

The Deloitte and NM HSD project teams will work together to plan, structure, monitor and control the communications on the project. The goal is to set up and maintain a communication approach that emphasizes transparency and effective collaboration by integrating NM HSD's deep knowledge of their system with Deloitte’s experience with application replat forming and making important decisions together.

The project teams will maintain the communication requirements for the project by identifying meaningful details and documenting them via meeting minutes, weekly status reports and monthly executive status reports.

The following tools will be used for collaboration, documentation and project management:

•JIRA: A centralized project management tool used for logging and tracking project activities

•Microsoft SharePoint: A platform to support collaboration and content/documentation management

•Microsoft Project: A project management software that assists in developing and tracking project schedule/timelines

6.5.1 COMMUNICATION MATRIX

Proper, timely escalation of project risks, issues, decisions, and change requests is critical for keeping a project on track. The project escalation levels are described below:

PAGE | 56


COMMUNICATION ITEM

DESCRIPTION OWNER/FACILITATOR

AUDIENCE FREQUENCY METHOD/MEDIA

Weekly Status Report

Report that captures the project activities and progress while highlighting major risks/issues/decision items and discussing any mitigation plans with NM HSD for the identified risks (if any). This report also contains details about project timelines and


NM HSD and Deloitte

Weekly(Wednesday 10:00 AM MTD).

PowerPoint

PDF

Weekly Status Meetings

Meetings to review the project status and discuss any open risks, issues, action items, decisions and risk mitigation approaches.


NM HSD and Deloitte

Weekly Face-to-face and/or Skype meeting

Project Schedule Updates

Updated project schedule to help ensure that both the NM HSD and Deloitte teams are effectively progressing the project as planned. Updates to the project schedule are also presented in the weekly status report.


NM HSD and Deloitte

Weekly Microsoft Project

PDF

Executive Steering Committee Meeting

Monthly checkpoint meeting to discuss project status and outstanding risks and issues.

Deloitte Project Director

NM HSDExecutive Steering Committee

Monthly Face-to-face and/or Skype Meeting

PAGE | 57


COMMUNICATION ITEM

DESCRIPTION OWNER/FACILITATOR

AUDIENCE FREQUENCY METHOD/MEDIA

Workstream Status Meeting

Status meetings specific to a workstream (Testing, Infrastructure and Database touchpoints) to review and discuss the plan, tasks, updates, and any issues and risks.

Deloitte Workstream Leads

NM HSDWorkstream Leads

Varies Face-to-Face and/or Skype Meetings

Figure 6.5.1: Escalation Process

The Executive Steering Committee with be responsible for developing a communications plan as well as all processes for external entities.

The table below describes the overall project escalation levels by process and threshold/criteria. A “control” is an item identified and monitored per the Project Controls Plan (e.g., an issue).

LEVEL ESCALATION PROCESS THRESHOLDS / CRITERIA

Project Managers

Escalation 1: Team leads escalate controls to the project managers (e.g., issues team) by changing the escalation level to 1.

Project controls will be escalated to the project managers when:

The control impacts multiple project teams, or the resolution requires coordination across teams.

PAGE | 58


LEVEL ESCALATION PROCESS THRESHOLDS / CRITERIA

Project Leadership

Escalation 2: Project Managers escalate controls to the project leadership by changing the escalation level to 2.

Controls will be escalated to the project leadership when:

The control cannot be resolved by the project managers, and the control priority/criticality is not “low.”

The control priority is critical.

Executive Steering Committee

Escalation 3: The project leadership will determine when controls need to be escalated to the executive steering committee.

To escalate a control to the Executive Steering Committee, project leadership will:

1. Change the escalation level to 3.

2. Confirm that the control documentation is complete.

3. Present the control, alternatives and recommendation to the steering committee or project sponsor.

Controls will be escalated to the executive steering committee when:

The issue cannot be resolved at lower levels and the priority is not low.

6.5.2 STATUS MEETINGS

Weekly status meetings attended by both CSES and Deloitte project managers, team leads, and PMO staff will be held to report on the overall project status, accomplished and upcoming action items, major project milestones, and any risks and issues that have arisen. An agenda will be established prior to the meeting, and the time allocated to each agenda topic will vary depending on the depth of issues to be covered. Items not able to be covered within the meeting time and accepted to be postponed may be added to the next standing meeting’s agenda or may require a special meeting. Meeting minutes will be taken and published no later than two days prior to the next regularly scheduled meeting. All other project meetings will follow the same agenda, timing, and meeting minute guidelines.

6.5.3 PROJECT STATUS REPORTS

The project status will be tracked and published in the weekly Project Status Report which can be seen in the figure below.

PAGE | 59


6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)The CSES Refactoring project supports all current CSES strategic goals as listed below.

The project will be measured by Deloitte’s timely completion of each Deliverable as defined in the Statement of Work. In accordance with the contract, the Retainage Release will be evaluated by the NM CSES and Deloitte agreement (after successful testing and the 182 calendar days warranty period) that the refactored application installed in NM CSES ’s production Java environment is a fully functional equivalent of the production mainframe COBOL/CA GEN version of CSES.

6.6.1 BASELINES

PROJECT AREA CATEGORY MEASURE

Discovery, Planning, Designing, Testing, Implementation, and Reporting

Schedule Deviation from initial schedule

Migrated Application Asset (Online)


PAGE | 60


Migrated Application Asset (Batch)


Final Acceptance Schedule Deviation from initial schedule

Retainage Release Schedule Deviation from initial schedule

6.6.2 METRICS LIBRARY

This section is N/A to Deloitte.

6.7 QUALITY OBJECTIVES AND CONTROLS6.7.1 QUALITY STANDARDS

Quality standards for all deliverables have been set by the QA checklist found in the Appendix, Section I of this document.

NO. QUALITY STANDARDTRACKING TOOL OR MEASURE

1 Deliverable format, consistency, and grammar • QA Checklist

6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTS

The table below defines the project and product review assessment cycles.

REVIEW TYPEQUALITY STANDARD

TOOLS REVIEWER REPORT

New Project Risk Assessment Engagement Review Framework

Russ Illich/ Paul Gosnell

Quarterly Report

Standard Risk Assessment Engagement Review Framework


Quarterly Report

Maintenance Risk Assessment Engagement Review Framework


Quarterly Report

6.7.3 AGENCY/CUSTOMER SATISFACTION

For a full list of meetings and project communication please refer to section E5 in the Appendix.

AREAS OF FEEDBACK WHEN HOW OFTEN

Agency awareness Status Report Meetings Weekly

PAGE | 61


Quality of communications Status Report Meeting Weekly

Manages project tasks Work Plan Review Meeting Weekly

Productive Meetings Architecture Touchpoint

Testing Check-ins

Weekly

3 times a week

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS

The project deliverable acceptance process is detailed below: . A. Submission. Upon completion of agreed upon Deliverables as set forth in Article 2 of the contract and Exhibit A, Contractor shall submit a Payment Invoice with the Deliverable, or descriptionof the Deliverable, to the HSD. Each Payment Invoice shall be for the fixed Deliverableprice as set forth in Article 2 and Exhibit A, less retainage as set forth in Article 3(D).B. Acceptance. In accord with Section 13-1-158 NMSA 1978, the Executive LevelRepresentative shall determine if the Deliverable provided meets specifications as agreedto in writing by the parties for the Deliverable. No payment shall be made for anyDeliverable until the individual Deliverable that is the subject of the Payment Invoice hasbeen Accepted, in writing, by the Executive Level Representative. In order to Accept theDeliverable, the Executive Level Representative, in conjunction with the ProjectManager, will assess the Quality Assurance level of the Deliverable and determine, at aminimum, that the Deliverable:

1. Complies with the Deliverable requirements as defined in Article 2 and Exhibit A(any noncompliance, labeled as a "defect" for purposes of this Agreement);

2. Meets the performance measures for the Deliverable(s) and this Agreement;3. Meets or exceeds the generally accepted industry standards and procedures for the

Deliverable(s); and4. Complies with all the requirements of this Agreement.

If the Deliverable is deemed Acceptable under Quality Assurance by the Executive LevelRepresentative or their Designated Representative, the Executive Level Representativewill notify the Contractor of Acceptance, in writing, within ten (10) Business Days fromthe date the Executive Level Representative receives the Deliverable(s) andaccompanying Payment Invoice.C. Rejection. Unless the Executive Level Representative gives notice of rejection within theten (10) Business Day Acceptance period, the Deliverable will be deemed to have beenAccepted. If the Deliverable is deemed unacceptable under Quality Assurance, ten (10)Business Days from the date the Executive Level Representative receives theDeliverable( s) and accompanying Payment Invoice, the Executive Level Representativewill send a consolidated set of comments indicating issues, unacceptable items, and/orrequested revisions accompanying the rejection. Upon rejection and receipt ofcomments, the Contractor will have ten (10) Business Days to resubmit the Deliverable tothe Executive Level Representative with all appropriate corrections or modificationsmade and/or addressed. The Executive Level Representative will review the correctionsor modifications made and/or addressed to determine whether the Deliverable(s) isAcceptable under Quality Assurance and provide a written determination within ten (10)Business Days of receipt of the revised or amended Deliverable. If the Deliverable isonce again deemed unacceptable under Quality Assurance and thus rejected, the

PAGE | 62


Contractor will be required to provide a remediation plan that shall include a timeline forcorrective action acceptable to the Executive Level Representative. The Contractor shallalso be subject to all damages and remedies attributable to the late delivery of theDeliverable under the terms of this Agreement and available at law or equity. In theevent that a Deliverable must be resubmitted more than twice for Acceptance, theContractor may be deemed as in breach of this Agreement. The HSD may seek any andall damages and remedies available under the terms of this Agreement and available atlaw or equity. Additionally, the HSD may terminate this Agreement.

DELIVERABLE FINAL APPROVAL PROCESSCUSTOMER ACCEPTANCE CRITERIA

N/A N/A N/A

6.8 CONFIGURATION MANAGEMENT6.8.1 VERSION CONTROL

Bitbucket 6.10 will be used for source code version control, and SharePoint will be used for document version control.

6.8.1.1 Document Versioning ProcessSharePoint will be configured to control document collaboration by allowing users to check out files. If you have a file checked out, you are ensuring that other users will not overwrite it. However, you are also preventing other users from seeing the latest changes or making changes themselves, so it is important that you check your files back in promptly. Please refer to Attachment G for more details related to project document management.

6.8.2 PROJECT REPOSITORY (PROJECT LIBRARY)

Bitbucket 6.10 will be used as the repository for all project code, and SharePoint will be used as the repository for all project documents.

6.9 PROCUREMENT MANAGEMENT PLANNM CSES will be responsible for all procurement activities for the CSES Refactoring (Transformation) Project.

7. 0 PROJECT CLOSE

7.1 ADMINISTRATIVE CLOSEThe administrative closure of the CSES Refactoring (Transformation) Project will conform to CSES and DoIT processes and standards.

7.2 CONTRACT CLOSEPAGE | 63


Contract close will conform to CSES and DoIT processes and standards.

PAGE | 64


ATTACHMENTS

This Attachments section contains information referenced in the Project Management Plan that changes over the life of the project or is different for each project phase. As the project progresses, the Deloitte Project Manager will add additional sub-sections to the appendix to address these needs, thereby isolating the changes from the body main of the Project Management Plan. Additional sub-sections added in this manner do not require an approved change request, although they will be reviewed and approved by the CSES Project Manager.

A. REFACTORING PROJECT METHODOLOGY

This section describes the activities involved in a typical refactoring project. The Refactoring Methodology is based on four main principles:

Unified Target Technology

One-to-One Approach

Automated Migration

Model Driven Development

A description of each as well as an explanation of how they are applied to the CSES Refactoring (Transformation) Project is provided in the sections below.

A.1 Unified Target TechnologyDuring the refactoring process, an Integrated Development Environment (IDE) and Application Lifecycle Management (ALM) tool suite is introduced. This tool suite supports the process to migrate to the target technology and provides modern development capabilities such as code analysis, unit testing, integrated configuration management, build management, and continuous integration.

A.2 One-to-One ApproachA one-to-one approach is the method for refactoring that transfers the structures from one application platform to a new one with the fewest possible changes. Application screens and source code modules are generally moved from the old to the new on a one-to-one basis. When moving from DB2 to Oracle DB, naming conventions and table structures are preserved wherever possible. When moving from COBOL/CAGEN to Java, variable naming conventions and procedural structures of the COBOL/CAGEN programming language is largely preserved as well.

The one-to-one approach reduces the training requirements for end users and developers and allows COBOL developers to continue development of the code after refactoring. The migrated programs have a high recognition value for the COBOL developers and can be maintained and edited more easily than they would be had they been migrated without a one-to-one approach.

A.3 Automated MigrationAn automated migration allows the transformation of source code in a repeatable way using the same schema. Errors during the transformation are fixed centrally in the transformation process. This means that the COBOL/CAGEN source code can be transformed using automation. Data is PAGE | 65


also migrated from mainframe DB2 to Oracle DB. This automated process works by using database backups to create load files for Oracle DB automatically.

The CSES Refactoring (Transformation) Project has opted to employ the “No Code Freeze” refactoring option, which is an optional benefit in a refactoring project that delays the point in time when changes to legacy system code is frozen, thereby accommodating changes to legacy code up until near the time when the migrated CSES is ready for production implementation. Automated migration is one of the methods which enables the “No Code Freeze” option.

A.4 Model Driven Development (MDD)Model Driven Development (MDD) is software engineering approach for software development that emphasizes the use of models in the software development life cycle and supports automation via model execution and code generation techniques. The Deloitte InnoWake suite provides the integration facilities necessary to apply an MDD approach. MDD techniques are used by the team to develop the new user interface and application components that are based on the original application. This tool allows the developer to model the interface and then automatically generate HTML5, JavaScript and CSS3 code to implement the interface.

B. PROJECT WORK PLAN APPROACH

B.1 Master PlanThe project will develop a CSES Refactoring (Transformation) Project Master Plan (a Gantt chart) that reflects the schedule for the phases, major activities, go-lives, and deployments. The CSES Refactoring (Transformation) Project Master Plan will contain key project milestones and summarize the critical path schedule for the project.

B.2 Work PlanDeloitte and the CSES project team will develop a single end-to-end CSES Refactoring (Transformation) Project Work Plan (in MS-Project) during startup. This CSES Refactoring (Transformation) Project Work Plan will adhere to a standard WBS format and contain cross-functional activities, phases, tasks, contractual deliverables, and milestones. Each task will include high-level dependencies, start and end dates, and responsible team and/or resource assignments.

The end-to-end CSES Refactoring (Transformation) Project Work Plan may be refined to include additional detail (including work products and resource assignments) as needed throughout the project. It will be deliverable-based and will guide the day-to-day execution of the project. As tasks are refined and additional details are added, the percent complete estimates for each task will be confirmed; adjustments will be made to the resources or schedule if preliminary estimates are changed.

The CSES Refactoring (Transformation) Project Work Plan will be reviewed by the PMO and the team leads and revised based upon feedback while maintaining the overall signed-off schedule. Once NM CSES has approved the Work Plan, it will be uploaded in SharePoint.

PAGE | 66


B.3 Project Work Plan Management Each week, the current task assignments will be published to the designated responsible individuals, progress will be tracked in the Work Plan, schedule performance will be analyzed, and the Work Plan will be revised (if necessary) to reflect current conditions. The table below highlights each of these steps, the responsible individual for each, and the timing.

Weekly Work Plan Management Process

MANAGE WORK PLAN STEP

DESCRIPTION RESPONSIBLE TIMING

Publish Assignments The tasks scheduled to be performed during the next two weeks are available to the project team.

Deloitte Project Management Office

Live via WebView

Track Progress Planned responsible individuals update progress of assigned tasks. Updates will forecast status as of the end of the work week.

Planned Responsible Individuals

Daily

Team Leads review and QA progress tracking updates.

Team Leads Daily

Analyze Progress and Performance

The integrated progress tracking is reviewed to determine the impact upon the project schedule.

Deloitte Project Manager Weekly

Re-plan Project leadership adjusts the CSES Refactoring (Transformation) Project Work Plan (if necessary) considering changing circumstances.


CSES Project Manager

Team Leads

Weekly

To accomplish the above activities, the following will be performed:

Publish Assignments – the CSES Refactoring (Transformation) Project Work Plan will be synchronized with WebView & Jira tasks.

Track Progress – each planned responsible individual will logon to Jira to update the status of his/her assigned tasks in the CSES Refactoring (Transformation) Project Work Plan:

Update Percent Complete – indicate the percentage of work that is complete for the designated task.

Document Estimated Finish Date (if required) – this field should only be populated if the task being updated is projected to be finished on a date that is after the currently planned finish date.

PAGE | 67


Analyze Performance – the Deloitte Project Manager will review the CSES Refactoring (Transformation) Project Work Plan after the track progress activity is complete. This analysis will consider:

Critical Path

Late/slipping Tasks

Deliverable Completion Rate

Re-plan – the Deloitte Project Manager will incorporate progress tracking updates (including adjusting planned durations of tasks that have a revised estimated finish date). This review will evaluate currently planned vs. baseline dates for milestones to determine if actual progress is impacting critical dates. If issues are identified, the Deloitte Project Manager will revise the phase CSES Refactoring (Transformation) Project Work Plan (e.g., add lag, adjust assignments, augment resources, etc.) to bring the schedule back in line.

The Deloitte Project Manager also needs to adjust the CSES Refactoring (Transformation) Project Work Plan during re-planning to implement any approved change requests for the project received that week.

Upon completion of the re-plan activity, the Deloitte Project Manager will review any work plan changes with the CSES Project Manager. During this review, any concerns or issues about late / slipping tasks will be discussed, and corresponding corrective actions will be identified. The revised CSES Refactoring (Transformation) Project Work Plan will be archived with documentation of NM CSES approval. The CSES Refactoring (Transformation) Project Master Plan will be adjusted, if required, to stay aligned with the CSES Refactoring (Transformation) Project Work Plan.

C. PROJECT DELIVERABLE MANAGEMENT PLAN

A “deliverable” is any work product that is signed-off and put under change control as a unit and is explicitly defined in the Statement of Work (SOW). An “artifact” is a project work product that does not require sign-off but will still be reviewed with appropriate members of the CSES project team to confirm alignment and established as a baseline version. For artifact change control, the appropriate issue and risk management process should be followed first and then escalated as needed through the change control process.

Deliverable Management is a five-step process:

C.1 Define Deliverable ExpectationsA Deliverable Expectation Document (DED) is a template for a deliverable that also contains CSES Refactoring (Transformation) Project defined review and/or acceptance criteria for the deliverable. Each DED will define deliverable contents and organization and be published in Microsoft PowerPoint. Most deliverables will utilize a DED.

The Deloitte project team assigned to the deliverable creates the draft deliverable using the appropriate template. This deliverable development step is not expected to start until the template (and any applicable review criteria) has been signed-off, and the reviewers for the deliverable review(s) have been defined. Hence, timely approval of the DED is key to maintaining deliverable production and project schedule.

PAGE | 68


CSES project team participation in the “Draft Deliverable” step is important. The CSES project team will participate actively in the development of deliverables.

C.2 Review DeliverableOnce drafted, the review planned for the deliverable will be performed. Microsoft Word will be used to collect deliverable comments and the updates required to resolve any defects. In cases where multiple reviewers provide feedback, the Deloitte project team will reconcile and consolidate all feedback into a single Microsoft Word version of the deliverable document(s) showing “Track Changes”. If conflicting comments remain, an issue will be documented and escalated to the Deloitte project manager. Deliverable reviews will be completed in a timely manner, consistent with the durations documented in the table below (deliverable process timing).

Once the planned deliverable reviews are complete and the documented feedback has been adequately addressed, the deliverable is ready to be shared with the appropriate CSES project stakeholder(s) for sign-off.

Project Deliverables RASCI Chart

The following chart lists those who need to be either informed, consulted, in support, accountable, or responsible for a given project deliverable.

R esponsible – to perform the work (may be delegated)

A ccountable – to own the delivery of the work (e.g. approver)

S upport – to help complete the delivery

C onsulted – opinions from SME

I nformed – who is kept up-to-date with progress or completionTask Item Sub

TasksDeliverable HSD

DEV/Tech Lead

HSD Infra. & App/DBA

HSD Architect

HSD Funct. BA/Tester

HSD Test Lead

HSD Project Manager

HSD Project Sponsor

Deloitte PMO Analyst

Deloitte DEV Team

Deloitte Build & Deploy

Deloitte Architect

Deloitte Test Lead

Deloitte Tech Lead /TMO

Deloitte PM

CSES Discovery, Planning, Designing, Testing, Implementation, and Reporting

1.1 Month 1 – 1.18 Month 18

Project Ramp Up and Discovery Documentation

I I I I I C I R I I S S S A

Weekly Project Status Report I I C I S I I S S S A/R

Deliverable Dependency Plan C I R I I I I I A

Work Plan C C I I C R I R I I S S S A

Project Management Plan I I I I I C I R I I I I I A

PAGE | 69


PAGE | 70

Task Item

Sub Tasks

Deliverable HSD DEV/Tech Lead


HSD Architect

HSD Funct. BA/Tester

HSD Test Lead

HSD Project Manager

HSD Project Sponsor


Deloitte DEV Team

Deloitte Build & Deploy

Deloitte Architect

Deloitte Test Lead


Deloitte PM

Deloitte LED

1.1 Month 1 – 1.18 Month 18

Development and Test Core Environments Installation

C R S A S R A A I

Test Plan I S S C I I S I I I R C A I

Future State Architecture (with sizing recommendation)

I C R I I I I C R C C A I

innoWake Enabler:test Training

I I S R S I S I R I A I

CSES Discovery, Planning, Designing, Testing, Implementation and Reporting

Test Report Template I I I C I I S I I R C A I

Training Plan C I I I I C I S I I I S S A/R I

Performance Environment Installation

C R S A S R A A I

SIT Test Environment C R S S S R A A I

User Acceptance Testing (UAT), Pre-Production (as needed) and Production Environments Installation

C R S A S R A A I

Migrated Application Assets (Online)

2.1 Contractor Tools Setup S S I I I S I R A I

2.2

Migrated Application Assets (Online)

C I I I I I S C I A/R A I

2.3Base Unit Tested Application

S S S R I I S S S A R A I

Migrated Application Assets (Batch)

3.1

Migrated Application Assets (Batch)

C I I I I I S C I A/R A I

3.2 Parser Error Remediation C I I I S I A/R A I

3.3Base Unit Tested Application

C S I I I S A I A R A I

Pilot 4.1 Pilot R R C S S A I S S S C S R A I


C.3 Sign-off DeliverableThe CSES CIO and the Project Manager will review the completed deliverable and the documentation supporting the review activities. During the sign-off process, the reviewer may provide additional feedback which will be documented and addressed. The reviewer will sign-off or provide feedback on the deliverable within the time documented in the table in the section below. Upon completion, the reviewer will document deliverable sign-off by completing the Deliverable Sign-off Form located on the project SharePoint site and send to the Deloitte PMO via e-mail. If no feedback is given within the timeline defined in the table below, the deliverable will be considered accepted.


C.4 Deliverable Process TimingDeliverable acceptance will be governed in accordance with Article 4 of the Contract. During the sign-off process, the reviewer may provide additional feedback which will be documented and addressed. The reviewer will sign-off or provide feedback on the deliverable within the time documented in the table in section below. Upon completion, the reviewer will document deliverable sign-off by completing the Deliverable Sign-off Form located on the project SharePoint site and send to the Deloitte PMO via e-mail.

PAGE | 71

Task Item Sub Tasks

Deliverable HSD DEV/Tech

Lead


HSD Architec

t

HSD Funct.

BA/Tester

HSD Test Lead

HSD Project

Manager

HSD Project Sponsor


Deloitte DEV Team

Deloitte Build

& Deploy

Deloitte Architect

Deloitte Test Lead


Deloitte PM

Deloitte LED

Final Acceptance

Final Acceptance

5.1

Optimized/Tested Application & Infrastructure

S S S C I I S S S S R S A I

5.2Developer and Administrator Training

S S C I S C A/R A I

5.3User Acceptance Test Training

I S S C I S I R C A I

5.4 End User Training I S S C I S I R C A I

5.5 Implementation Support R R C S S A I S S S C S R A I

5.6 Go Live Support R S S S S A I S S S C S R A C

5.7Maintenance & Operations Transition Plan

S R C S I I C S S A C R A I

Production Support 6.1 Production

Support S R I I S S R A I

Maintenance and Operations and Ad-Hoc Support

7.1

Application Maintenance and Operations Support

R R C S S A I S S S C S R A I

7.2 Ad-Hoc Support TBD TBD TBD TBD TBD TBD TBD TBD TBD TBD TBD TBD TBD TBD TBD



DELIVERABLE DELIVERABLE REVIEW – SIGN-OFF OR FEEDBACK

DELOITTE ADDRESSES FEEDBACK

ACCEPTANCE OR FEEDBACK

All Sign-off should occur as early as possible, not to exceed ten business days unless agreed upon in advance. If deemed unacceptable, feedback should be given as early as possible, not to exceed ten business days from deliverable submission. If no sign-off or feedback is provided, Deloitte may consider a Deliverable deemed accepted as-is.



D. ACTION ITEM MANAGEMENT

This section documents the process and tools the project will use to log action items and manage them to closure throughout the life of the project. An action item is an assignment to do some work or address a question that can be addressed in less than four hours of effort. The project will use SharePoint to document and manage all project action items throughout the life of the project.

D.1 Process SummaryThe flow-chart below summarizes the project’s action item management process:

PAGE | 72


Figure D.1: Action Item Management Process Flow

D.2 Action Item PrioritiesFollowing are the action item priorities and descriptions:

Critical - the action item must be addressed immediately in order to protect the project’s objectives

High - the action item must be addressed as soon as possible in order to prevent significant negative impacts to the project (for example, cost overruns or milestone delays)

Medium - the action item will be addressed, monitored, and controlled following regular project action item management processes

Low - the action item will be addressed as cost and schedule permits

D.3 Action Item MeetingsThe action item meeting plan described in the table below will address project action items:

Addressed during with the Weekly and Monthly Status meetings, the action item topics below will be added to the appropriate Status Meeting agenda as required:


Meeting Frequency and As part of Weekly and Monthly Status Meetings

PAGE | 73



Schedule

Participants Project managers, team leads, and PMO staff

Attendees needed for a Quorum

3 people, including one CSES Refactoring (Transformation) Project representative

Meeting Agenda Announcements

Review “New” action items

Review any “In Progress” or “On Hold” action items that need attention

Determine if any action items have become project issues

E. PROJECT DECISIONS

Managing decisions includes identifying, documenting, prioritizing, assigning, and tracking the results of decisions throughout the phases of the project. This section documents the process and tools the project will use to log and manage day-to-day decisions as well as formal project decisions. Day-to-day decisions are decisions that project management deems necessary to document and track for future reference. Formal decisions are decisions that require a more structured process for analyzing alternatives for potential solutions. The decision criteria for making a formal decision versus a day-to-day decision must be understood by team members. The project will use SharePoint to document and manage all project decisions throughout the life of the project.

E.1 Process SummaryThe flow-chart below summarizes the project’s decision management process:

PAGE | 74


Figure E.1: Decision Management Process Flow

E.2 Decision PrioritiesFollowing are the recommended decision priorities and descriptions:

Critical - the decision must be addressed immediately in order to protect the project’s objectives

High - the decision must be addressed as soon as possible in order to prevent significant negative impacts to the project (for example, cost overruns or milestone delays)

Medium - the decision will be addressed, monitored, and controlled following regular project decisions management processes

Low - the decision will be addressed as cost and schedule permits

E.3 Day-to-Day Decision-Making ProcessAlthough most project decisions do not require a formal decision process using a detailed qualitative and quantitative analysis of alternatives, important decisions will be logged in SharePoint and managed to closure, similar to risks, issues, and action items.

The objectives of the day-to-day decision-making process include:

Documenting and communicating day-to-day decisions made

PAGE | 75


Confirming that day-to-day decisions are made in a timely manner

Preventing decisions made from being revisited

Day-to-day decisions should be documented in the project’s SharePoint with typically two alternative options to consider for the solution.

E.4 Formal Decision-Making ProcessDecisions that require the formal decision-making process are decisions that may impact project outcomes regarding the solution schedule, cost, or quality. It is critical that formal decisions be made once, by the right level of authority, and in a timely manner.

The formal decision-making process allows the project team to analyze possible critical decisions using a formal evaluation process that evaluates identified alternatives against established criteria. The formal decision process results in a recommended solution and rationale that are provided to key stakeholders for review and approval before it is considered final.

The objectives of the formal decision-making process include:

Making decisions using qualitative and quantitative feedback based on established solution criteria at the appropriate level of authority

Driving timely decision-making

Documenting and communicating formal decisions made

Preventing formal decisions from being revisited

The project should consider using the formal decision process in scenarios where the outcome may significantly impact the ability of the project to meet its commitments or established objectives. High project impact decisions will be made by the ESC. Other decisions can be handled at the team level. The formal decision-making process will be followed for all decisions.

E.5 Project Management Communication Schedule

The following table depicts a calendar view of the communication vehicles described in Section 6.5.1.

# MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY

Week 1

Testing SME Check In

Work Plan Review Meeting

Project Status Meeting


Bi-weekly Architecture and Infrastructure Touchpoint


PAGE | 76


# MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY

Week 2





Technical Review Board/Change Control Board Meeting

Testing SME Check in

Week3







Week 4





Technical Review/Change Control Board Meeting


Week 5







F. PROJECT DOCUMENT MANAGEMENT PLAN

F.1 Document Management Roles and ResponsibilitiesThe table below lists the roles and responsibilities involved in the project’s document management activities.

ROLE RESPONSIBILITY

Deloitte PMO Establishes and maintains the project document management plan

Establishes and manages the project document management system

Coordinates project document management activities

Manages, maintains, and controls project documents

Change Control Board (CCB)

Review, approve, and prioritize change requests to approved deliverables, which frequently includes documents

The project’s CCB is defined in Section 3, Project Organization.

PAGE | 77


F.2 Document Management SystemF.2.1 DOCUMENT MANAGEMENT TOOL

The CSES Refactoring (Transformation) Project will use SharePoint for managing documents. This tool will be administered by the Deloitte PMO and accessible to the project team. The document repository will retain version history of all documents automatically for archival purposes.

F.2.2 DIRECTORY STRUCTURE

The CSES Refactoring (Transformation) Project document repository will contain the following folders initially. Additional folders and sub-folders will be created as appropriate to support document management needs of the project team.

FOLDER / PAGE DESCRIPTION

Project Home Page Provides navigation to folder structure. Also includes the project calendar, team announcements, and team contact list.

Executive Steering Committee

Dedicated site used to support ESC related communications

Contract & Deliverables

Used to store final versions of contracts, work products and signed-off deliverables under change control, and IV&V report. Only authorized users will have write access to this library.

Team Working Folders

Used to store specific project team information and/or draft work products

Project Mgt. Used to store meeting minutes and other items related to project management

Risk Used to store any project risks identified

Team Contact List Used to store contact information for both the Deloitte and CSES project teams

Project Team Calendar

Project team calendar to post PTO and trainings

Project Calendar Standard project calendar to post relevant project events by date

Team Discussion Provides a forum for project team members to discuss important topics together and share knowledge

The screenshot below is the Project Home Page, which provides navigation to other folders.

PAGE | 78


Figure F.2.2: CSES SharePoint Home Page

F.2.3 DOCUMENT NAMING CONVENTIONS

The following table describes the document naming conventions to be followed for the CSES Refactoring (Transformation) Project. Software naming conventions are not included here. The red text indicates the portion of the filename that requires input.

TYPE OF DOCUMENT

NAMING CONVENTION

Deliverables DELX.X_Deliverable Name_VX.X.file extension

Drafts DELX.X_Deliverable Name_V0.X.file extension

Artifacts Artifact Name_Artifact_VX.X.file extension

F.2.5 DOCUMENT MANAGEMENT PROCESS

F.2.5.1 Pre-Sign-off (deliverables) or finalization (work products)

Documents that are in development will be managed by individual team members under the guidance of their team leads. These documents will be stored in the appropriate section of the SharePoint site. All team members will have access to their documents in SharePoint.

F.2.5.2 Post-Sign-off

As documents are finalized, they will be reviewed and, if the document is a deliverable or part of a deliverable, signed-off. The final version of documents will be archived in SharePoint by PMO staff. The PMO will manage the deliverable sign-off process and will archive documents that are part of a deliverable. It is the responsibility of the Team Leads to communicate the document name and version of work products (no formal sign-off) that are final to the PMO so that those documents can also be archived.

PAGE | 79


Once an approved document is archived in SharePoint, it will not be updated without an approved change request. The Team Leads will notify the PMO when change requests requiring document updates are approved so that the approved change can be implemented. This is being managed by JIRA.

F.2.6 DOCUMENT MANAGEMENT TOOL ADMINISTRATION

F.2.6.1 Team Member Access

The CSES Refactoring (Transformation) Project onboarding document provides information on how to access the SharePoint site.

F.2.6.2 Backup and Recovery

The SharePoint site is maintained by Deloitte Consulting and has scheduled backups and maintenance windows.

F.2.6.3 End of Project Archival

Deloitte will work with the CSES Project Manager to define the End of Project Archival process as part of transition activities in project closeout.

G. PROJECT TOOLS PLAN

The table below summarizes the tools that will be used to support the successful planning, execution, monitor and control, and delivery of the project.

# PROJECT AREA SELECTED TOOL(S) RESPONSIBILITY

1 CSES System Features Capture Microsoft Excel, Microsoft SharePoint

NM CSES is responsible for procuring licenses and installation and configuration of the CSES solution

Deloitte is responsible for installation and configuration of the InnoWake tools in non-production environments

2 Work Planning Microsoft Project

3 Project Management Information System for Project Controls (e.g., risks, issues, action items, decisions, change requests, deliverable reviews)

Microsoft SharePoint

Jira

4 Document Management Microsoft SharePoint

5 Code Management Bitbucket

6 Data Management Oracle DB

7 Testing Management/Automation

XRay, innoWake Enabler, Jenkins

8 Stress Testing Load Runner or JMeter

PAGE | 80


# PROJECT AREA SELECTED TOOL(S) RESPONSIBILITY

9 Development Tools innoWake Enterprise Suite, Java JRE, Legacy DevOps - Development, Maven

10 Build and Deploy Management Jenkins, Nexus

11 Batch Scheduling OpCon

12 Identity and Access Management

Active Directory

13 Web Server, Application server HTTPD, Apache Tomcat

H. DELIVERABLE CROSS-WALK TO SOW

The deliverable cross-walk compares the SOW requirements to the specific sections of the deliverable that meet the specified SOW requirements.

SOW DESCRIPTION DELIVERABLE CONTENT MAPPING

Project Management Approach

• Section 4 – Project Deliverables and Methodology

• Section 5 – Project Work

• Section 6 – Project Management and Controls

• Section 7 – Project Close

Communication Plan • Section 6 – Project Management and Controls

Program Functional Overview

• Section 1 – Project Overview

• Section 2 – Project Authority and Organizational Structure

• Section 3 - Scope

Risk and Issue Management • Section 6 – Project Management and Controls

Escalation Paths • Section 2 – Project Authority and Organizational Structure

Change Management Process • Section 6 – Project Management and Controls

I. DELIVERABLE QA CHECKLIST

Deliverable Checklist Deliverable Name:

Deliverable Author

Peer Review

Workstream Lead

QA

Title Page

PAGE | 81



Deliverable Author

Peer Review

Workstream Lead

QA

Confirm the deliverable title is correct by reviewing the naming conventions in the SOW o See section 1.1.1

Confirm document title is displayed as deliverable title followed by project title underneatho See title of this document for reference

Ensure title is centred

Ensure the latest NM CSES logo is included and in the correct position

Confirm there is no header/footer

Document Control Information

Document Information

o Document Identification: Confirm the deliverable name ties to the SOW

o Project Name: Child Support Enforcement Systen (CSES) Refactoring Project

o Client: New Mexico Human Services Department

o Document Author: ‘Your name’ or ‘Deloitte’ if multiple authors

o Document Version: Confirm this is updated per the submission

o See section 1.1.4

o Document Status: Confirm this is updated per the submission

o See section 1.1.5

o Date Released: Confirm the date reflects the submission, resubmission, or final submission date in the WP

o Date format follows: mm/dd/yyyy

Document Edit History

o Version: Version should match the document versioning in document information section. Do not document multiple internal drafts.

o See section 1.1.4

o Date: Date should match the date released in the document information section.


o Additions/modification is the “document status” NOT an internal log of modifications

PAGE | 82



Deliverable Author

Peer Review

Workstream Lead

QA

o See section 1.1.5.

o Prepared/Revised by: ‘Your name’ or ‘Deloitte’ if multiple authors

Document Review/Approval History

o Date should match the date released in the document information section


o Name: Russ Illich/Paul Gosnell

o Organization/Title: Child Support Enforcement System (CSES) Refactoring Project project manager

Distribution of Final Document

o Name: Russ Illich/Paul Gosnell

o Organization/Title: Child Support Enforcement System (CSES) Refactoring Project project manager

Header

o Left header: Deloitte Logo (new branding, white background)

o Center header: Child Support Enforcement Systen (CSES) Refactoring Project and the Title of Document

o Right header: latest NM CSES Logo

Footer

o Left footer: The Section Name and Date (mm/dd/yyyy)

o Center footer: The Page Number (Page 1 of 2)

o Right footer: The Filename Confirm file path is correct. See section 1.1.2

Table of Contents

Update Table of Contents

Ensure page numbers are accurate

Header (same as document control info header)

Footer (same as document control info footer)

PAGE | 83



Deliverable Author

Peer Review

Workstream Lead

QA

Deliverable

Introduction section includes: o 1.1 Purposeo 1.2 Goalso 1.3 Scope

Reference: Title of Reference ties to the SOW/project naming conventions Type of Document, e.g., deliverable, artifact, or DED is displayed

Location: The URL to where the document is located is accurate

Confirm links work Confirm links navigate to the correct location

Header is correct on ALL pages (matches previous headers)

Footer (correct on ALL pages (matches previous footers)

Naming Conventions

o Child Support Enforcement System (CSES) Refactoring Project usage is accurate

o Child Support Enforcement System (CSES) Refactoring Project roles are accurate

o Software Naming Conventions are accurate

Grammar/Spelling

o Spelling and Grammar Check ran (check all graphics as well)

o Acronyms usage is accurate on all pages

o Number usage is accurate on all pages

o e.g. and i.e. usage is accurate on all pages

o Commas before “And” and within “dates” is accurate on all pages

o Sentence spacing is accurate on all pages

o Consistent use of capitalization

Formatting

o The correct styles are being used on all pages

PAGE | 84



Deliverable Author

Peer Review

Workstream Lead

QA

o Privacy Page deleted

o Heading/Subheadings are in hierarchal order on all pages

o Page numbers are accurate throughout document

o Bullet formatting/usage is accurate on all pages

o Number list formatting/usage is accurate on all pages

o Table formatting is accurate on all pages

o Figure titles are accurate on all pages

o Title page formatting

o TOC updated

Figures:o Numbered correctlyo Description providedo Figure is on the same page as descriptiono Figure title includedo Font style is correct

Validate key stats/metrics are consistent

Review by at least one non-author team member

Complete and submit checklist to Yihong for every formal deliverable

Deliverable Sign-off Document has been filled out appropriately and submitted with document

J. GLOSSARY

A glossary of terms.

TERM DESCRIPTION

Batch Manage and run JCL scripts on Unix/Linux/Windows.

Bitbucket Code repository and version controlling tool.

Deloitte Enterprise Value Delivery for Systems Integration (EVD)

Method provides a collection of deliverable templates, guidelines, and accelerators that support multiple delivery lifecycles, promoting consistency, quality, and value to clients.

Transformation Enabler A runtime tool emulating the behaviour of the

PAGE | 85


TERM DESCRIPTION

COBOL runtime environment.

Legacy DevOps - Development The development environment that combines the features of legacy programming with modern development in Java.

MS Project Project Management tool; assign tasks, track progress and analyse workloads.

SharePoint The NM CSES ONGARD Refactoring Project will use SharePoint for managing documents. This tool will be administered by the Deloitte PMO and accessible to the project team. The document repository will retain version history of all documents automatically for archival purposes.

Jira XRay Test Management tool; bug reporting and tracking.

Jenkins Build and Deployment tool that also helps with automation.

Nexus Maintain and manage the build/deployment artifacts.

Oracle DB The target database for the CSES application.

innoWake Enabler - Test Testing tooling allowing for use case recording and documentation.

UtraCompare Third Party GUI tool for file comparisons

PAGE | 86


PAGE | 1

Date post:	15-Sep-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times