Executive Sponsor – Ned Fuller, ACTING GSD Cabinet Director · Web view2019-06-12 · General Services Department. Risk Management Information System Replacement Project. PROJECT

GENERAL SERVICES DEPARTMENT

RISK MANAGEMENT INFORMATION SYSTEM REPLACEMENT PROJECT

PROJECT MANAGEMENT PLAN

EXECUTIVE SPONSOR – NED FULLER, ACTING GSD CABINET DIRECTOR

BUSINESS OWNER – LARA WHITE-DAVIS, GSD/RMD DIRECTOR

PROJECT DIRECTOR – KAREN BALTZLEY, GSD CIO

PROJECT MANAGER – JOHN SALAZAR, CSW ENTERPRISES, LLC

ORIGINAL PLAN DATE: AUGUST 16, 2018VERSION: 1.0

PROJECT MANAGEMENT PLAN FOR RMIS REPLACEMENT PROJECT

Table of Contents

REVISION HISTORY............................................................................................................................................. III

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

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT....................................................................................................11.2 FUNDING AND SOURCES...........................................................................................................................................21.3 CONSTRAINTS........................................................................................................................................................41.4 DEPENDENCIES.......................................................................................................................................................41.5 ASUMPTIONS........................................................................................................................................................51.6 INITIAL PROJECT RISKS IDENTIFIED...........................................................................................................................5

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE.............................................................................7

2.1 STAKEHOLDERS......................................................................................................................................................72.2 PROJECT GOVERNANCE STRUCTURE...........................................................................................................................9

2.2.1 Describe the organizational structure – Org Chart....................................................................................92.2.2 Describe the role and members of the project steering committee.........................................................102.2.3 Organizational Boundaries, interfaces and responsibilities.....................................................................10

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

3.0 SCOPE......................................................................................................................................................... 11

3.1 PROJECT OBJECTIVES............................................................................................................................................113.1.1 Business Objectives.................................................................................................................................113.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..........................................................................................................144.1.2 Deliverable Approval Authority Designations..........................................................................................184.1.3 Deliverable Acceptance Procedure..........................................................................................................19

4.2 PRODUCT LIFE CYCLE.......................................................................................................................................204.2.1 Technical Strategy...................................................................................................................................214.2.2 Product and Product Development Deliverables.....................................................................................224.2.3 Deliverable Approval Authority Designations..........................................................................................254.2.4 Deliverable Acceptance Procedure..........................................................................................................25

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

5.1 WORK BREAKDOWN STRUCTURE (WBS)..................................................................................................................265.2 SCHEDULE ALLOCATION -PROJECT TIMELINE..............................................................................................................305.3 PROJECT BUDGET.................................................................................................................................................31

Major Project Deliverable and Performance Measure.....................................................................................31Budget..............................................................................................................................................................31Due Date..........................................................................................................................................................31Project Phase on...............................................................................................................................................31

5.4 PROJECT TEAM....................................................................................................................................................335.4.1 Project Team Organizational Structure...................................................................................................335.4.2 Project Team Roles and Responsibilities..................................................................................................33

5.5 STAFF PLANNING AND RESOURCE ACQUISITION................................................................................................355.5.1 Project Staff.............................................................................................................................................355.5.2 Non-Personnel resources.........................................................................................................................36

5.6 PROJECT LOGISTICS.........................................................................................................................................36

REVISION: 0.3 i OF vi


5.6.1 Project Team Training.............................................................................................................................37

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

6.1 RISK AND ISSUE MANAGEMENT..............................................................................................................................386.1.1 Risk Management Strategy.....................................................................................................................396.1.2 Project Risk Identification........................................................................................................................396.1.3 Project Risk Mitigation Approach............................................................................................................396.1.4 Risk Reporting and Escalation Strategy...................................................................................................406.1.5 Project Risk Tracking Approach...............................................................................................................406.1.6 Issue Management..................................................................................................................................40

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V...........................................................................................416.3 SCOPE MANAGEMENT PLAN..................................................................................................................................42

6.3.1 Change Control........................................................................................................................................426.4 PROJECT BUDGET MANAGEMENT............................................................................................................................42

6.4.1 Budget Tracking......................................................................................................................................436.5 COMMUNICATION PLAN........................................................................................................................................44

6.5.1 Communication Matrix............................................................................................................................446.5.2 Status Meetings.......................................................................................................................................456.5.3 Project Status Reports.............................................................................................................................46

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS).....................................................................................466.6.1 Baselines.................................................................................................................................................466.6.2 Metrics Library........................................................................................................................................47

6.7 QUALITY OBJECTIVES AND CONTROL..............................................................................................................476.7.1 quality Standards....................................................................................................................................476.7.2 Project and Product Review AND ASSESSMENTS.....................................................................................486.7.3 Agency/Customer Satisfaction................................................................................................................486.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS......................................................................................496.7.5 DELIVERABLE ACCEPTANCE Procedures...................................................................................................49

6.8 CONFIGURATION MANAGEMENT...................................................................................................................516.8.1 Version Control........................................................................................................................................516.8.2 Project Repository (Project Library).........................................................................................................51

6.9 PROCUREMENT MANAGEMENT PLAN............................................................................................................51

7. 0 PROJECT CLOSE........................................................................................................................................... 52

7.1 Administrative Close...................................................................................................................................527.2 Contract Close............................................................................................................................................52

ATTACHMENTS................................................................................................................................................. 53

APPENDIX A - ACRONYMS AND DEFINITIONS.....................................................................................................54

APPENDIX B – DELIVERABLE ACCEPTANCE FORM...............................................................................................63

DELIVERABLE ACCEPTANCE FORM..................................................................................................................................63

APPENDIX C – DELIVERABLE ACCEPTANCE LOG..................................................................................................64

DELIVERABLE ACCEPTANCE LOG....................................................................................................................................64

APPENDIX D – PROJECT SCHEDULE.................................................................................................................... 65

APPENDIX E – PROJECT BUDGET........................................................................................................................ 67

REVISION: 0.3 ii OF vi


REVISION HISTORY

REVISION NUMBER DATE COMMENT

1.0 August 16, 2018 Version 1 – Document approved by DoIT

REVISION: 0.3 iii OF vi

1.0 PROJECT OVERVIEW

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT The General Services Department (GSD) Risk Management Division (RMD) was created to protect and conserve the state's human and physical resources and financial assets. RMD provides multi-line insurance coverage, employee health benefits programs, loss prevention and control initiatives, dispute prevention and resolution services, and legal defense for the State of New Mexico. RMD acts as a self-insured carrier providing property and casualty, disability, workers’ compensation and life insurance coverage for 153 state agencies and multiple local public bodies, encompassing coverage for approximately 24,000 employees. RMD also provides legal defense for state employees from tort claims filed against them while performing job duties associated with their employment with the State.

Since 2001, RMD has used the Risk Management Information System (RMIS) to manage and process claims. In 2010, the RMIS product received an upgrade to a .NET framework; however, the underlying architecture is based on an aged Visual Basic (6) technology. Over the years, software modifications to the RMIS enhanced functionality required to accommodate changes in business requirements, but those efforts resulted in a system that is difficult to maintain and is beginning to cause data integrity issues.

Business Need:

The General Services Department is undertaking the Risk Management Information System (RMIS) Replacement Project to replace a legacy system designed and built over twenty years ago with the software not currently providing full software functionality required by the Risk Management Division (RMD). Over the years, RMD has developed many manual workarounds to address lacking system functionality with the manual processes adding complexity to the RMD operation. The existing system includes a proprietary designed owned and maintained by American Technical Services, Inc. Historically, GSD has obtained software maintenance using a sole-source procurement process.

Project Objective: Implement a Commercial Off-the-shelf (COTS) RMIS product that will improve the

agency’s data collection process leading to improvements in claims processing times; Increase staff productivity by implementing a software solution that provides self-service

portal facilities where constituents can enter claims and where data entry validations occur immediately to eliminate bad data and exception processing by RMD staff members

Improve data analysis and management decision making processes by reducing the time required to develop system reports by implementing a software product designed and formatted with existing reports that will allow RMD personnel to filter, sort and extract information for further analysis;

PAGE | 1

Incorporate claims best practices by implementing a proven software product designed and built utilizing industry best practices for claims processing.

Planned Technical and Procurement Approach:

The GSD strategy for procuring a replacement product is to develop a Request for Proposal which will be used to document the business and technical requirements required to support the operation of the Risk Management Division. GSD intends to leverage the existing computing infrastructure currently owned and operated by GSD to host the new software product.

1.2 FUNDING AND SOURCES

SOURCE AMOUNT ASSOCIATED RESTRICTIONS

APPROVERS

Laws of 2014, Chapter 63, Section 7, Subsection 7

$1,500,000.00 Senate Bill 314 - To purchase and implement a risk management information system.

Department of Finance and Administration (DFA), and Legislative Finance Committee (LFC)


House Bill 2 Extend period of time to expend $1,500,000.00 through FY2017

DFA and LFC


($1,250,000.00) House Bill 2 - Extend period of time to expend $250,000.00 of the $1,500,000.00 through FY18

DFA and LFC


House Bill 2 - Extend period of time to expend $250,000.00 of the $1,500,000.00 through FY19

DFA and LFC

Other – RMD Operating Budget (Enterprise Funds): Property - Fund 35603, Liability-

$230,948.00 DFA and LFC

PAGE | 2

SOURCE AMOUNT ASSOCIATED RESTRICTIONS

APPROVERS

Fund 35703 and Workers’ Compensation Fund 35903

Total $480.948.00

Note: In order to address project budget requirements, GSD will submit a FY20 C2 funding request, in the amount of $1,019,052.00. The FY20 C2 request will support the cost associated with the Implementation and Close phases of the project.

PAGE | 3

1.3 CONSTRAINTS

NUMBER DESCRIPTION

1 The new RMIS system must be placed in production on or before July 1, 2020. In Fiscal Year 21, the GSD budget request will eliminate on-going software maintenance budget for the legacy RMIS product.

2 In most cases, customization of the replacement RMIS product will be avoided by changing RMD processes to correlate with software functionality provided by the replacement product. In instances where the replacement software does not address NM specific requirements, work-rounds, either automated or manual will be implemented. .

1.4 DEPENDENCIES Mandatory dependencies are dependencies that are inherent to the work being done. D- Discretionary dependencies are dependencies defined by the project management team. This may also

encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.

E-External dependencies are dependencies that involve a relationship between project activities and non-project activities such as purchasing/procurement

NUMBER

DESCRIPTION TYPE M,D,E

1. In a recent Risk Management industry publication where risk management software COTS products are rated and reviewed on software functionality and time required to deploy products, the publication identified complex deployment timeframes averaged between 9-12 months. Based on anticipated software deployments timeframes, the RFP for the acquisition and installation of the replacement RMIS product must be completed and awarded by June 30, 2019.

M, E

2. Selecting a COTS solution and implementation vendor are dependent on the availability of GSD personnel for evaluating the RFP proposals, and meeting schedule timeframes for completing contract award tasks by GSD State Purchasing, DoIT and DFA.

M,E

3. In order to address project budget requirements, GSD will submit a FY20 C2 funding request, in the amount of $1,019,052.00. The FY20 C2 request will support the cost associated with the Implementation and Closeout phases of the project.

E

PAGE | 4

1.5 ASUMPTIONS

NUMBER DESCRIPTION

1. Procurement vehicle is available to obtain professional services from the risk management consultants.

2. Existing GSD computing infrastructure will support modernized solution.3. With the change in the administration anticipated in January 2019, the new

administration will continue to support the RMIS Replacement Project.

1.6 INITIAL PROJECT RISKS IDENTIFIED

Risk 1 – Change in Administration

Description -

With a change in exempt personnel from the GSD Office of the Secretary and the RMD in January 2019, the new management team may delay the project for a short period of time to determine if the project is viable and if modernizing the software is a high priority.

Probability - HIGH Impact - HIGH

Mitigation Strategy –During the transition period, ensure the existing management team meets with the new management team to get agreement on proceeding with procuring a new product. The existing management team will place emphasis on the importance of replacing a proprietary, end-of-life legacy product that has limited software functionality, data integrity issues. Additionally, the current product will not be eligible for on-going maintenance support beyond September 2020. Contingency Plan - If the project is delayed by the new Administration, the Agency will continue to utilize the existing legacy RMIS product.

PAGE | 5

Risk 2 – Legacy Data Migration

Description -

Due to the design of the legacy database and the known data integrity issues, data conversion and migration tasks may require extended timeframes.

Probability - HIGH Impact - HIGH

Mitigation Strategy –GSD intends to have American Technical Services, Inc.(ATS), the current RMIS vendor, develop reports from the legacy database to identify data anomalies. With the identification of data anomalies completed, GSD RMD staff members will correct data through the use of the ATS application or ATS will develop scripts to perform automated data clean up.Contingency Plan – If during the development of the data migration plan it is determined that data conversion cannot be accomplished by the schedule target date, the project team and implementation vendor will identify, prioritize and migrate data elements required to initialize the replacement system with information to service constituents. These events may impact the schedule and will require the project teams to seek schedule slack opportunities in other areas.

PAGE | 6

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE

2.1 STAKEHOLDERS

NAME STAKE IN PROJECT ORGANIZATION TITLE

Ned Fuller Executive Sponsor, Member of the Executive Steering Committee

GSD Acting Cabinet Secretary

Lara White-Davis Project Sponsor, Business Owner,Member of the Executive Steering Committee

GSD/RMD Division Director

Karen Baltzley Project Director,Chief Information OfficerMember of the Executive Steering Committee

GSD Chief Information Officer

Michael Bebeau Business Owner, Member of the Executive Steering Committee

GSD/RMD Legal

Rod Crawley Business Process Design - Property & CasualtyBusiness Subject-Matter-Expert

RMD Bureau Chief

Markita Sanchez Business Process Design – Finance /Accounts PayableBusiness Subject-Matter-Expert

Finance Bureau Bureau Chief

Brian Walker Business Process Design – Business Administration and ReportingBusiness Subject-Matter-Expert

GSD/RMD Business Administrator

Ida Spence Business Process Design – Workers’ Compensation/Claims Management/OversightBusiness Subject-Matter-Expert

GSD/RMD Workers’ Compensation Bureau

TBD SHARE Database Support/Cash Remediation Software Functionality Functional/Technical

DoIT DBA /Application Developer

PAGE | 7

NAME STAKE IN PROJECT ORGANIZATION TITLE

Flaviano Prosperini

Application/Database SupportFunctional/Technical

GSD/Technology Systems and Support Bureau (TSSB)

Application Developer III

Maurice Bonal Security, Server and Network Support Technical

GSD/TSSB Systems Administration

RMD Staff Members

Use the RMIS system to perform their job duties.

GSD/RMD Various

RMIS Constituents

Use the system to submit claims and to monitor the status of their claims.

154 state agencies and local bodies

Various

PAGE | 8

2.2 PROJECT GOVERNANCE STRUCTURE2.2.1 DESCRIBE THE ORGANIZATIONAL STRUCTURE – ORG CHART

PAGE | 9

2.2.2 DESCRIBE THE ROLE AND MEMBERS OF THE PROJECT STEERING COMMITTEE

The Executive Sponsor operates as the Chair for the Project Steering Committee. As such, the Chair is the point person for the project within GSD.

Responsibilities include:

Championing the project;

Considering potential changes facing the organization and assesses the organizational impact;

Deciding which changes will be instituted, communicates priorities and provides resources to ensure success;

Creating an environment that enables changes to be made on time and within budget;

Participating in planning sessions; and

Chairing the Steering Committee.

The Steering Committee provides governance over the direction and support of the project.

The responsibilities of the Steering Committee Members include:

Attending and participating in Steering Committee Meetings;

Reviewing and providing comment on presented documentation;

Balancing larger picture versus details of the project;

Reviewing project funding and expenditures;

Championing the project; and

Contributing to lessons learned.

Steering Committee membership is included in the Project Organizational Chart depicted on the previous page of this document

2.2.3 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES

The key interfaces between the organizations involved in and supporting the RMIS Replacement Project are those between the GSD CIO, the RMIS Replacement Project Manager, and the RMIS Replacement Project Owner.

The methods of communications utilized on the project will include:

Status Reports, Talking Points Memos, and Briefings;

Standing Team or Committee Meetings;

Ad-hoc meetings;

Electronic mail;

Distribution of Meeting Minutes; and

Phone conversations.

PAGE | 10

Interaction may occur directly between the technical components of all teams. Final decisions will be made at the Steering Committee level as required. Project communications and plans will be fully detailed in the RMIS Replacement Project Communications Plan,

2.3 EXECUTIVE REPORTINGThe RMIS Project Manager will ensure regular and timely communications with the Executive Steering Committee.

Steering Committee Meetings once a month or as directed to review project status, schedule, budget, risks/issues, and action items;

The RMIS Replacement Project Manager will meet with the Executive Sponsor, Business Owner, and Project Director to discuss any issue that represents a significant impediment to progress.

The Project Manager will submit an agency-approved Project Status Report to DoIT and GSD on a monthly basis.

3.0 SCOPE

3.1 PROJECT OBJECTIVES3.1.1 BUSINESS OBJECTIVES

NUMBER DESCRIPTION

BUSINESS OBJECTIVE 1 Implement a COTS RMIS product that will improve the agency’s data collection process leading to improvements in claims processing times.

BUSINESS OBJECTIVE 2 Increase staff productivity by implementing a software solution that provides self-service portal facilities where constituents can enter claims and where data entry validations occur immediately to eliminate bad data and exception processing by RMD staff members

BUSINESS OBJECTIVE 3 Improve data analysis and management decision making processes by reducing the time required to develop system reports by implementing a software product designed and formatted with existing reports that will allow RMD personnel to filter, sort and extract information for further analysis.

BUSINESS OBJECTIVE 4 Incorporate claims best practices by implementing a proven software product designed and built utilizing industry best practices for claims processing

PAGE | 11

3.1.2 TECHNICAL OBJECTIVES

NUMBER DESCRIPTION

TECHNICAL OBJECTIVE 1

Replace a legacy application that does not adequately provide the software functionality required to meet NM statutory, programmatic and/or technical needs with a system incorporating industry best-practices.


In order to reduce project costs and to take advantage of GSD financial investment of GSD IT systems infrastructure and the technical experience and training of GSD TSSB staff members, the proposed solution should reside on the existing GSD computing infrastructure.


Increase system security by implementing a system capable of authenticating users by the use of the agency’s active directory structure.

3.2 PROJECT EXCLUSIONSThe project excludes any upgrades to the agency’s FileNet Electronic Content Management (ECM) suite required to deal with the agency’s record retention schedules for electronic records generated by the new RMIS software.

3.3 CRITICAL SUCCESS FACTORS

NUMBER DESCRIPTION

QUALITY METRIC 1 Reduce the average number of days required to process a claim by 20 percent by implementing improved data entry validation routines and work flow processing facilities.

QUALITY METRIC 2 For the first two months of operations using the replacement software, 25 percent of claims filed at RMD will be through the use of a self-service claims portal. By the seventh month of operation, 90 percent of claims will be filed by the self-service portal.

QUALITY METRIC 3 Decrease the volume of cancelled warrants by 50 percent.

PAGE | 12

4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE

Phase Summary of Phase Key Deliverables

Initiation Define the scope, schedule, and budget for performance, including business benefits to be achieved.

PCC Initiation Phase Certification Request and associated Presentation

Draft Project Charter

Planning Develop the strategy for delivering on the goals and objectives of the project and all key planning documents.

Identify key project team members and form Project Team.

Develop Work Breakdown Structure, estimation of costs and time, identify resources and manpower.

PCC Planning Phase Certification Request and associated Presentation

Final Project Charter

Project Management Plan

IV&V Professional Services Contract

Implementation Execute the project using the methodology established and documented in the Project Management Plan to monitor and control the project.

TARC Documentation and TARC review

TARC approval

PCC Implementation Phase Certification Request and associated Presentation

IV&V Reports

Updated Project Management Plan

Closeout Project comes to a close, with product and services ready for use.

Contracts are terminated, and project teams dissolved.

All invoices are paid.

Lessons Learned Report

PCC Closeout Phase Certification Request and associated

PAGE | 13


Presentation

PCC Closeout Presentation

IV&V Final Report

4.1.1 PROJECT MANAGEMENT DELIVERABLES

4.1.1.1 RMIS-DEL-001 - Project Charter Description – The project charter is the document that formally authorizes a project. The project charter provides the project manager with the authority to apply organizational resources to project activities.

Deliverable Acceptance Criteria – Must meet acceptance of the Executive Sponsor and the Project Certification Committee (PCC).

Standards for Content and Format –DoIT template.Quality Review – Reviewed and approved by GSD CIO.

4.1.1.2 RMIS-DEL-002 - Project Management Plan

Description – The Project Management Plan (PMP) is a formal document approved by the Executive Sponsor, the GSD

Deliverable Acceptance Criteria – All areas of the PMP completed with sufficient levels of detail to convey complete understanding of the effort to stakeholders

Standards for Content and Format –DoIT template.

PAGE | 14

CIO and DoIT. The PMP is developed during the Plan Phase of the project, and is utilized to manage project execution, control, and project close.

The primary uses of the PMP are to document planning assumptions and decisions, facilitate communication among stakeholders, and to document the approved scope, cost and schedule. The PMP includes and/or integrates by reference other related plans for issue escalation, change control, communications, deliverable review and acceptance, risk management, environment management, business continuity, testing, training and operational support plans

Quality Review – Reviewed and approved by GSD CIO

4.1.1.3 4.1.1.4 RMIS -DEL-003 - Certification Request Forms and Presentations

Description – Forms and presentations tailored to provide specific information to the Project Certification Committee as the project progress through the Initiation, Planning, Implementation or Closeout phases.

Deliverable Acceptance Criteria – Must obtain acceptance of the PCC.

Standards for Content and Format –DoIT templates for requests.Quality Review – Reviewed and approved by GSD CIO and RMIS Business Owner.

4.1.1.5 RMIS -DEL-004 - IV&V Contract & Reports

Description – IV&V Contract and associated reports on project status.

Deliverable Acceptance Criteria – Must meet acceptance of the Executive Steering Committee and DoIT.

Standards for Content and Format –DoIT template.Quality Review – Reviewed and approved by GSD CIO and RMIS Business Owner.

PAGE | 15

4.1.1.6 RMIS -DEL-005 - Business Analysis IT Professional Services Contract

Description – Business Analysis Contract to define the Risk Management Division’s “As-Is” Business and Technical Requirements

Deliverable Acceptance Criteria – Contains sufficient detail to completely define terms and conditions, scopes of work, deliverables, quality review and acceptance criteria, maximum hours and cost at a deliverable level, due dates and other necessary details relevant to the scope of work being performed

Standards for Content and Format – Compliant with DoIT and SPD guidelines and statutesQuality Review – Quality Review – 1st Review: RMIS Business Owner and GSD CIO2nd Level Review: DoIT, and GSD General Counsel

4.1.1.7 RMIS -DEL-006 - Risk Management Consultants IT Professional Services Contracts

Description – Risk Management Consultants Contract to define the Risk Management Division’s “To-Be” Business and Technical Requirements and to develop the RMIS Request for Proposal (RFP)

Deliverable Acceptance Criteria – Contains sufficient detail to completely define terms and conditions, scopes of work, deliverables, quality review and acceptance criteria, maximum hours and cost at a deliverable level, due dates and other necessary details relevant to the scope of work being performed

Standards for Content and Format – Compliant with DoIT and SPD guidelines and statutesQuality Review – Quality Review – 1st Review: RMIS Business Owner and GSD CIO2nd Level Review: DoIT, and GSD General Counsel

4.1.1.8 RMIS -DEL-007 - Monthly Project Status Reports to DoIT

Description – For all projects that require Department oversight, the lead agency project manager shall submit an agency approved project status report on a monthly basis to DoIT.

Deliverable Acceptance Criteria: All areas of the Project Status Report Form completed with sufficient levels of detail to convey complete understanding of project status to governance

Standards for Content and Format: Completed to DoIT StandardsQuality Review – Reviewed and approved by GSD CIO

4.1.1.9 RMIS -DEL-008 - Project Schedule

Description – Schedule is the key project management tool by

Deliverable Acceptance Criteria: All Project Tasks, Milestones, and Deliverables detailed, with durations, predecessors, and resources entered.

PAGE | 16

which the Project will be managed. The Project Schedule contains all project key tasks, activities and milestones. Tasks and activities are defined with durations and deliverables, predecessor tasks, and the deliverable(s) associated with that task where they exist.The Project Schedule also contains an accurate calendar reflecting state holidays and other non-productive time periods, such as the week between Christmas and New Year’s Day

Standards for Content for the Project Schedule is developed consistent with Best Practice Project Management Standards (PMBOK) and DoIT requirements mat: Completed to DoIT StandardsQuality Review – IV&V, RMIS Business Owner and GSD CIO

4.1.1.10 RMIS -DEL-009 - Executive Steering Committee Meeting Agenda/MinutesDescription – Executive Steering Committee meeting agenda and minutes

Deliverable Acceptance Criteria – Must meet criteria of the Executive Steering Committee.Standards for Content and Format – Will use PM template.Quality Review – Project Executive Steering Committee and IV&V.

4.1.1.11 RMIS -DEL-010 - Project Team Meeting Agenda/Minutes

Description – Project Team meeting agenda and minutes

Deliverable Acceptance Criteria – Must meet needs as defined by the Project Team members and the Project Manager.Standards for Content and Format - Will use PM template.

Quality Review - Will be reviewed by Project Team Leads

4.1.1.12 RMIS -DEL-011 - Project Budget and Expenditures Report

Description – Project Budget report to identify spend by fiscal year and projected amount

Deliverable Acceptance Criteria – Must meet criteria of the Project Sponsor, Project Owner and Project Director.

PAGE | 17

remaining. Standards for Content and Format – Will use PM template.

Quality Review – Will be reviewed by IV&V, RMIS Project Owner and GSD CIO.

4.1.1.13 RMIS -DEL-012 - Risk/Issue Log

Description – Project Risk/Issue Log to track Risk, Mitigation and Contingency plans. Issues will be tracked and assigned to a principle owner for resolution.

Deliverable Acceptance Criteria – Will be reviewed and accepted by the Project Steering Committee

Standards for Content and Format – Will use standard DoIT template.

Quality Review - Will be reviewed by IV&V, Business Owner and Project Director

4.1.1.14 RMIS -DEL-013 – Lessons Learned

Description – Document lessons learned during course of entire project.

Deliverable Acceptance Criteria – Will be reviewed and accepted by the Project Steering Committee

Standards for Content and Format – Will use standard DoIT template.

Quality Review - Will be reviewed by the IV&V, RMIS Business Owner and GSD CIO

4.1.2 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS

DELIVERABLE NUMBER

DELIVERABLE APPROVERS (WHO CAN APPROVE)

DATE APPROVED

RMIS-DEL-001 Project Management Charter Sponsor and GSD CIO

RMIS -DEL-002 Project Management Plan (PMP) Executive Sponsor and GSD CIO

RMIS -DEL-003 PCC Certification Request Forms & Presentations

Business Owner and GSD CIO

RMIS -DEL-004 IV&V Contract & Reports Business Owner and GSD CIO

PAGE | 18

DELIVERABLE NUMBER


DATE APPROVED

RMIS -DEL-005 Business Analysis IT Professional Services Contracts


RMIS -DEL-006 Risk Management Consultants IT Professional Services Contracts


RMIS -DEL-007 Monthly Project Status Reports to DoIT

GSD CIO

RMIS -DEL-008 Project Schedule RMIS Business Owner and GSD CIO

RMIS -DEL-009 Executive Steering Committee Meeting Agenda/Minutes


RMIS -DEL-010 Project Team Meeting Agenda/Minutes

Project Team Members

RMIS -DEL-011 Project Budget and Expenditures Report


RMIS -DEL-012 Risk/Issue Log Executive Steering Committee

RMIS -DEL-013 Lessons Learned Executive Steering Committee

4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE

Section 6.7.5 documents the Deliverable Acceptance procedures to be followed for the RMIS Replacement project.

PAGE | 19

4.2 PRODUCT LIFE CYCLE The General Services Department intends to purchase a Commercial Off-the-Shelf (COTS) product with the product providing software functionality to address risk management best-practices. GSD’s product life cycle strategy is to incorporate phases to plan, design, build, test, deploy and transition the product to operations. The table below documents the process and anticipated Key Deliverables.


Plan GSD will utilize the Plan Phase to document “As-Is” and “To-Be” Business and Technical Requirements.

During the Plan Phase, GSD also intends to develop a Request for Proposal(RFP) to procure software and services from potential vendors.

“As-Is” Business and Technical Requirements

“To-Be” Business and Technical Requirements

Requirements Traceability Matrix

RFP Requirements

Design Once a software vendor is awarded a contract via an RFP, the vendor and GSD personnel will begin the process of documenting design specifications to address NM requirements.

Implementation Vendor Work Plan

Project Schedule

Build The Build Phase will extend and focus the areas of performance detailed during the Design Phase. Work during the Build Phase will be focused according to the area or track as follows:

Install and Configure Development, QA and Production Environments

Configure Software

Develop Reports

Configure Security

Data Conversion and Migration

Test The testing process will be driven and guided by the work flows defined Design Phase.

Unit Test Results

Module Test Results

End to End Process Test Results

System Integration

PAGE | 20

Testing

User Acceptance Testing

Deployment The software is placed into the Production Environment and utilized by the agency to process their day-to-day transactions.

All Testing completed

Support Staff Trained

End Users Trained

Go-No Go Sign-Off

Production cutover activities documented and executed

Transition to Operations Documentation drafted, reviewed and approved by GSD CIO

Transition to Operations After a 6-months warranty period, GSD TSSB support staff will provide first-level technical support for the product.

Process to document software issues and failures.

Maintenance Contract executed and in place

4.2.1 TECHNICAL STRATEGY

The Technical Strategy for the RMIS Replacement Project is to acquire and install a Commercial Off-the-Shelf software product designed and built to address governmental entities that are self-insured. Other elements of the Technical Strategy include:

Appropriate Sizing – The environment will be resized as necessary to account for any additional resources required to support the system;

Open Architecture – Infrastructure will allow for data flow between the RMIS modules and allow for third party products to interface with RMIS for a seamless architecture and scale to allow for growth;

Customer Portal and Web-Based System – Will be designed on a public-facing network with the web-based platform front-end to enable RMD, agency customers, and contractors to view data specific to their claims and associated transactions;

Database Standards – System database will comply with TSSB supported platform standards of MS SQL 2014 or higher;

Efficiency, High Performance – Application will be deployed on current GSD ESX 6.5.0 VMWare platform;

PAGE | 21

Embedded Report Tool – System will have an embedded report writing tool for ad hoc and standard reports. Regularly scheduled reports may be generated upon request or demand;

Authentication – The RMIS Replacement System must interface with Microsoft Active Directory;

Redundancy – GSD virtual server infrastructure supports system fail over; and

Security/User Roles – The RMIS Replacement product must provide a secure front-end user system log in facility and incorporate security role-level authentication

4.2.2 PRODUCT AND PRODUCT DEVELOPMENT DELIVERABLES

4.2.2.1 RMIS-DEL-101 - Business Analysis “As-Is” Business and Technical Requirements

Description – GSD intends to contract for business analysis services to document the Risk Management Division’s “As-Is” Business and Technical Requirements

Deliverable Acceptance Criteria: Contains sufficient detail to clearly convey information related to the existing business and technical requirements in use by the Risk Management division in preforming their daily work tasks.

Standards for Content and Format: Compliant with DoIT Template Standards and guidelines; and GSD-TSSB StandardsQuality Review – 1st Review: GSD Project Teams2nd Level Review: RMIS Business Owner and GSD CIO

PAGE | 22

4.2.2.2 RMIS-DEL-102 - Risk Management Consultants “To-Be” Business and Technical Requirements

Description – GSD has identified a firm with extensive risk management experience that also publishes annual rankings for risk management software products based on software functionality provided, and the ability of the vendor to implement their products in a timely manner.

Contains sufficient detail to clearly convey information related to future-state software functionality required by the Risk Management division in order to address industry best-practices.

Standards for Content and Format: Compliant with DoIT Standards and guidelines; and GSD-TSSB StandardQuality Review – Reviewed and approved by GSD CIO

4.2.2.3 RMIS-DEL-103 - RMIS Replacement Requirements Traceability Matrix (RTM)

Description – Using the “As-Is” and “To-Be” Reports, the RM Consultants will develop an RTM.

Contains sufficient detail to clearly convey information related to business and technical requirements needed in a new RMIS product.

Standards for Content and Format: Project Management Best Practice and aligned to and in support of the strategic goals and objectives of the State, GSD, and RMD.Quality Review – Reviewed by Project Manager, RMIS Business Owner, GSD CIO, and IV&V vendor

4.2.2.4 RMIS-DEL-104 - RMIS Request for Proposal

Description – The RM Consultants will develop a RFP with associated documentation required to procure a RMIS Replacement Product.

Deliverable Acceptance Criteria: Sufficient levels of detail to conduct a procurement of a RMIS software product, procure implementation services, and procure maintenance and support for the product once transitioned to operations.

Standards for Content and Format: Compliant with NM State Purchasing RFP guidelines and standards, DFA and DoIT Procurement and Contract Review and Approval Process.

PAGE | 23

Quality Review –

1st Review: Project Functional Teams, 2nd Level Review: and IV&V, Project Director, RMIS Business Owner and GSD CIO3rd Level Review: GSD State Purchasing Division and DoIT EPMO

4.2.2.5 RMIS-DEL-105 - Implementation Vendor Contract

Description – Once RFP is completed, and vendor is identified as the awarded-vendor, an IT Professional Services Contract is developed and executed between GSD and the awarded vendor. The Vendor Contract will identify all Contract Deliverables. Deliverable Due Dates and Deliverable Compensation Amounts.

Deliverable Acceptance Criteria: The DoIT IT Professional Services Contract Template will be utilized to document contract terms and conditions. GSD and the Vendor will document Exhibit A – Contract Deliverables which meet the interest of the General Services Department – Risk Management Division.

Standards for Content and Format: Standard DoIT large template IT contract template to be used.

Quality Review –

1st Review: Reviewed by the RMIS Business Owner, GSD CIO and IV&V Vendor.2nd Level Review: DoIT EPMO, and GSD General Counsel.

4.2.2.6 RMIS-DEL-106 - Implementation Vendor Work Plan

Description – The RFP awarded vendor will be required to develop a Work Plan describing how they will implement their software product.

Deliverable Acceptance Criteria: Conveys a clear understanding of the vendor activities related to software design, build, test, deploy and transition to operations.

Standards for Content and Format: Format will be agreed to by GSD and the RFP awarded vendor.

Quality Review –

1st Review: RMIS Business Owner, GSD CIO and IV&V Vendor 2nd Level Review: Executive Steering Committee

PAGE | 24

4.2.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS

DELIVERABLE NUMBER


DATE APPROVED

RMIS-DEL-101 Business Analysis “As-Is” Business and Technical Requirements

RMIS Business Owner and GSD CIO

RMIS -DEL-102 Risk Management Consultants “To-Be” Business and Technical Requirements

RMIS Business Owner and GSD CIO

RMIS -DEL-103 RMIS Replacement Requirements Traceability Matrix (RTM)


RMIS -DEL-104 RMIS Request for Proposal Business Owner and GSD CIO

RMIS -DEL-105 Implementation Vendor Contract Business Owner and GSD CIO

RMIS -DEL-006 Implementation Vendor Work Plan


4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE

Section 6.7.5 documents the Deliverable Acceptance procedures to be followed for the RMIS Replacement project.

PAGE | 25

5.0 PROJECT WORK

5.1 WORK BREAKDOWN STRUCTURE (WBS)

The table presented below identifies the anticipated Work Breakdown Structure (WBS) to be followed during the RMIS Replacement Project; therefore, the table will be updated as the project progresses, and a vendor is awarded the RFP contract. The table is subject to change and will most likely incorporate vendor proven methodologies utilized in similar project deployments.

PAGE | 26

Identifier Work Package Description Definition/Objective Milestone/Deliverable

1.0 Project Management and Control

Risk, Issues and Action Item Management, Documentation Management, Scope Control, Status Reporting, Steering Committee Meetings

Status Reports, Steering Committee Meetings, Risk, Issues and Action Items

2.0 Technology Install latest version of RMIS Replacement software in the TEST EnvironmentEnsure difference of no greater than one release between TEST, QA and PROD environmentsInstall RMIS Replacement Versions as they are releasedMaintain Environments

Installed Software and Documentation (where applicable)

3.0 Initiation Phase Finalize Scope; Develop Project Scope; Schedule and Budget documentation; Set up Document Management Repository; Conduct Kick-Off Meeting; Technology Planning; Change Management Planning

Project Initiation Proposal, PMP, SharePoint, Schedule, Kick-Off Meeting;

4.0 Plan PhaseBusiness Requirements Definition Plan,

Prepare for Business Requirements Definition Sessions

Requirements Definition Plan,

Session Schedules, and Participants;

Implementation Request and PCC Presentation

PAGE | 27


5.0 Implementation Phase Comprised of Design, Build, and Test Activities

Completion of Design – Business Requirements Definition Report Sign-Off

Completion of Build – Unit Testing CompletedCompletion of Test – End to End Process Testing Complete

5.1 Design Activities Train Business Process Requirements Definition Participants in methodology and products to be implemented;

Conduct Requirements Definition Sessions; Prepare Business Requirements Report; Finalize and present to Steering Committee for Approval

Core Team Orientation Training

Business Requirements (Design Document) approved by Steering Committee

5.2 Build Activities Software configuration, data conversion, interface development, report development.

Testing Environment Ready;

Configuration, Data Conversion,

Interface Specifications;

Reports; Testing Strategy and Plan,

5.3 Test Activities Unit Testing; Training Materials Developed; Module Testing; End to End Process Testing;

Unit, Module and Process Test Results;

End User Quality Assurance Sign-off

PAGE | 28


6.0 Deployment Phase Support Staff Training, Train the Trainer Training, End User Training;

Go/No Go Review; Production Cutover;

Stabilization Support (Call Center, End User Field Support, Remediation and Follow up Training Support); Lessons Learned Analysis; Project Close-out

Support Staff, Trainer and End User Training Completed;

Production Authorization;

Cut Over;

Lessons Learned Report, Project Close-Out

7.0 Closeout Phase Conduct Lessons Learned Review and Prepare Report;

Submit Closeout Request and Presentation to PCC

Lessons Learned Report

PCC Closeout Request, and Presentation

PAGE | 29

5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE

PAGE | 30

5.3 PROJECT BUDGET

MAJOR PROJECT DELIVERABLE AND PERFORMANCE MEASURE

BUDGET DUE DATE PROJECT PHASE ON

Preliminary Internal Staff Project Kick-offCommunication Plan draftResource AllocationDraft Project CharterPMP draft including schedule and budget IV&V Deliverables DefinedIV&V Contract DraftedAs-Is Business Analyst Contract DraftedRisk Management Consultants identified and

Deliverables DefinedDetermine procurement vehicle for Risk

Management ConsultantsGovernance Structure FinalizedSharePoint Document Repository, Folder

Hierarchy Designed/Setup

$11,800.00 (Prof.

Services)

July 2018 Initiation

Finalize PMPBusiness and Tech Requirements definedCommunication Plan finalized“As-Is” Business and Technical

Requirements, User Requirements, Process Flow Diagrams, Data Flow Diagrams, Requirements Traceability Matrix

Finalize Business Requirements Definition Session Strategy and Schedule

Develop RMIS Request for ProposalsDevelop RFP Mandatory and Desirable CriteriaDevelop RFP Evaluation CriteriaDevelop RFP Finalist Presentation ScenariosDevelop RFP Evaluation Committee ReportSchedule definedBudget finalizedRisk Plan completedSupport and Operations PlanTechnical Architecture finalizedProject Team FinalizedSystem Preparedness and deployment plan

$469,148.00. (Prof.

Services)

June 2019 Planning

PAGE | 31

MAJOR PROJECT DELIVERABLE AND PERFORMANCE MEASURE

BUDGET DUE DATE PROJECT PHASE ON

Roles and Responsibilities definedChange Management PlanOfficial Project KickoffImpact Analysis PerformedIV&V Contract ExecutedRMIS software acquisition and

Implementation Services Contract Executed

“As-Is” and “To-Be” Business Requirements Documentation

Software installedTest and Train environments refreshedSystem configurationTraining RequirementsUse CaseTest PlanTraining PlanSystem Admin PlanUser Acceptance Test PlanAgency Pilot Plan

Security Policy and PlanUser documentationSystem Admin DocumentationBusiness Admin DocumentationArchitecture Plan

$478,370.00 (Prof.

Services)

$519,282.00(Software)

June 2020 Implementation

Final DocumentationTransition to OperationsFinal IV&V ReportLessons Learned

$21,400.00 (Prof.

Services)

September 2020

Closeout

TOTAL $1,500,000.00

PAGE | 32

5.4 PROJECT TEAM5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE

5.4.2 PROJECT TEAM ROLES AND RESPONSIBILITIES

Role Responsibility Name Functional Area

Property & Casualty Claims Requirements Definition Team

Participates in the Business Requirements Definition Sessions identifying the requirements for the Property & Casualty Bureau

Rod Crawley and 2 other staff members to be determined

RMD Property & Casualty Claims Bureau

Workers’ Compensation Requirements Definition Team

Participates in the Business Requirements Definition Sessions identifying the requirements for the Workers’ Compensation Requirements Bureau

Ida Spence

Martin Sandoval

Carl Sandoval

RMD Workers’ Compensation Bureau

Business Admin and Reporting Business Requirements Definition Team

Participates in the Business Admin and Reporting Requirements Definition Sessions identifying Admin requirements

Brian Walker and 1 other staff member to be determined

RMD Business Administration and Reporting Bureau

Financial Controls Business Requirements Definition Team

Participates in the Business Admin and Reporting Requirements Definition Sessions identifying Admin requirements

Markita Sanchez and 1 other staff member to be determined

RMD Finance

Change Management Lead

Oversees Implementation of Change Management Plan; participates in Business Requirements Definition Core Team Training and Business Requirements Definition Sessions

Michael Bebeau RMD Legal

PAGE | 33


Technical Lead Conducts Technical Site Survey and Sizing Study; develops Configuration Management Plan, Continuity of Operations Plan, and Backup and Recovery Plan; installs and maintains technical environments, applies patches, manages configuration; maps data to new RMIS product, stages and loads data; unit tests data loads

Maurice Bonal TSSB

Functional Administrator (User Authorizations)

Manages User Authorities TBD TSSB

Report Development

Designs, develops, tests, and deploys reports

Flaviano Prosperini TSSB

Data Lead / DBA Tunes database; and performs data cleanup; refreshes TEST and TRAIN environments as required


Integration Lead Designs, builds, and tests integrations to RMIS


Property & Casualty Claims User Acceptance Team

Participates in the user acceptance testing of the property and casualty claims modules

Rod Crawley and 2 other staff members to be determined

RMD Property & Casualty Claims Bureau

Workers’ Compensation User Acceptance Team

Participates in the user acceptance testing of the Workers’ Compensation modules

Ida Spence

Martin Sandoval

Carl Sandoval

RMD Workers’ Compensation Bureau

Business Admin and Reporting User Acceptance Team

Participates in the user acceptance testing of the Reporting modules

Brian Walker and 1 other staff member to be determined

RMD Business Administration and Reporting Bureau

PAGE | 34


Financial Controls User Acceptance Team

Participates in the user acceptance testing of the financial controls modules

Markita Sanchez and 1 other staff member to be determined

RMD Finance

5.5 STAFF PLANNING AND RESOURCE ACQUISITION5.5.1 PROJECT STAFF

Resource Cost Estimate

Estimated Hours Availability Skill Set Work Product/Deliverable

Karen Baltzley $ 0 325 .25 FTE CIO Technology Plan; Contract Administration; Project Charter; Project Documentation; Tech Staff Management; Steering Committee Meetings, PCC Hearings; Monthly DoIT Reports and Check-ups

Project Manager $ 300,000 4160 F/T Project Management; Strategic Planning

PMP, Project Schedule, Planning Documents; Project Management

IV&V Contractor $ 88,000 Contract Terms

As Needed

Project Management

IV&V Plan; Assessment; Monthly Status Reports; System & Acceptance Testing; Final Assessment Report

Flaviano Prosperini

$ 0 TBD .25 FTE Technical Lead

Oversee Technical Environments; Interface Development; Configuration Management

Michael Bebeau $ 0 400 .10 FTE Change Management Lead

Provide input to Change Management Plan; coordinate development of new or updated SOPs, coordinate Presentations and other communications; provide input to Communications Plan

PAGE | 35


Estimated Hours Availability Skill Set Work Product/Deliverable

Martin Sandoval $ 0 600 .15 FTE Test Lead Provide input to the Test Strategy and Plan; coordinate development of test products and testing and document results

Ida Spence $ 0 600 .15 FTE B-SMEWorkers’ Compensation

Business Process Definition Designs, Training Products, Testing Products;; End User Support

Rod Crawley $ 0 600 .15 FTE B-SME Property and Casualty

Business Process Definition Designs, Training Products, Testing Products; End User Support

Brian Walker $ 0 600 .15 FTEB-SME Business Admin & Reporting


Markita Sanchez $ 0 600 .15 FTEB-SME Finance


5.5.2 NON-PERSONNEL RESOURCES

None identified at this time.


Estimated units/hours Availability Source Work Product/Deliverable

5.6 PROJECT LOGISTICSA Project Office has been in established at the GSD TSSB’s offices at the Joseph Montoya Bldg., 1100 St. Francis Drive, Suite 1022, Santa Fe. The Project Manager will work out of this space. Project Planning, the Business Process Definition Design Sessions, testing, training and the majority of other project activities will be conducted in the TSSB Training Lab.

PAGE | 36

Technical Staff are located in TSSB’s offices at the Joseph Montoya Bldg., 1100 St. Francis Drive, Suite 1022, Santa Fe.

During the Testing Lifecycle, the TSSB Training Lab will be used as a Test Lab, during which time the Test Lead and Testers will carry out testing evolutions.

All other key resources are currently located at the Risk Management Division offices located at the Joseph Montoya Bldg., 1100 St. Francis Drive, Room 2073, Santa Fe.

5.6.1 PROJECT TEAM TRAINING

Project Team members and stakeholders will receive various types and levels of training, depending on their involvement in the project and the phase of the project. This information will be developed and refined as Planning activities continue.

PAGE | 37

ResourceCost Estimate

Estimated Hours Availability Skill Set

Work Product/Deliverable

Property & Casualty Claims Business Requirements Definitions Team

$ 0 TBD 3 FTE High-level experience

“As-Is” and “To-Be” RequirementsRMIS Software Business Definition Requirements

Workers’ Compensation Business Requirements Definitions Team



Business Admin & Reporting Business Requirements Definitions Team



Financial Controls Business Requirements Definitions Team



Property & Casualty Claims User Acceptance Testing Team

$ 0 TBD 3 FTE Mid-level experience

RMIS Testing Results

Workers’ Compensation User Acceptance Testing Team



Business Admin & Reporting User Acceptance Testing Team



Financial Controls User Acceptance Testing Team



6.0 PROJECT MANAGEMENT AND CONTROLS.

6.1 RISK AND ISSUE MANAGEMENTThe Project is using the strategy developed in the recent GSD PROOF project which follows the DoIT Methodology as it relates to Risk Management and Issues Management. MS-SharePoint will be deployed in support of the project, and both Risk Management and Issues Management are documented and tracked from the Home Page of the project site.

PAGE | 38

A Risk is defined as something that has a probability of occurring, and for which a determination of action must be made to avoid, mitigate, or accept the effects of that occurrence.

An Issue is defined as something that has occurred, and which will have an adverse impact which must be addressed to minimize impact and to facilitate recovery.

NOTE: a project risk that has occurred may also be considered an issue

6.1.1 RISK MANAGEMENT STRATEGY

A Risk Assessment and Report will be developed during the first few weeks of the project and will be on file on the project SharePoint site in the Risk Management Library. A Risk Log will be created at that same time and will also be maintained and updated at frequent intervals. It will also be filed on the SharePoint site.

Tasks will be established in the project schedule for updating the Risk Assessment Report prior to each project stage gate. Risk Identification is a standing item on the Core Team Meeting Agenda to ensure that risk awareness remains at a high level across the project team over the lifecycle of the project. Prior to Phase Gates, the Core Team will elevate emphasis on Risk and Issue Identification and Management.

The Risk Log is referred to and updated regularly by the Project Manager. All project personnel have access to the Risk Log and may submit a perceived risk at any time.

6.1.2 PROJECT RISK IDENTIFICATION

Risks may be identified at the project level or by a number of other criteria. A column entitled ‘Category’ has been added to the Risk and Issues Log, which provides any stakeholder with another method for parsing the risks by area of responsibility, thereby aligning risks with the project organizational structure.

As indicated above, any member of the team may identify and log either a risk or an issue at any time. Team Members and Stakeholders are encouraged to raise risks and issues anywhere and anytime they are perceived.

6.1.3 PROJECT RISK MITIGATION APPROACH

The Project Team’s approach to risk mitigation is based on conservativism and pro-activity. Any perceived risk will be granted due diligence, objective consideration. A mitigation strategy will be developed as appropriate.

The Project Team will be pro-active and strive to create a culture where team members are encouraged to raise risks and issues wherever they are perceived. The Team is similarly committed to elevating awareness of risks and issues to the Executive Steering Committee and Governance and will work pro-actively with the IV&V contractor to seek collaborative and timely mitigation of strategies

6.1.4 RISK REPORTING AND ESCALATION STRATEGY

Risks may be raised by anyone at any point during the project lifecycle. Risks may be reported via email or entered directly into the SharePoint Risk Log and then reported to the Project Manager for consideration and disposition.

PAGE | 39

Risks will be evaluated by the Project Manager and Core Team Leads (Technical, Change Management, and Communications Leads). All Risks reported will remain on the Risk Log, though they may be moved to a “Closed” status as appropriate. All new risks will be discussed in the weekly Core Team Meetings and will be disclosed on the Project Manager’s weekly status reports to Executive Steering Committee Members and other Stakeholders.

Risks of “Likely” or higher probability or “Medium” or higher impact will be presented at the monthly Steering Committee meetings. The contingency plans for each will be discussed, as will the mitigation plans.

6.1.5 PROJECT RISK TRACKING APPROACH

All project risks will be tracked using the DoIT Risk and Issue Log Tracking tool provided. As noted above, new risks will be discussed at the bi-weekly project team meetings, and all open risks will be reviewed by the Core Team on a monthly basis to assess changes in probability or impact.

The Risk and Issues Log is available at any time on the Project SharePoint.

6.1.6 ISSUE MANAGEMENT

6.1.6.1 Internal Issue Escalation and Resolution ProcessThe internal process is provided for issues that involve project resources, processes, procedures, or methodology that should be resolved within the Division responsible for managing the project without affecting the overall project schedule, cost, or quality. This process should be used for improving project processes as the project is executed and where the implementation of such improvements should not be postponed to Lessons Learned during Project Close.

Internal issues will be addressed and escalated in a manner similar to that of the Risks. Internal Issues can be raised by any team member or stakeholder. Issues will be maintained in the Issues Tracking folder on the RMIS Replacement Project SharePoint site. New Issues will be discussed at the Core Team Meeting and assigned, dispositioned, or escalated as appropriate. Internal Issues will also be discussed at bi-weekly one-on-one meetings between the Project Director, Project Manager and RMD Director. As appropriate, Internal Issues will be escalated to the Executive Steering Committee, DoIT, or other governance body

6.1.6.2 External Issue Escalation and Resolution ProcessThe external process is provided for issues that involve project resources, processes, procedures, or methodology that cannot be resolved within the Division responsible for managing the project without impacting overall project schedule, cost, or quality.

External Issues will have the same escalation and resolution process as internal issues, except for the need to reach out to and engage the external agency or entity involved. At the core, the Project Team will seek collaborative and mutual agreeable resolutions to issues

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V

PAGE | 40

The NM GSD RMIS Replacement Project’s IV&V approach will include evaluation of project management practices and key project deliverables for conformance with industry standards and best practices.

The IV&V Contractor shall:

Attend a broad range of project meetings to assess overall project health, and conduct interviews with a diverse sample of project stakeholders.

Provide an independent escalation path for project issues and project inhibitors. Provide early, proactive insight into project risks with recommendations. Facilitate early detection and correction of errors/issues. Enhance the project management team’s understanding of how to apply the industry’s

best practices to specific project needs. Help the project team meet its performance, schedule, and budget requirements. Provide valuable assessments of products and processes throughout the project lifecycle.

IV&V Contract Deliverables include:

1. IV&V Initial Assessment Report 2. 22-monthly IV&V Status Reports3. IV&V Close-Out Report

PAGE | 41

6.3 SCOPE MANAGEMENT PLAN6.3.1 CHANGE CONTROL

6.3.1.1 Change Control ProcessChange Control will initially come into the project’s visibility as an Issue, Action Item or Risk. Change Control items are expected to surface primarily during the BBP Sessions, but irrespective of when and how they surface, the process of evaluating, escalating and resolving the Change Item (CI) will be the same. CI’s will be documented in the ‘Action Items and Issues’ folder on the RMIS Project’s SharePoint site. CI’s will be detailed there, with specific information required, including:

Brief Description Detailed Description Date CI Submitted Submitted By Business Owner (Director Benefitting/Requiring) Business Justification Cost Benefits Decision Required By Date Status Progress Notes Resolution

Once a CI has been submitted, a meeting of the Core Team Leadership will be convened, including the Project Manager, GSD-CIO, RMD Director, Change Control Lead, Technical Lead, B-SME Lead, Functional Administrator, and Communications & Training Leads. The Project Leadership Group will consider the CI, its justification, costs and benefits, and make a recommendation on the resolution of the CI. CI’s resolved there by a unanimous vote will be escalated to the Steering Committee for approval. Those CI’s either not resolved, or where resolution is by less than a unanimous vote will be escalated to the Steering Committee (Change Control Board) for evaluation and final resolution.

6.3.1.2 Change Control Board (CCB)The Executive Steering Committee will serve as the CCB, who will make a final determination on any CI.

6.4 PROJECT BUDGET MANAGEMENTProject costs are as defined above under Sections 5.5.1 and 5.5.2. All costs related to project staff are included in the project schedule and projected out over the lifecycle of the project.

PAGE | 42

Project costs have been projected using an MS-Excel spreadsheet containing monthly forecasts of costs for contract resources, software, maintenance fees, and contingencies. Actual costs will be reported against this forecast, and variances reported on a monthly basis.

6.4.1 BUDGET TRACKING

The Project Manager will track project expenditures as expenditures are paid on the SHARE Accounting System. RMD Finance personnel will generate a monthly expenditure report for the project and the project expenditures will be reconciled with the Project Budget and Expenditures Worksheet and the SHARE General Ledger.

PAGE | 43

6.5 COMMUNICATION PLANThe Project Communication Plan will provide an approach for communications and support for the project.

The purpose of the Communication Plan is to facilitate centralized communications between and among all identified project audiences. Combining the audiences’ needs with methods for standardizing communications will enable processes for conveying project awareness, status, and issues and provide a means for feedback.

Various types of information are being communicated throughout the life of the Project. For the purpose of this project, four types of information categories have been determined:

Project Execution Project Status Project Awareness Information Generic Information

The Project audience has been broken into four broad categories:

Core Team Extended Team Internal [within RMD] External [New Mexico citizens, and other interested parties]

A detailed matrix will be created to match audiences with the appropriate type of information. Frequency and media have also been identified for each type of communication. The communications matrix will serve as the foundation of who, what, where, when, why and how the Project team will communicate with project stakeholders

6.5.1 COMMUNICATION MATRIX

The communications matrix matches the various types of information with the appropriate audiences. In addition, the matrix identifies the communication frequency and medium for the information, by audience. The matrix format is dynamic in that it allows for changes in types of information received, how often, and in what format.

A significant amount of the information communicated is focused within the Project Team. A well-informed team is better prepared to communicate effectively the strategy, goals, objectives, and status of the Project efforts. In addition, the majority of the communication information originates within the team. Therefore, effective communications within the Project Team contributes to the success of the communication efforts with the other audiences.

PAGE | 44

The following key identifies the various frequency and media options for communications.

Communications Frequency

Daily

Bi-Weekly

Weekly

Monthly

Quarterly

Upon Document Publications

As needed

Upon Joining Project

Communications Media

Lead Agency Publications

Documents / Presentations

Electronic Mail

SharePoint Web Site

Road Show Presentation Meetings

Ad Hoc Meetings

Training

Voice Mail

Tele/Video meeting

6.5.2 STATUS MEETINGS

Various status meetings are conducted on a frequent basis:

Project Core Team meetings are typically conducted bi-weekly, with the exception of the period when Business Requirements Definition (BRD) Sessions are in progress

NOTE: Core Team Meetings are typically suspended during the BRD Sessions, as the entire team is engaged in the meetings. If a Core Team Meeting is required to address a critical project issue, a special session will be convened.

Meeting between the Project Director, Project Manager and RMD Director every other Wednesday;

Executive Steering Committee Meeting meets the last week each month;

PAGE | 45

Weekly attendance / representation at the RMD Manager’s meeting More frequent meetings with leadership and other stakeholders as appropriate or as

needed

6.5.3 PROJECT STATUS REPORTS

All contract personnel will be required to submit status reports weekly to the Project Manager. In addition, the Project Manager will gather detailed accomplishments from RMD staff and incorporate these in the Project Status Reports (PARs). These individual PARs include activities and accomplishments, plans for the next reporting period, and any comments, suggestions, issues, concerns or questions. The Project Manager combines these individual PARs into a project level status report that is distributed to Executive Steering Committee Members, key stakeholders in RMD, GSD, IV&V Contractor, and all Project Core Team Members. A copy of each week’s status report is also filed on the Project SharePoint Site in the Status Report folder.

Monthly status reports are also submitted to DoIT in accordance with DoIT requirements. The IV&V Contractor will also submit status reports and reviews on a monthly basis. Both the DoIT Status Reports and the IV&V Review Reports will be available on the Project SharePoint site

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)The Project Manager, Business Sponsor, and Executive Sponsor will define the project metrics that will be used to control the project, with possible criteria identified in the table below. Metrics will be collected for measuring the progress of a project against its planned budget, schedule, resource usage, and error rates, and of establishing a historical database, which will aid in planning and forecasting future projects.

Metric Type Metric Goal

Schedule Late Tasks – Tasks starting late or projected to finish late

< 5; < 1 for Critical Path Tasks

Quality Key Project Documents Approved by Leadership 100%

6.6.1 BASELINES

Project Area Category Measure

Project Schedule Schedule On or ahead

Project Budget Budget Under

Project Scope Scope Control 0 Change Orders

PAGE | 46

6.6.2 METRICS LIBRARY

6.7 QUALITY OBJECTIVES AND CONTROLThe Project Goal is to conduct a timely, cost effective implementation without modifying or customizing the software. These are the Quality Objectives by which the project will be judged. In essence, on time, within budget, without customization, achieving the goals stated at the top of this PMP document.

Quality Control will be further demonstrated in the Test Strategy and Plan as well as the Training Plan. Finally, more definition to the quality objectives will be detailed in the Benefits Realization Plan section of the Business Requirements Report.

6.7.1 QUALITY STANDARDS

No. Quality Standard Tracking Tool or Measure

1 Standards defined by statute • TBD2 The Project Management Quality Standards as defined by

the Project Management Body of Knowledge (PMBOK)• TBD

3 Information Technology standards defined within the Information Technology framework by DoIT

• TBD

4 Risk Management industry best practice standards. • TBD5 •

•

•

•

PAGE | 47

6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTS

Review Type Quality Standard Tools Reviewer Reports

Requirements NM Statutes; Work Flows modeled in product;Maintenance and Materials Management Industry Best Practice

MS-Visio, MS-Excel, MS-Word,

RMD Director, Executive Steering Committee

Business Process Requirements Report

Plans PMBOKDoIT

MS-Word, MS-Project

GSD CIORMD Director

PMP, Change Management, , Communications, Training;Test Strategy and Plan

Milestones PMBOKDoIT

MS-Project RMD Director; Executive Steering Committee

Status ReportsExecutive Steering Committee Presentations

Testing PMBOKDoIT

MS-Word

MS-Excel

GSD CIORMD Director

Status Reports

Test Strategy and Plan

Use CasesTest Results

6.7.3 AGENCY/CUSTOMER SATISFACTION

Customer and Agency satisfaction will be assessed on an on-going basis by the Project Manager and Team. Weekly (Stakeholder) and Monthly (DoIT) Status reports, Steering Committee Meetings, Presentations, and frequent updates to agencies and customer groups will be the primary mechanisms by which the Team will communicate progress, goals and objectives, and identify issues and benefits.

Project reporting metrics will provide primary feedback on schedule and budget performance, and we will coordinate efforts with initiatives wherever synergy and common interests exist.

PAGE | 48

The project manager will meet with the RMD Director and GSD-CIO on a bi-weekly basis to ensure project performance is meeting expectations, and with the GSD Cabinet Secretary and others on a monthly basis to ensure customer and agency satisfaction

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS

All products produced by the Project will be reviewed by oversight groups and leadership.

Testing the RMIS product and RMD processes will have several dimensions to ensure quality and consistency in all deliverables. Each track of the project (process change, configuration, data conversion, interface development, report development, testing, and training) will be tested initially on an isolated basis (Unit Testing). Unit Testing will be followed by Module Testing.

Following successful completion of Module Testing, End to End Process Testing will be performed. In End to End Testing, transactions will be run through their entire life cycle. In that effort, the Project Test Team will exercise and evaluate process change related documentation (forms, SOPs, etc.), configuration data workflow, data conversion, interface performance, reports, and training materials.

Following completion of End to End Process Testing, a final round of End User Acceptance Testing will be undertaken. Staff from various bureaus of RMD will be engaged to process work using the modules being implemented and will provide feedback to the Project Team.

Prior to beginning production use of the RMIS software, an evaluation will be made regarding operational readiness in a number of areas, including training readiness, technical readiness, quality assurance testing readiness, and operational support readiness. The results of that evaluation will be presented to the Executive Steering Committee, which will make the final determination on approving the production cut-over.

6.7.5 DELIVERABLE ACCEPTANCE PROCEDURES

The Deliverable Acceptance Procedure assures that the deliverables meet the requirements of the contract.

The Project Manager will deliver a Deliverable Acceptance Form (Sample in Appendix -B) to the Approver with each Deliverable. The Form will identify the deliverable and the acceptance criteria.

Upon receipt of the Deliverable and Acceptance form, the Approver has 15 working days to formally approve or reject the Deliverable. The form must be marked approved or disapproved. There is no acceptance or rejection by default.

If the Deliverable is rejected, a detailed description of why it was rejected must be included on the form. In the event of a rejection, the Contractor has 3 business days to address issues with the Deliverable and to resubmit the Deliverable. All errors and omissions must be detailed in the Rejection. The Contractor

E-mail approval with the approver’s name typed on the form is an acceptable form of transmittal. When e-mail approvals are used, the e-mail with the approval should be saved as a text document and pasted into the acceptance form at the end of the form. Verbal approvals are not acceptable.

PAGE | 49

PAGE | 50

Criteria for Acceptance

The Project Manager and Approving Authority must agree on acceptance criteria for all deliverables before delivery. Acceptance criteria will describe deliverables by submitting vendor, contract number, deliverable title or name, deliverable acceptance criteria, or other measurable factors.

Acceptance Log

The Project Manager will maintain a Deliverable Acceptance Log (Sample in Appendix - C) to document the delivery and approval of each deliverable. The acceptance log will include the following information:

Date Submitted – the date the Project Manager presents the deliverable to the approving authority for acceptance.

Vendor – The name of the Vendor submitting the Deliverable. Contract Number – The Contract Number assigned by the Agency. Deliverable # - The Contract Deliverable Numbers as identified in the Professional

Services Contract. Approved or Rejected – indicating whether or not the deliverable is approved or rejected. Date of Action – Date that the approval or rejection took place.

.

PAGE | 51

6.8 CONFIGURATION MANAGEMENTConfiguration Management (CM) is the process of systematically controlling and managing all steps of configuration throughout the project lifecycle, the CM Plan operates in conjunction with, and in alignment to the Project Test Plan, the Continuity of Operations Plan, the Backup and Recovery Plan, and the Service Level Agreement.

The CM Plan provides a systematic approach for: (1) defining the process for managing changes to the RMIS environments; (2) determining who made a change to the environments; (3) discovering what changes were made, when they were made and why; and (4) understanding who authorized the changes.

This CM Plan is designed to safeguard effectively the data and configuration assets developed over the course of the Project.

The CM Plan:

(1) Provides contextual information aligning this plan to Project as a whole and references other related documents;

(2) Defines the scope of the CM processes for the Project;

(3) Provides details related to the environments that will be utilized in managing configuration changes;

(4) Details the processes for moving configuration items through environments;

(5) Defines the roles and responsibilities of project team members with respect to CM; and

Defines the toolset that will be used by the project team to track and manage changes during the project lifecycle

6.8.1 VERSION CONTROL

6.8.2 PROJECT REPOSITORY (PROJECT LIBRARY)

SharePoint has been implemented for RMD and is being utilized to track all project documentation

6.9 PROCUREMENT MANAGEMENT PLANAll procurement is being conducted in accordance with established standards and procedures promulgated by SPD, in accordance with DoIT guidelines, and with the ultimate approval of the LFC and DFA.

PAGE | 52

7. 0 PROJECT CLOSEProject Close consists of evaluating the project execution from a best-practice perspective, closing out administrative elements of the project, and contractual and financial aspects of the project as it relates to external vendors. A final element to the closeout relates to handing off ownership of the systems to the business, through transition to the RMD Change Board. The final step in the Project Close is a presentation to DoIT Project Certification Committee, which will review the closure request. Completing these activities is a mandatory step in the project life cycle.

7.1 ADMINISTRATIVE CLOSE

Administrative activities complete the internal needs for managing the project, such as records archival, recording the last hours against the project, transitioning staff to other assignments. Administrative closure consists of verifying that objectives and deliverables were met and transitioning remaining relevant documentation to the appropriate agencies providing on-going support.

7.2 CONTRACT CLOSE

Contractual activities must meet the contractual needs, such as executing a procurement audit and formal acceptance of the project work products. Contract close is similar to administrative close in that it involves product and process verification for contract close

PAGE | 53

ATTACHMENTSAppendix A – Acronyms and DefinitionsAppendix B – Deliverable Acceptance FormAppendix C – Deliverable Acceptance Log Appendix D – Project Schedule Appendix E – Project Budget

PAGE | 54

APPENDIX A - ACRONYMS AND DEFINITIONS - A -

Acceptance Criteria – The criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE-STD-610]

Acceptance Testing – Formal testing conducted to determine whether a system satisfies its acceptance criteria and to enable the customer to determine whether to accept the system. [IEE-STD-610]

Action Log – The action log is a direct extension of the project schedule. The action log reflects specific actions to be completed. Generally, these actions are small enough in both impact and duration to be handled on the Action Log rather than requiring a special revision to the project plan. Any item that requires more than one day to complete should be on the action log. The action log is a living document that will be updated frequently and serves as an ongoing “To Do List” to insure that action items are not left uncompleted. Actions will be captured during meetings and at other times by means of an action-input form. This form will be submitted to the project manager for entry into the log. The log will be maintained as a table in MS word. Closed actions will be moved to an archive.

AR Export – Asset Renewal Export

AR Import – Asset Renewal Import

ASD – Administrative Services Department

Assumptions – Planning factors that, for planning purposes, will be considered true, real, or certain. Assumptions generally involve a degree of risk. They may be documented here, or converted to formal risks.

- B -

Baseline – A specification or product that has been formally reviewed and agreed upon that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. [IEEE-STD-610]

BRR – Business Requirements Report

BPR – Business Process Re-engineering

- C -

CCB – Change Control Board

Change Management Log – The change management log lists the current status and project impact of each planned or enacted project change request. The log shows at a glance the current impact of change on the project. The Project Manager in a MS-Excel Worksheet format will maintain the change management log. The log will be updated when a proposed

PAGE | 55

or approved PCR is received. The log will be reviewed at the weekly Leadership meeting and reported on in the Weekly Status report.

CI – Change Item; a request for change on a project that falls under the purview of Change Control

Commitment – A pact that is freely assumed, visible, and expected to be kept by all parties.

Configuration Management (CM) – A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IEEE-STD-610]

Consensus – a decision that is in the best interests of New Mexico, GSD and RMD, and a design that the participants can live with and which they will commit to supporting

Constraints – Factors that will (or do) limit the project management team’s options. Contract provisions will generally be considered constraints.

Contingency Planning – The development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur.

COTS – Commercial off the Shelf Software. Package systems provided by vendors such as PeopleSoft or Oracle that provide support for a variety of different functions. Often referred to as Enterprise Resource Planning (ERP) Systems or Enterprise Asset Management (EAM) Systems.

.

Crashing – Taking action to decrease the total duration after analyzing a number of alternatives to determine how to get the maximum duration compression for the least cost.

Critical Path – The series of activities that determines the duration of the project. The critical path usually defined as those activities with float less than or equal to specified value often zero. It is the longest path through the project.

- D -

Decision Maker – a member of an organization possessing a high enough level of authority to render a decision with regard to organizational policy or procedure

Deliverable – Any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a project or part of a project that is subject to approval by the project sponsor or customer.

Dependencies, Discretionary – Dependencies defined by the project management team. They should be used with care and usually revolve around current Best Practices in a particular application area. They are sometimes referred to as soft logic, preferred logic, or preferential

PAGE | 56

logic. This may also encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.

Dependencies, Mandatory – Dependencies that are inherent to the work being done. In some cases, they are referred to as hard logic.

Dependency Item – A product, action, piece of information, etc., that must be provided by one individual or group to a second individual or group so they can perform a planned task.

DFA – Department of Finance and Administration

DoIT – Department of Information Technology

Duration – The number of work periods (not including holidays or other nonworking periods) required to complete an activity or other project element.

Duration Compression – Shortening the project schedule without reducing the project scope. Often increases the project cost.

- E -

Effort – The number of labor units required to complete an activity or other project element. Usually expressed as staff hours, staff days, or staff weeks.

Empowerment – SME’s participating in the Business Requirements Definition Sessions are authorized to make design decisions for the deployment of RMIS software modules with the exception of:: (1) decisions in violation of statute; (2) decisions that violate management-bargaining unit agreements; (3) decisions that commit additional funds; and (4) decisions that violate established, jurisdictional boundaries

End User – The individual or group who will use the system for its intended operational use when it is deployed in its environment.

ERP – Enterprise Resource Planning System (see COTS)

- F -

FA – Functional Administrator

Fast Tracking – Compressing the project schedule by overlapping activities that would normally be done in sequence, such as design and construction.

Float – The amount of time that an activity may be delayed from its early start without delaying the project-finished date.

Formal Review – A formal meeting at which a product is presented to the end user, customer, or other interested parties for comment and approval. It can also be a review of the management and technical activities and of the progress of the project.

FS – Funding Source

PAGE | 57

- G -

GSD – General Services Department

- H -

No entries at this time

- I -

Integrated Project Plan – A plan created by the project manager reflecting all approved projects and sub-projects.

IPS – Integrated Project Schedule; a master schedule created by the project manager reflecting all approved project activities of the main project and sub-projects.

Issues Log – Similar to the action log, the issues log is an extension of the project plan. The issue log will be updated as needed throughout the week. An issue differs from an action in severity and the amount of effort required to resolve. An issue, if left unresolved would have a significant adverse impact on the project. Typically, the resolution to an issue is not known at the time it is created and the issue owner must develop a solution. The project issue log will be updated as needed by submitting an update form to the project manager. The issue log will be maintained in a MS-Word table.

IWA – Internal Work Agreement (or Amendment)

- J –


- K –

KPI – Key Performance Indicator

- L -

Lessons Learned – The learning gained from the process of performing the project. Lessons learned may be identified at any point during the execution of the project.

LFC – Legislative Finance Committee

- M -

Method – A reasonably complete set of rules and criteria that establish a precise and repeatable way of performing a task and arriving at a desired result.

Methodology – A collection of methods, procedures, and standards that defines an integrated synthesis of engineering approaches to the development of a product.

Milestone – A scheduled event for which some individual is accountable and that is used to measure progress.

PAGE | 58

- N -

NMAC – New Mexico Administrative Code

NMSA – New Mexico Statutes Annotated

Non-technical Requirements – Agreements, conditions, and/or contractual terms that affect and determine the management activities of an architectural and software project.

NTP – Notice to Proceed

- O -

OBS – Organizational Breakdown Structure

OCIO – Office of the Chief Information Officer

OOS – Office of the Secretary

- P -

PCC – Project Certification Committee

Performance Reporting – Collecting and disseminating performance information. This includes status reporting measurement, and forecasting.

PMBOK – Project Management Body of Knowledge

PMI – Project Management Institute

PMP – Project Management Plan

PO – Purchase Order

PR – Purchase Requisition

Procurement Planning – Determining what to procure and when.

Product Scope – The features and functions that characterize a product or service.

Program – A group of related projects managed in a coordinated way. Programs include an element of ongoing work.

Project Change Request forms – A PCR (Project Change Request) is a request for change on the project. It has two parts, one for estimating the cost to investigate the PCR, the other to determine how much the PCR will cost to implement. All project changes require an approved PCR. Typically, this involves a change to the project schedule, budget, or scope.

Project Charter – A document issued by senior management that formally authorizes the existence of a project. It provides the project manager with the authority to apply organizational resources to project activities.

Project Leader (Technical) – The leader of a technical team for a specific set of tasks. Typically referred to as the Technical Lead, they have technical responsibility, and provide technical direction to the staff working on the tasks.

PAGE | 59

Project Management – The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project Management is also responsible for the oversight of the development and delivery of the architecture and software project.

Project Manager – The role with total business responsibility for an entire project. The individual who directs, controls, administers, and regulates a project. The project manager is the individual ultimately responsible to the customer.

Program Management Office (PMO) – An organizational entity responsible for management and oversight of the organization’s projects. As a specific reference in this document, the Office of the Chief Information Officer.

Project Management Plan (PMP) – A formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and documents approved scope, cost, and schedule baselines. The Project Management Plan (PMP) is a project plan.

Project Schedule – A tool used to indicate the planned dates, dependencies, and assigned resources for performing activities and for meeting milestones. Software products such as ABT’s Workbench and Microsoft Project are tools used to develop project schedules.

Project Scope – The work that must be done to deliver a product with the specified features and functions.

Project Sponsor – The individual that provides the primary sponsorship for an approved project. This individual will play a key role in securing funding, negotiating for resources, facilitating resolution of critical organizational issues, and approving key project deliverables.

- Q -

QMP – Quality Management Plan

Quality – The degree to which a system, component, or process meets specified requirements. The degree to which a system, component, or process meets customer or user needs or expectations. [IEEE-STD-610]

Quality Management – The process of monitoring specific project results to determine if they comply with relevant standards and identifying ways to eliminate causes of product non-compliance.

- R -

RFP – Request for Proposal

Risk – Possibility of suffering loss.

Risk Management – An approach to problem analysis, which weighs risk in a situation by using risk probabilities to give a more accurate understanding of, the risks involved. Risk

PAGE | 60

Management includes risk identification, analysis, prioritization, and control. Risk mitigation seeks to reduce the probability and/ or impact of a risk to below an acceptable threshold.

Risk Management Plan – The collection of plans that describes the Risk Management activities to be performed on a project.

RMD – Risk Management Division.

RMIS – Risk Management Information System.

- S -

SA – Systems Administrator

Scope Change – Any change to the project scope. A scope change usually requires an adjustment to the project cost or schedule.

SLA – Service Level Agreement

SHARE – Statewide Human Resources, Accounting, and Reporting. The State of New Mexico’s PeopleSoft-based Enterprise Resource Planning System used by the General Services Department Risk Management Division.

SME – Subject Matter Expert. A member of an organization acknowledged as an authority in a particular area or topic.

Software Life Cycle – The period that begins when a software product is conceived and ends when the software is no longer available for use. The Software Life Cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation, and checkout phase, operation and maintenance phase, and, sometimes, retirement phase.

SOP – Standard Operating Procedure

SPD – State Purchasing Division

Stakeholder – Individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected because of project execution or project completion. They may also exert influence over the project and its results.

Standard – Mandatory requirements employed and enforced to prescribe a disciplined uniform approach to software development.

Statement of Work – The Statement of Work (SOW) is the contractual agreement that defines the project objectives, expectations and scope. Each project member should be familiar with the SOW particularly as it relates to project scope and the definition of completion for each major deliverable.

PAGE | 61

System Requirements – A condition or capability that must be met or possessed by a system component to satisfy a condition or capability needed by a user to solve a problem. [IEEE-STD-610]

Subproject – A smaller portion of the overall project.

- T -

Task – A sequence of instructions treated as a basic unit of work. [IEEE-STD-610] A well-defined unit of work in the software process that provides management with a visible checkpoint into the status of the project. Tasks have readiness criteria (preconditions) and completion criteria (post conditions). Please refer to activity for contrast.

Task Assignment Sheets – Where applicable, the project manager will provide a detailed outline of the specific steps required to complete an assigned task. The Task Assignment Sheet provides much greater detail and specificity than the project schedule. In some cases a single project schedule task may be broken down into fifteen or more steps to complete. Where practical this Task Assignment Sheet will be developed in MS Word and distributed in hard copy prior to opening the new task. In addition, the project manager will hold a coaching session at the start of each task to review the task assignment.

TCM – Total Cost of Maintenance

TCO – Total Cost of Ownership

Team – A collection of people, often drawn from diverse but related groups, assigned to perform a well-defined function for an organization or a project. Team members may be part-time participants of the team and have other primary responsibilities.

Technical Requirements – Requirements that describe what the software must do and its operational constraints. Examples of technical requirements include functional, performance, interface, and quality requirements.

Traceability – The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another. [IEEE-STD-610]

TSSB – Technology & Systems Support Bureau

- U -UAT – User Acceptance Test

- V –


- W -

PAGE | 62

WBS – Work Breakdown Structure: a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work.

WCA – Workers Compensation Administration

- X, Y, and Z


PAGE | 63


APPENDIX B – DELIVERABLE ACCEPTANCE FORM

DELIVERABLE ACCEPTANCE FORM

GSD RMIS REPLACEMENT PROJECT

NAME OF VENDOR SUBMITTING DELIVERABLE:

CONTRACT NUMBER:

CONTRACT DELIVERABLE NUMBER:

DELIVERABLE DESCRIPTION:

ACCEPTANCE CRITERIA:

Project Manager Acceptance

Approved Disapproved

Name Signature Date

Business Owner Acceptance

Approved Disapproved

Name Signature Date

Remarks:

PAGE | 64


APPENDIX C – DELIVERABLE ACCEPTANCE LOG

DELIVERABLE ACCEPTANCE LOG

GSD RMIS REPLACEMENT PROJECT

Date Submitted

Vendor submitting

Deliverable

Contract Number

Deliverable Number

Approved or Rejected

Date of Action

Approved or Rejected by

PAGE | 65


APPENDIX D – PROJECT SCHEDULE

PAGE | 66


Task:

PCC Project InitiationPCC Project PlanningPCC Project ImplementationPCC Project Closeout

BA Contract DevelopmentIV&V Contract Development

Develop PCC Project CharterDevelop PCC Project Management PlanDevelop PCC Planning RequestDevelop PCC Planning Request PowerPointBA Contract Approval & Signature ProcessIV&V Contract Approval & Signature ProcessRM Consultants Contract Development

IV&V Initital AssessmentBA - Deliverable 1 - BA Work PlanRM Consultants Contract Approval & Signature Process

IV&V Interim Report #1RM Consultants RFP Development

IV&V Interim Report #2RM Consultants RFP DevelopmentBA - Deliverable 2 - Sub 1 - Product Market Research and AnalyBA - Deliverable 2 - Sub 2 - Requirements Gathering AnalysisBA - Deliverable 2 - Sub 3 - As-Is Business workflowBA - Deliverable 2 - Sub 4 - As-Is Process Maps/Use CasesBA - Deliverable 2 - Sub 5 - Requirements Traceability Matrix

IV&V Interim Report #3RM Consultants RFP DevelopmentRFP Development - Business RequirementsRFP Development - Technical RequirementsRFP Development - Scoring RequirementsDevelop RFP Finalist Presentation Criteria

IV&V Interim Report #4RFP Evaluation Team FormationRFP Review by DoITRFP Review by State Purchasing

IV&V Interim Report #5

IV&V Interim Report #6RFP Publication

RFP Responses due back to GSD RMDIV&V Interim Report #7RFP Proposal Evaluation

IV&V Interim Report #8RFP Finalist PresentationsRFP Best & Final Offers

IV&V Interim Report #9RFP AwardDevelop RMIS TARC Documentation

IV&V Interim Report #10RMIS TARC PresentationDevelop - DoIT PCC Implementation RequestDevelop - PCC Implementation Request PowerPoint Presentati

PAGE | 67


APPENDIX E – PROJECT BUDGET

PAGE | 68


Type

Description Vendor

RMIS Software Licensing *TBD $ 519,282.00 $ - $ - $ 519,282.00 $ - $ - $ - $ - $ -

Prof Services *TBD $ 150,000.00 $ - $ - $ 150,000.00 $ - $ - $ - $ - $ -

Prof Services Implementation Vendor Training *TBD $ 15,000.00 $ - $ - $ 15,000.00 $ - $ - $ - $ - $ - Prof Services RESPEC $ 74,218.00 $ - $ 74,218.00 $ - $ - $ - $ - $ - $ -

Prof Services Project Management Services - FY18 CSW Enterprises $ 11,800.00 $ 11,800.00 $ - $ - $ - $ - $ - $ - $ - Prof Services Project Management Services - FY19 *TBD $ 138,200.00 $ - $ 138,200.00 $ - $ - $ - $ - $ - $ - Prof Services Project Management Services - FY20 *TBD $ 140,000.00 $ - $ 140,000.00 $ - $ - $ - $ - $ - Prof Services Project Management Services - FY21 *TBD $ 10,000.00 $ - $ - $ 10,000.00 $ - $ - $ - $ - Prof Services *TBD $ 37,480.00 $ - $ 37,480.00 $ - $ - $ - $ - $ - $ -

Prof Services *TBD $ 39,120.00 $ - $ - $ 39,120.00 $ - $ - $ - $ - $ -

Prof Services *TBD $ 11,400.00 $ - $ - $ - $ 11,400.00 $ - $ - $ - $ -

Prof Services *TBD $ 219,250.00 $ - $ 219,250.00 $ - $ - $ - $ - $ - $ -

Prof Services RMIS Software Interfaces Several Vendors $ 89,250.00 $ - $ - $ 89,250.00 $ - $ - $ - $ - $ - Contingency Project Contingency - ~3 percent *TBD $ 45,000.00 $ - $ - $ 45,000.00 $ - $ - $ - $ - $ -

Total Amounts $ 1,500,000.00 $ 11,800.00 $ 469,148.00 $ 997,652.00 $ 21,400.00 $0.00 $0.00 $0.00

Project Appropriation History Amount Total DoIT PCC Certified/Non-Certified Balances AmountLaws of 2017, Chapter 135, Section 7 Subsection 3, Item 8 $250,000.00 Appropriation Amount $250,000.00

DoIT PCC Certified Funds $129,000.00

Total Appropriation $250,000.00 DoIT PCC Uncertified Balance $121,000.00DoIT PCC Certification History Amount Project Certified Funds Balance Amount February 28, 2018 $129,000.00 Total DoIT PCC Certified Funds $129,000.00 Total Expenses (Inception to date) $0.00 Balance of DoIT PCC Certified Funds $129,000.00 Project Unfunded Amounts Amount

Total Appropriated Funds $250,000.00

Total Projected Expenses for Project $1,500,000.00

Total DoIT PCC Certified Funds $129,000.00 Total Unfunded Amount -$1,250,000.00Total Appropriated Funds Balance Amount Budget Allocation by Fiscal Year Amount

Total Appropriation $250,000.00 FY18 Appropriated Funds (From Original C2 request in FY2014) $250,000.00

Total Expenditures - Inception-to-date$0.00

$230,948.00

Appropriation Balance $250,000.00 FY20 C2-Request (GSD Enterprise Funds) $1,019,052.00

Total Budget Allocation by Fiscal Year $1,500,000.00

Total Projected Expenses

FY18 Projected Expenses




FY18 Actual Expenses




Software Licensing

Data Conversion and RMIS Software Implementation Services

Business Analyst - Define and document existing Risk Management business processes

Independent Validation & Verification Services - FY19



Risk Management - System Procurement and Industry Best-Practices Consultants

FY19 Operating Budget - GSD Enterprise Funds (Property - Fund 35603, Liability-Fund 35703 and Workers’ Compensation Fund 35903)

PAGE | 69