General Services Department
Risk Management Division
Risk Management Information System
PROJECT MANAGEMENT PLAN
Executive Sponsor
Arturo Jaramillo, GSD Cabinet Secretary
Mike Wilson, Risk Management Division Director
Business Owner
George McGeorge
Project Manager
Jon King/POD, Inc
GSD Chief Information Officer
Karen Baltzley
Original Plan Date: February, 2007
Revision Date: December 10, 2008
Revision: 1.9
Table of Contents
Project Management Plan for Risk Management Information System
Revision History
Preparing the Project Management plan
1.0 Project Overview
Executive Summary- rationale for the Project
1.2 funding and sources
1.3 constraints
1.4 dependencies
1.5 ASSUMPTIONS
1.6 Initial Project Risks Identified
2.0 Project Authority and Organizational Structure
2.1 Stakeholders
2.2 Project Governance Structure
2.2.2 Describe the role and members of the project steering committee
2.2.3 Organizational Boundaries, interfaces and responsibilities
2.3 Executive Reporting
3.0 Scope
3.1 Project Objectives
3.1.1 Business Objectives
3.1.2 Technical Objectives
3.2 Project exclusions
3.3 Critical Success Factors
4.0 Project Deliverables and methodology
4.1 Project Management Life Cycle
4.1.1 Project Management Deliverables
4.1.2 Deliverable Approval Authority Designations
4.1.3 Deliverable Acceptance Procedure
4.2 PRODUCT LIFE CYCLE
4.2.1 Technical Strategy
4.2.2 Product and Product Development Deliverables
4.2.3 Deliverable Approval Authority Designations.
4.2.4 Deliverable Acceptance Procedure
5.0 Project Work
5.1 Work Breakdown Structure (WBS)
5.2 Schedule allocation -Project Timeline
5.3 Project Budget
5.4 Project Team
5.4.1 Project Team Organizational Structure
5.4.2 Project Team Roles and Responsibilities
5.5 STAFF PLANNING AND Resource ACQUISITION
5.5.1 Project Staff
5.5.2 Non-Personnel resources
5.6 PROJECT LOGISTICS
5.6.1 Project Team Training
6.0 Project Management and Controls
6.1 Risk and issue Management
6.1.1 Risk Management Strategy
6.1.2 Project Risk Identification
6.1.3 Project Risk Mitigation Approach
6.1.4 Risk Reporting and Escalation Strategy
6.1.5 Project Risk Tracking Approach
6.1.6 ISSUE MANAGEMENT
6.2 INDEPENDENT Verification And Validation - Iv&V
6.3 Scope Management Plan
6.3.1 Change Control
6.4 Project Budget Management
6.4.1 Budget Tracking
6.5 Communication Plan
6.5.1 Communication Matrix
6.5.2 Status Meetings
6.5.3 Project Status Reports
6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)
6.6.1 Baselines
6.7 QUALITY OBJECTIVES AND CONTROL
6.7.1 quality Standards
6.7.2 Project and Product Review AND ASSESSMENTS
6.7.3 Agency/Customer Satisfaction
6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS
6.8 CONFIGURATION MANAGEMENT
6.8.1 Version Control
6.8.2 Project Repository (Project Library)
6.9 PROCUREMENT MANAGEMENT PLAN
7. 0 Project Close
7.1 Administrative Close
7.2 Contract Close
appendices
Appendix A
APPENDIX B
APPENDIX C
Appendix D
Appendix E
APPENDIX F
Revision History
Revision Number / Date / Comment1.0 / December 11, 2007 / GSD/RMD Revision
1.1 / December 20, 2007 / GSD/RMD Revision
1.2 / February, 2008 / Karen Baltzley Revision
1.3 / July, 2008 / GSD/RMD Revision
1.4 / September, 2008 / Karen Baltzley Revision
1.5 / December 03, 2008 / Jon King/POD
1.6 / December 4, 2008 / Jon King/POD
1.7 / December 9, 2008 / Karen Baltzley/GSD Revision
1.8 / December 9, 2008 / Karen Baltzley/Jon King
1.9 / December 10, 2008 / Karen Baltzley/Jon King
Preparing the Project Management plan
Revision: 1.9DoIT-PMO-TEM-0201 of vi
Project Management Plan for Risk Management Information System
1.0 Project Overview
Executive Summary- rationale for the Project
The Risk Management Information System (RMIS) is a claim management and data analysis software tool used in the insurance industry. Data stored in the Risk Management Division (RMD) RMIS consists of technical and financial histories of 200,000 claims encompassing 11 lines of coverage provided to state agencies by GSD/RMD. The RMIS needs to interface with SHARE and the GSD/ASD financial programs to allow for financial audit of expenditures made against the RMD retention funds through claim payments. The current system is seven years old and has limited capabilities. RMD will fund the software through an appropriation of enterprise funds.
The RMD has a pressing need for a Claims RMIS with high quality processing and analysis capabilities. The industry standard technology products are to meet RMD’s anticipated business needs over the next 5 years.
The current ATS RMIS proprietary system was implemented in October, 2000. For the past 3 years, the annual maintenance and application development support has been handled as a sole source contract. State Purchasing has notified Risk Management Division that they will not approve another Sole Source contract for this system support and will require that RMD release a Request for Proposal to procure another system contract before the end of FY2009.
Business Application Requirements
- Claims Risk Management Information System- RMD requires claims processing and analysis for 11 lines of insurance coverage including workers compensation, property, casualty, civil rights and torts. The current system is inefficient and outdated, and needs major enhancement or replacement.
Business Risks
- RMIS - The lack of an adequate claims management system jeopardizes RMD’s ability to meet statutory obligation for timely claims payments and Federal, Workers Compensation Administration reporting requirements. Without a demonstrated pattern and practice of timely claim payments, RMD could be subject to potential maximum penalties of over $20 million a year for workers’ compensation for insufficient reporting and processing alone.
Business Problem/ Opportunity
Without a functioning RMIS, RMD will not meet the obligation imposed by statute, or court ordered settlements, for timely paymentsof amounts owed claims. The most recent calculation performed by RMD indicates a maximum penalty of over $20 million annually for the workers’ compensation coverage alone, if RMD cannot demonstrate a pattern and practice of issuing timely payments. The opportunity is to improve claim handling, claim payment, and loss trend analysis capabilities through enhancement of the existing system or replacement with one possessing needed capabilities.
RMD made a partial payment of $500,000 for penalty and interest because of untimely and non-filing federal and state taxes.
1.2 funding and sources
Source / Amount / Associated restrictions / ApproversLaws of 2007, Chap 28, Section 7, Subsection 8 / 2.3 – (Includes ECM, RMIS, MCDAT (DataWarehouse))
RMIS – estimated @$750K / None
1.3 constraints
Number / Description1 / Project budget for implementation of the base program is limited. Funding will not be re-authorized at the end of FY10.
2 / Customization of disabilities program does not have a budget
3 / RMIS vendor will adopt RMD system definitions and nomenclature to minimize customization costs.
4 / Current contract expires before implementation of a new system
5 / Contract/amendment approval time
6 / WCA, DFA, DoITHCM technical teams time to respond and define interface requirements
7 / Network design to allow for public facing system and providing high security levels
1.4 dependencies
Types include the following and should be associated with each dependency listed.
- 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 / DFA Financial Technical Support / M
2 / SPD Business process Re-Engineering / M
3 / SHARE System Processing Capacity large enough to accommodate new modules / M
4 / Department of Information Technology Project Oversight Committee approval of Project certification phases to support on-going project effort / M
5 / Infrastructure design and availability. / E
6 / Contract Approval and purchase for software and maintenance. / E
7 / Funding for software maintenance, implementation and on-going support of system. / M
8 / Data conversion and mapping from existing database’s to new RMIS system. / M
9 / Develop Operating Standards Maintenance standards manual. / M
10 / Certification of system. / M
11 / Application server procurement and installation / M
12 / Installation of application server / M
13 / Development of Universe and implementation of Crystal Reports/WEBi software / M
14 / Export of canned reports from MyEureka / M
15 / RMIS RFP released on schedule to allow adequate time for implementation and acceptance of new system / M
1.5 ASSUMPTIONS
Number / Description1 / System will integrate with DoIT infrastructure
2 / Data will be easily migrated and without corruption or loss.
3 / Vendor will honor contractual obligations.
4 / Software will integrate with PeopleSoft software
5 / Adequate Budget will be available.
6 / Adequate staffing levels with the proper skill sets necessary to ensure the system will perform at level expected.
7 / Staff is trained properly on the operation of the system to ensure continued success of the program.
8 / Vendor will continue to support software and release upgrades/patches on a regular basis.
9 / Business Requirements will have minimal change over the life cycle of the project.
1.6 Initial Project Risks Identified
Risk 1
Description - Insufficient funds appropriated to support this project; / Probability: Low / Impact:Medium1) May be forced to implement application modules in a phased manner. 2) Divisions may be unable to meet statutory requirements, 3) customer agency needs may not be completely met, and 4) procurement efficiency will be negatively impactedMitigation Strategy: Need to prioritize required functionality and focus efforts on highest impact areas.
Contingency Plan: Worst case – continue with client/server architecture, request sole source renewal with current vendor and continue on an annual maintenance agreement; Most likely case, implement a subset of functionality.
Risk 2
Description - A large, comprehensive database and GUI application screens requires users that are trained and experienced. / Probability - High / Impact - Medium 1) may be forced to delay “go-live” date 2) may require additional training at additional costsMitigation Strategy – Provide on-site, hands on user training for all modules housed on test/development server.
Contingency Plan - expand training window, delay “go-live” date
Risk 3
Description – Technical/Functional staff inexperience, lack of training / Probability - Medium / Impact – Medium 1) longer learning curve resulting in longer timeline for production, 2) may require additional training at additional costsMitigation Strategy - Send key staff to additional training by vendor. Hire staff with experience and required skill sets
Contingency Plan - If we lose key staff or do not hire those with needed skill set we will hire contractual or temporary staff with database experience
Risk 4
Description - Inability to generate necessary adhoc and custom management reports / Probability - Medium / Impact – HighMitigation Strategy - Send key staff to Crystal Report/WEBi Training by Business Objects so that we have reporting capability within our organization.
Contingency Plan - If we lose key staff, hire contractual or temporary staff with database experience
Risk 5
Description – RMISconfiguration changes on Test server not completed/fail. Changes are not done on time or fail, the project timeline extends. / Probability - Medium / Impact – HighMitigation Strategy - Vendor to ensure that configuration changes are successfully completed within project timeline
Contingency Plan - Continue operations with legacy systems
Risk 6
Description – RMIS configuration changes on client training systems not completed/fail. If changes are not done on time or fail ,project timeline extends / Probability - Medium / Impact – MediumMitigation Strategy - GSD to ensure that configuration changes on client training systems are successfully completed within project timeline
Contingency Plan - Move training date
Risk 7
Description - client testing against Migrated Application and Database Instance test server not complete/fails / Probability - Medium / Impact – HighMitigation Strategy - GSD to ensure that testing on client training systems are successfully completed within project timeline
Contingency Plan - Move Go Live Date
Risk 8
Description - All testing issues are not resolved within project timeline / Probability - Low / Impact – HighMitigation Strategy - Ensure that all issues/changes are addressed by vendor and GSD technical staff
Contingency Plan - Move Go Live Date, Conduct weekly status conference calls with vendor and project team
Risk 9
Description – RMIS Database migration to SQL2005 Server could cause system instability and inability to implement utilities module and upgrade software version / Probability - Low / Impact – HighMitigation Strategy - Significant degradation of software and system performance would require roll back to previous application level
Contingency Plan - roll back to previous operating system level
Risk 10
Description – Insufficient system/database back-up before migration / Probability - Low / Impact – HighMitigation Strategy - Conduct data restoration test.
Contingency Plan - Keep legacy systems in operation mode for fall back
Risk 11
Description - Production install of RMIS creates software instability in environment (apps incompatibility issues) / Probability - Medium / Impact – HighMitigation Strategy - RMIS rolled back to legacy system. Incompatible apps are evaluated and/upgraded or removed
Contingency Plan - Keep legacy systems in operation mode for fall back
Risk 12
Description – Data migration takes longer than planned / Probability – Medium/High / Impact – HighMitigation Strategy - GSD to ensure correct data mapping is provided to vendor. Vendor commitment to supply within agreed scheduled dates
Contingency Plan - Move Go Live Date, Conduct weekly status conference calls with vendor and project team
Risk 13
Description –Legacy data cannot be converted entirely / Probability - Medium / Impact – LowMitigation Strategy –GSD to work with vendor during evaluation
Contingency Plan - Keep Legacy data on current SQL platform for reporting
2.0 Project Authority and Organizational Structure
2.1 Stakeholders
name / Stake in Project / Organization / TitleArturo Jaramillo, / Program financial responsibility / General services department (GSD) / cabinet secretary
Mike wilson / program administration responsibility / gsd, risk management division / Project Sponsor
Ed romero / program administration responsibility / GSD Finance / Deputy Director of Finance
George McGeorge / Business Owner / GSD Finance / Deputy Director of Finance
Karen Baltzley / Project Director / GSD / GSD CIO
Jeffrey Granger / Project oversight / GSD / GSD Project Manager
Steve mindham / Project team advisor / gsd, risk management division
ida spence / workers compensation administration responsibility / gsd, risk management division / Bureau chief
Gerald Rodriguez / RMIS system administration / gsd, risk management division / Bureau chief
Velma Herrera / Property and Casualty Claims / Property and Casualty / Bureau chief
Claudia Melendrez-rel / Benefits enrollment and payments / benefits / bureau chief
nancy bearce / benefits enrollment and payments / benefits / bureau chief
Marcia Ronquillo / Legal / GSD,Risk Management
gary graves / share hcm benefits / department of information technology / Application Developer
David Vilar, Ryan Woodard / technical support of systems / technology and system support / Lead GSD/ System Support
End-User Focus Groups / Providers / UNM, NMSU, WCA
Interagency Benefits Advisory Committee / Users / IBAC
Jon King / contractor Project manager / POD
TBD / Contractor IV&V / TBD
2.2 Project Governance Structure
2.2.1 Organizational Chart
2.2.2 Describe the role and members of the project steering committee
Steering Committee Member / Is chartered to provide governance over the direction and support of the project.Responsibilities include:
- Attend and participate in meetings
- Review and accept deliverables
- Review and provide comment on presented documentation
- Balance larger picture versus details of the project
- Review project funding and expenditures
- Champion the project
- Contributes to lessons learned
2.2.3 Organizational Boundaries, interfaces and responsibilities
The Project Manager will interface with the Business Owner, Project Director, Steering Committee and the Business Operations Review team members via Status Report, weekly and ad-hoc meetings, e-mail and phone conversations. Overall task direction will come from the Project Manager and final decisions will be made at the Steering Committee level.
2.3 Executive Reporting
Meetings will be conducted with GSD Management and project teams on a regularly scheduled basis.
Whiteboard sessions outlining project task and resource assignment schedules and agendas are conducted throughout the process and transferred to Microsoft project.
Project team meetings are scheduled to coincide with the Vendor Implementation/Design teams for on-site implementation sessions. Frequency and length of meetings to be defined.
Project status updates reports will be provided weekly to Business Owners conducted at weekly staff meetings.
GSD management will be kept informed on progress of the project periodically throughout the project life cycle.
Special oral and written Project Management and IV&V reports will be given on project progress to the RMIS Steering Committee.
3.0 Scope
The scope of this project is to fully implement and put into production a Risk Management Information (Claims) System that will address the current business requirements of the Risk management Division Bureaus; Workers Compensation, Loss Control, Property and Casualty, Benefits, Legal. The system will be open architecture with a web-front end and will be capable of interfacing with SHARE and GSD/ASD financial systems.
3.1 Project Objectives
3.1.1 Business Objectives
Business Objective 1 / System functionality will be able to handle administration of more than one type of claim. The types of claims that can be handled will include Workers Compensation, General Liability and Property. The system will be able to handle the types of claims handled by the current system except for DisabilitiesBusiness Objective 2 / System will comply with EDI (electronic data interface) standards, HIPAA, Regulatory Claim Reporting (State Reporting, 1099s)
Business Objective 3 / System functionality will be customizable and will allow the state to upgrade or improve functionality over time; Safety & Loss Control, Reporting Structure, Litigation Management, Claims Administration Management
Business Objective 4 / System will enable Actuarial, Trend Analyses and Carrier evaluation Capabilities
Business Objective 5 / Robust Data Mining capabilities for better reporting and data management. Utilize the internet to send out reports to the field
Business Objective 6 / Streamline traditional claims inefficiencies and reduce manual, paper-based processes, which contribute to high claims costs and overhead expenses.
Business Objective 7 / Perform real-time concurrent reviews of 100 percent of claims, to enable a higher level of claims-handling performance for internal and external sources (medical carriers, attorneys). The audit findings will allow claims managers to fine-tune operations, achieve a tighter lifecycle and ensure cost-containment at key junctures of the claims process.
3.1.2 Technical Objectives
Number / DescriptionTechnical Objective 1 / Web-Based System - will be designed on a public facing network with a web based Java platform front-end to allow RMD staff and vendor remote access
Technical Objective 2 / System will provide Web-based incident reporting, Standard reports, Ad hoc reporting generator utilizing industry standard tools.
Technical Objective 3 / Monitoring - System will provide notifications, alerts and events on a web-based dashboard.
Technical Objective 4 / Dashboard - System will provide dashboard to include a minimum of a listing of smart prioritization of tasks, ability to post messages to users when they log into system, display important information automatically from reports that run on a scheduled basis.
Technical Objective 5 / Interfaces - System will interface to external carrier systems (Third Party Administrators (TPA), Property & Casualty Database (PRDP), GSD and SHARE Financial system(s))
Technical Objective 6 / System will provide intelligent online forms (smart forms) that use drop-down lists, auto-populated fields and threads of logic to easily navigate users through the electronic claim submission process. System will provide Claim email automation tool to combine automated form and letter generation with email routing capabilities from the claims file.
Technical Objective 7 / System Integration - Provide an architecture that will easily integrate legacy systems into a comprehensive system without customization.
Technical Objective 8 / Open Architecture - Provide an open architecture infrastructure that will interface with Crystal Reports software and scalable to allow for growth.
technical objective 9 / Database Standards - System database will follow GSD supported platform standards of SQL, My SQL
technical objective 10 / Efficiency, High Performance – Application will be server independent and can be deployed on an open source application server such as Apache Tomcat
technical objective 11 / Authentication - System will support Microsoft Active Directory
technical objective 12 / Systems Integration - System will be connected to Hitachi SAN
technical objective 13 / Redundancy - System will be configured to support system fail over
technical objective 14 / Security/User Roles - System will support a secure front end user system log in and security role level authentication
3.2 Project exclusions
No exclusion