preparing the project management plan

NNEWEW M MEXICOEXICO D DEPARTMENTEPARTMENT OFOF H HEALTHEALTH

PPUBLICUBLIC H HEALTHEALTH D DIVISIONIVISION

BBILLINGILLING ANDAND E ELECTRONICLECTRONIC H HEALTHEALTH RRECORDECORD (BEHR) U (BEHR) UPGRADEPGRADE

PROJECT MANAGEMENT PLAN PROJECT MANAGEMENT PLAN (PMP)(PMP)

EXECUTIVE SPONSOR – JANE PEACOCK, MSDIRECTOR, PUBLIC HEALTH DIVISION

BUSINESS OWNER - MAGGI GALLAHER, MD, MPHMEDICAL DIRECTOR, PUBLIC HEALTH DIVISION

PROJECT MANAGER – MICHAEL SNOUFFER

ORIGINAL PLAN DATE: SEPTEMBER 3, 2013REVISION DATE: N/A

REVISION: 1.0

PROJECT MANAGEMENT PLAN FOR [PROJECT NAME]

RREVISIONEVISION H HISTORYISTORY.................................................................................................................................................................................................. IIIIII

PREPARING THE PROJECT MANAGEMENT PLAN................................................................................................. IV

ABOUT THIS DOCUMENT................................................................................................................................... IV

Project Oversight Process Memorandum – DoIT, July 2007...................................................................................iv

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

1.1 Executive Summary- rationale for the Project...................................................................................................11.2 funding and sources..........................................................................................................................................11.3 constraints.........................................................................................................................................................11.4 dependencies....................................................................................................................................................11.5 ASSUMPTIONS...................................................................................................................................................11.6 Initial Project Risks Identified..........................................................................................................................2

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE.............................................................................2

2.1 Stakeholders......................................................................................................................................................22.2 Project Governance Structure...........................................................................................................................3

2.2.1 Describe the organizational structure – Org Chart.....................................................................................32.2.2 Describe the role and members of the project steering committee...........................................................32.2.3 Organizational Boundaries, interfaces and responsibilities.......................................................................3

2.3 Executive Reporting...........................................................................................................................................3

3.0 SCOPE........................................................................................................................................................... 3

3.1 Project Objectives.............................................................................................................................................33.1.1 Business Objectives....................................................................................................................................33.1.2 Technical Objectives..................................................................................................................................3

3.2 Project exclusions..............................................................................................................................................33.3 Critical Success Factors......................................................................................................................................4

4.0 PROJECT DELIVERABLES AND METHODOLOGY...............................................................................................4

4.1 Project Management Life Cycle.........................................................................................................................44.1.1 Project Management Deliverables.............................................................................................................44.1.2 Deliverable Approval Authority Designations............................................................................................54.1.3 Deliverable Acceptance Procedure.............................................................................................................5

4.2 PRODUCT LIFE CYCLE.........................................................................................................................................54.2.1 Technical Strategy.....................................................................................................................................54.2.2 Product and Product Development Deliverables........................................................................................64.2.3 Deliverable Approval Authority Designations............................................................................................64.2.4 Deliverable Acceptance Procedure.............................................................................................................6

5.0 PROJECT WORK............................................................................................................................................. 6

5.1 Work Breakdown Structure (WBS)....................................................................................................................65.2 Schedule allocation -Project Timeline...............................................................................................................75.3 Project Budget...................................................................................................................................................75.4 Project Team.....................................................................................................................................................8

5.4.1 Project Team Organizational Structure......................................................................................................85.4.2 Project Team Roles and Responsibilities....................................................................................................9

5.5 STAFF PLANNING AND Resource ACQUISITION.................................................................................................95.5.1 Project Staff...............................................................................................................................................95.5.2 Non-Personnel resources...........................................................................................................................9

5.6 PROJECT LOGISTICS.........................................................................................................................................10

REVISION: 1.0 DOIT-PMO-TEM-020 I OF VI


5.6.1 Project Team Training..............................................................................................................................10

6.0 PROJECT MANAGEMENT AND CONTROLS....................................................................................................10

6.1 Risk and issue Management............................................................................................................................106.1.1 Risk Management Strategy......................................................................................................................116.1.2 Project Risk Identification........................................................................................................................116.1.3 Project Risk Mitigation Approach............................................................................................................116.1.4 Risk Reporting and Escalation Strategy...................................................................................................116.1.5 Project Risk Tracking Approach................................................................................................................116.1.6 ISSUE MANAGEMENT..............................................................................................................................11

6.2 INDEPENDENT Verification And Validation - Iv&V...........................................................................................116.3 Scope Management Plan.................................................................................................................................11

6.3.1 Change Control........................................................................................................................................126.4 Project Budget Management..........................................................................................................................12

6.4.1 Budget Tracking.......................................................................................................................................126.5 Communication Plan.......................................................................................................................................12

6.5.1 Communication Matrix............................................................................................................................126.5.2 Status Meetings.......................................................................................................................................126.5.3 Project Status Reports..............................................................................................................................12

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS).....................................................................................126.6.1 Baselines..................................................................................................................................................136.6.2 Metrics Library.........................................................................................................................................13

6.7 QUALITY OBJECTIVES AND CONTROL..............................................................................................................136.7.1 quality Standards.....................................................................................................................................136.7.2 Project and Product Review AND ASSESSMENTS.....................................................................................146.7.3 Agency/Customer Satisfaction.................................................................................................................146.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS......................................................................................14

6.8 CONFIGURATION MANAGEMENT...................................................................................................................156.8.1 Version Control........................................................................................................................................156.8.2 Project Repository (Project Library).........................................................................................................15

6.9 PROCUREMENT MANAGEMENT PLAN............................................................................................................15

7. 0 PROJECT CLOSE........................................................................................................................................... 15

7.1 Administrative Close...................................................................................................................................167.2 Contract Close.............................................................................................................................................16

AttachmentS..............................................................................................................................................................16

REVISION: 1.0 DOIT-PMO-TEM-020 II OF VI


REVISION HISTORYREVISION HISTORY

RREVISIONEVISION N NUMBERUMBER DDATEATE CCOMMENTOMMENT

1.0 July 27th, 2007 DoIT Project Management Office Revision

2.0

2.1

2.2

REVISION: 1.0 DOIT-PMO-TEM-020 III OF VI


PREPARING THE PROJECT MANAGEMENT PLANPREPARING THE PROJECT MANAGEMENT PLAN

The workbook for preparation of the Project Management Plan is built around helping the project manager and the project team to use the Project Management Plan in support of successful projects. Please refer to it while developing this PMP for your project.

ABOUT THIS DOCUMENTABOUT THIS DOCUMENT

Project Oversight Process Memorandum – DoIT, July 2007Project Oversight Process Memorandum – DoIT, July 2007

“Project management plan” is a formal document approved by the executive sponsor and the Department and developed in the plan phase used to manage project execution, control, and project close.

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.

A project plan includes at least other plans for issue escalation, change control, communications, deliverable review and acceptance, staff acquisition, and risk management.

“Project manager” means a qualified person from the lead agency responsible for all aspects of the project over the entire project management lifecycle (initiate, plan, execute, control, close). The project manager must be familiar with project scope and objectives, as well as effectively coordinate the activities of the team. In addition, the project manager is responsible for developing the project plan and project schedule with the project team to ensure timely completion of the project. The project manager interfaces with all areas affected by the project including end users, distributors, and vendors. The project manager ensures adherence to the best practices and standards of the Department.

Project product” means the final project deliverables as defined in the project plan meeting all agreed and approved acceptance criteria.

“Product development life cycle” is a series of sequential, non-overlapping phases comprised of iterative disciplines such as requirements, analysis and design, implementation, test and deployment implemented to build a product or develop a service.

REVISION: 1.0 DOIT-PMO-TEM-020 IV OF VI


1.0 PROJECT OVERVIEW1.0 PROJECT OVERVIEW The Project Overview sets the stage for the details of the project and begins the “story” of the project and plan.

1.11.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECTEXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT

The Department of Health (DOH) Public Health Division (PHD) is initiating this project to upgrade the existing Billing and Electronic Health Record (BEHR) system. The BEHR system is the electronic medical record for all clinical services provided in public health offices. BEHR allows PHD to submit claims for services provided electronically and track compensation received for services performed, supporting revenue recovery.

The upgrade will allow PHD to comply with the United States Department of Health and Human Services (HHS) mandate that all entities covered the Health Insurance Portability and Accountability Act (HIPAA) implement the International Statistical Classifications of Diseases and Related Health Problems code set 10 (ICD-10) for medical coding by October 1, 2014. In addition, the upgrade will enable PHD to implement Stage 2 of Meaningful Use, part of the American Recovery and Reinvestment Act (ARRA), and apply for incentive payments offered by the federal government for adoption of electronic medical records.

The BEHR system was initially implemented in 2007 with all DOH public health offices using BEHR since early 2008. The system was first upgraded in 2010/2011 to meet Stage 1 Meaningful Use requirements. This will be the second major upgrade since the initial implementation.

1.2 FUNDING AND SOURCES1.2 FUNDING AND SOURCES

SOURCESOURCE AMOUNTAMOUNT ASSOCIATED ASSOCIATED RESTRICTIONSRESTRICTIONS

APPROVERSAPPROVERS

General Appropriations Act of 2010, Laws 2010, Chapter 6, Section 4, Department of Health General Fund Appropriation.

$250,000 NONE JANE PEACOCK

1.3 CONSTRAINTS1.3 CONSTRAINTSConstraints are factors that restrict the project by scope, resource, or schedule.

PAGE | 1


NNUMBERUMBER DDESCRIPTIONESCRIPTION

1 FY14 funds must be expended by June 30, 2011 and project must be completed in FY14.

2 Upgrade will go live simultaneously for all end users. Training must be completed shortly before the go live date. (within 2 weeks of go live)

3 Federal deadline for implementing ICD-10 is October 1, 2014. Upgrade must be completed before this date.

1.4 DEPENDENCIES1.4 DEPENDENCIESTypes 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

NUMBENUMBERR

DESCRIPTIONDESCRIPTION TYPE M,D,ETYPE M,D,E

1 EHR upgrade must be completed before ICD-10 Conversion can begin.

M,E

1.5 1.5 ASSUMPTIONSASSUMPTIONSAssumptions are planning factors that, for planning purposes, will be considered true, real, or certain.


1 Resources from PHD will be available for the duration of the project.

1.6 INITIAL PROJECT RISKS IDENTIFIED1.6 INITIAL PROJECT RISKS IDENTIFIEDIn this section identify and describe how each risk will be managed. Include the steps that will be taken to maximize activity that will result in minimizing probability and impact of each risk.

Stakeholder EngagementProbability LLOWOW

Impact HHIGHIGH

PAGE | 2


Description - Project will be at risk if all stakeholders are not engaged at the beginning of the project.

Mitigation Strategy: Emphasize communication to all stakeholders to be sure they understand the benefits of a successful project.Contingency Plan: This risk will be addressed during the planning phase so that necessary communication takes place throughout the project.

Lack of Implementation Resources

Description - Project will be at risk if the implementation vendor resources are not available.

Probability LLOWOW

Impact HHIGHIGH

Mitigation Strategy: In the beginning of the project, work with vendor and agree upon a schedule.Contingency Plan: Review the schedule monthly with the vendor to address any scheduling issues.

Lack of Funding

Description - Project will be at risk if the state withdraws the funding for cost containment purposes.

Probability LLOWOW

Impact HHIGHIGH

Mitigation Strategy: Show how services will become more cost effective and the ability to generate revenue recovery if this project is completed.Contingency Plan: The contingency plan will be developed during the planning phase as part of the project management plan.

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL 2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURESTRUCTURE

The Project Organization describes the roles and responsibilities of the project team. It also identifies the other organizational groups that are part of the project and graphically depicts the hierarchical configuration of those groups. It exists to clarify interaction with the project team.

2.1 STAKEHOLDERS2.1 STAKEHOLDERSList all of the major stakeholders in this project, and state why they have a stake. . Stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results.

NAMENAME SSTAKETAKE ININ P PROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE

Jane Peacock, MS Executive Sponsor Public Health Division (PHD)

Director

PAGE | 3


NAMENAME SSTAKETAKE ININ P PROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE

Maggi Gallaher, MD, MPH

Business Owner PHD Medical Director

PHD Staff Users of the system PHD

Citizens of New Mexico

Receive services in Public Health Offices

2.2 PROJECT GOVERNANCE STRUCTURE2.2 PROJECT GOVERNANCE STRUCTURE2.2.1 D2.2.1 DESCRIBEESCRIBE THETHE ORGANIZATIONALORGANIZATIONAL STRUCTURESTRUCTURE – O – ORGRG C CHARTHART

PAGE | 4


2.2.2 D2.2.2 DESCRIBEESCRIBE THETHE ROLEROLE ANDAND MEMBERSMEMBERS OFOF THETHE PROJECTPROJECT STEERINGSTEERING COMMITTEECOMMITTEE

NNAMEAME GGROUPROUP RROLEOLE RRESPONSIBILITYESPONSIBILITY

Jane Peacock, MS NMDOH

Executive Project Sponsor

Steering Committee

Member

Participate in planning sessions ; Ensure project staff availability, funding, and

contract management Review and accept the initial risk assessment,

management plan, project plan, and budget Provide management review and accept

changes to project plan, contract or deliverables

Attend executive requirements reviews and resolve requirements problems

Empower the Project Director and the Project Manager

Communicate with the Department of Health Champion the project Contribute to lessons learned

Maggi Gallaher, MD, MPH NMDOH

Project Director

Steering Committee

Member

Facilitate Steering Committee Meetings Participate in planning sessions Ensure project staff availability, funding, and

contract management Review and accept the initial risk assessment,

management plan, project plan, and budget Appoint Committee and Team members Provide management review and accept

changes to project plan, contracts or deliverables

Ensure user and sponsor acceptance Attend executive requirements reviews and

resolve requirements problems Adjudicate any appeals relative to Steering

Committee decisions Cast the deciding vote where a consensus

cannot be reached by the Steering Committee Empower the Project Manager Communicate with the Executive Sponsor and

NMDOH Champion the project Contribute to lessons learned

Terry Reusser NMDOH Agency CIO

Steering

Provide Information Technology guidance Attend and participate in meetings Review and accept deliverables

PAGE | 5


Committee Member

Review presented documentation Balance larger picture versus details of project Review project funding and expenditures Champion the project

Michael Snouffer NMDOH

Project Manager

Advisory Steering

Committee Member

Develop initial management plan and project plan

Provide leadership for a coordinated project effort

Document project assumptions, constraints, and critical success factors

Conduct initial risk assessment Facilitate project meetings Assign tasks Manage schedule, budget and scope Develop detailed plans with project team for

risk, change, quality Ensure project consensus Manage expectations Report on project status Maintain issues log Maintain action items log Promote and practice change management Close-out action items Value teamwork, cooperation, and planning Champion the project Facilitate lessons learned process

Remaining members of the Steering committee members are yet to be determined. Membership will reflect the organizations that will use and be affected by the BEHR system upgrade.The Steering Committee is chartered to provide governance over the direction and support of the project and is chaired by the Project Director. The Steering Committee member responsibilities include:

Attend and participate in meetings Review and accept deliverables Review presented documentation Balance larger picture versus detail of project Review project funding and expenditures Champion the project Contribute to lessons learned

2.2.3 O2.2.3 ORGANIZATIONALRGANIZATIONAL B BOUNDARIESOUNDARIES, , INTERFACESINTERFACES ANDAND RESPONSIBILITIESRESPONSIBILITIES

Use this section to describe any special considerations regarding contact between the project team, the project manager, and individuals from various organizations involved in the project: Boundary, interface and responsibilities at the interface.

PAGE | 6


The BEHR Upgrade Project will work closely with the Department of Information Technology (DoIT) for contracting and amendment review and approval, project status reporting and technical oversight.

2.3 EXECUTIVE REPORTING2.3 EXECUTIVE REPORTINGThe Project Manager will communicate on a regular basis regarding all aspects of the BEHR Upgrade Project. To facilitate effective communication and provide accurate updates on progress, the Project Manager shall report on the Project in the following manner:

Project Meetings: Project meetings will be held bi-weekly to discuss the current activities, the schedule of future activities, prioritized risks and the status of project issues. Special focus will be given to those activities and action items that were planned, but not accomplished. If necessary meetings will held more frequently. The BEHR Upgrade Project Manager will facilitate these meetings. Steering Committee meetings will be held monthly to update the membership on status, schedule, and budget, and to receive direction on project issues or decisions.

Status Reporting: The BEHR Upgrade Project Manager will meet with the Executive Sponsor and Project Director on a bi-weekly basis or provide a written status report, to discuss the current activities, the schedule of future activities, prioritized risks and the status of project issues. Special focus will be given to those activities and action items that were planned, but not accomplished.

Monthly Progress Reporting to DoIT: The BEHR Upgrade Project Manager will submit monthly reports using the DoIT template.

Other Communications: The BEHR Upgrade Project Manager will use email, telephone calls, conference calls, and additional meetings and presentations to communicate with the vendor, project team, and other stakeholders as needed.

3.0 SCOPE3.0 SCOPE

3.1 PROJECT OBJECTIVES3.1 PROJECT OBJECTIVES3.1.1 B3.1.1 BUSINESSUSINESS O OBJECTIVESBJECTIVES


Bus. Objective 1 Upgrade BEHR to meet federal required ICD-10 code sets for HIPAA covered entities.

Bus. Objective 2 Upgrade BEHR to be ready to meet Meaningful Use Stage 2 reporting requirements.

Bus. Objective 3 Increase revenue recovery with the use of more specific ICD-10 billing codes.

Bus. Objective 4 Train all staff on the use of both the new version of BEHR and ICD-10 coding.

PAGE | 7


3.1.2 T3.1.2 TECHNICALECHNICAL O OBJECTIVESBJECTIVES


Tech. Objective 1 Complete Requirements and Configuration documentation.

Tech. Objective 2 Implement upgraded PM and EHR application in test environment.

Tech. Objective 3 Develop test plan and scripts. Execute test scripts in test environment. Track and fix defects.

Tech. Objective 4 Upgrade BEHR PM and EHR application in production.

Tech. Objective 5 Improve integration and data exchange between the medical record (EHR) and the patient demographics (PM).

3.2 PROJECT EXCLUSIONS3.2 PROJECT EXCLUSIONSImplementation of the actual stage one and stage two Meaningful Use Modules will be excluded from the BEHR Upgrade Project because of cost constraints. The upgrade will be Meaningful Use ready.

3.3 CRITICAL SUCCESS FACTORS3.3 CRITICAL SUCCESS FACTORSIdentify the critical success factors for achieving success in this project. Metric are key to understanding the ability of the project to meet the end goals of the Executive Sponsor and the Business Owner, as well as the ability of the project team to stay within schedule and budget. See also section 6.7 Quality Objectives and Controls.

NUMBERNUMBER DESCRIPTIONDESCRIPTION

QUALITY METRICS 1 Data is converted properly from existing BEHR system.

QUALITY METRICS 2 Billing and immunization interfaces are working properly and electronic claim submission is not interrupted.

QUALITY METRICS 3 Implementation vendor and end user testing are successful by developing a test plan and test scripts.

QUALITY METRICS 4 Independent verification and validation review will be conducted on all project deliverables.

PAGE | 8


4.0 PROJECT DELIVERABLES AND METHODOLOGY4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE4.1 PROJECT MANAGEMENT LIFE CYCLE

Phase Summary of Phase Key Deliverables

Initiation This phase defines overall parameters of the project and established the appropriate project management and quality environment required to complete the project.

Project Charter, Initial Risk Assessment, High level schedule, Procurement Strategy, Approval for next phase.

Planning This phase defines the exact parameters of the project and ensures all the pre-requisites for execution and control are in place.

Project Management Plan, Team members identified, Final scope statement, High level WBS, Resources identified, High level Schedule, Budget and Communication Plans, Roles and Responsibilities, Status reports, Approval for next phase.

Implementation The phase configures and deploys the system.

Configuration Documentation, Testing Documentation, Training Documentation, Updated Project Schedule, Updated Budget, Risk Management Log, Issue Log, Status Report, Acceptance.

Closeout The phase accesses the project and derives any lessons learned and best practices.

Post Implementation Review and Report, Administrative Close-Out.

4.1.1 P4.1.1 PROJECTROJECT M MANAGEMENTANAGEMENT D DELIVERABLESELIVERABLES

Project Deliverables are work products or artifacts that are driven by the project management methodology requirements and standard project management practices regardless of the product requirements of the project.

4.1.1.1 Project CharterDescription - The initial project deliverable plan will contain the Project Charter. This deliverable

Deliverable Acceptance Criteria – Sign-off by Project Sponsor or Project DirectorStandards for Content and Format – Use of DoIT Project Charter template

PAGE | 9


may be revised during planning phase.

Quality Review –Peer review for grammar and spellingKey project team members review for consensus

4.1.1.2 Project Management PlanDescription - The Project Management Plan will be the guide used throughout the Project. This plan will contain the following plans: Scope Management, Schedule Management, Budget, Risk Management, Communications, Change Management, Lessons Learned and Roles/Responsibilities of team members. This plan is an evolving document as new information will be added and existing information will be revised during initiation and planning phase.

Deliverable Acceptance Criteria –

Sign-off by Project Sponsor or Project Director

Standards for Content and Format –

Use of DoIT Project Management Plan template

Quality Review – Peer review for grammar and spellingKey project team members review for consensusFinal review by Steering Committee, Project Director and Sponsor

4.1.2 D4.1.2 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

Complete the following table to identify the deliverables this project is to produce, and to name the person or persons who have authority to approve each deliverable.

DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))

DDATEATE AAPPROVEDPPROVED

PRJ-DEL-001 Project Charter Jane Peacock, MS


PRJ-DEL-002 Project Management Plan (PMP) Jane Peacock, MS


4.1.3 D4.1.3 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDUREDescribe the process that this project will use for the formal acceptance of all deliverables.

The Project Director and the project Sponsor will review and accept the project documents.

4.2 PRODUCT LIFE CYCLE4.2 PRODUCT LIFE CYCLE

PAGE | 10


“During the project management lifecycle, agencies shall select and implement a phase product development lifecycle methodology approved by the Department.” PROJECT OVERSIGHT PROCESS Memorandum

Phase Summary of Phase Key Deliverables

Planning Project scope of work and deliverables identified.

Project timeline finalized.

Vendor and IV&V contracts finalized.

Implementation Vendor Contract

IV&V Vendor Contract

Project Implementation Plan

Configuration and Implementation

Standup and configure new Test, Training and Production Environments for upgrades

New environments deployed and configured

Test plans completed

System Testing and Validation Upgrades tested and issues resolved and retested.

Current production data in upgraded system.

System functionality validated.

Training Training on system – both technical and process.

Training Documentation and tools. Users trained on upgraded system.

Deployment Deployment of system to all trained users.

Deployment strategy.

Shift to transition to production.

Production Completed System Deployment and move to close-out Project.

Updated User documentation

Updated Application Support Plan

Updated Disaster Recovery Plan

4.2.1 T4.2.1 TECHNICALECHNICAL S STRATEGYTRATEGY

Discuss the key technical strategies for achieving success in this project. Certify system performance after test upgrade and migration to new version

Upgrade to production environment, configuration, testing and signoff

4.2.2 P4.2.2 PRODUCTRODUCT ANDAND P PRODUCTRODUCT D DEVELOPMENTEVELOPMENT D DELIVERABLESELIVERABLES

Product Deliverables are work products or artifacts that are driven by the product management methodology requirements and standard project management practices regardless of the product requirements of the project.

PAGE | 11


(Note - deliverable numbering begins at C, 3 because these deliverables will be amended to an existing contract.)

C. Deliverable Number 3 Develop Implementation Plan for PM Upgrade

Deliverable Name Due Date Compensation

Develop Implementation Plan for PM Upgrade to PM v10.5 10/18/14

$1,000.00

(Excludes New Mexico Gross Receipts Tax)

Task Item Sub Tasks Description

Develop project plan and schedule for PM upgrade.

The Contractor, with Procuring Agency’s participation, will develop a detailed project implementation plan outlining tasks to be completed, deliverables to be produced and responsibilities of the parties relative to these tasks and deliverables utilizing the Contractor’s implementation methodology as appropriate and agreed upon by the Procuring Agency. The Plan and supporting documentation will be created and maintained using Microsoft Office and Microsoft Project. The tasks and deliverables will relate to the project to implement the upgrade of Practice Management (PM) to all PHD offices and central offices. The Plan will include the setup of hosting environment, installation of software, super user training, design, build, test, and configuration of software, update of business processes, system and software training, implementation support, end-user training, transition to operations and production support processes. Plan will also include all documentation, tasks, and responsibilities required for a successful implementation of the software modules in a hosted environment for the complete rollout to the other regional and central offices, and for production. The Plan will include the design, configuration, build, and testing (configuration, system, integration, end-user) of the BEHR System.

Agency Acceptance

The Procuring Agency project manager will review, approve and accept the project implementation plan and notify the Contractor in writing of the acceptance of the plan.

D. Deliverable Number 4 Build Production, Test and Training Environments for PM Upgrade

PAGE | 12



Build Production, Test and Training Environments for PM

Upgrade11/1/14

$2,000.00



Build Production, Test and Training Environments for PM upgrade.

The Contractor will prepare hosting environments for the Allscripts PM v 10.5 in Production, Test and Training. The test and production hosting environments shall meet or exceed the minimum standards for hardware, networking, and connectivity for the Allscripts Software modules and any future Software releases or modules. The test environment will be able to incorporate all of the production data for testing purposes. A separate mirrored training environment will be developed with the option of containing no protected patient information. See Deliverable 14 for details regarding the eradication of protected patient information. The Contractor will set-up multiple database servers, including clustering for the production environment, web servers, print servers and imaging servers. This deliverable does not replace deliverable 1 as amended. All of the requirements in deliverable 1 must continue to met or exceeded as part of the set-up of these environments.

Agency Acceptance

Contractor will participate in weekly meetings with the agency project team and provide written weekly status reports. Contractor will provide weekly reports documenting material decisions made and will provide such reports to Procuring Agency project manager for acceptance and approval. The system setup will be reviewed and accepted by the Procuring Agency project team.

E. Deliverable Number 5 Configure Production, Test and Training Environments for PM Upgrade


Configure Production, Test and Training Environments for PM

Upgrade11/8/14

$2,000.00


PAGE | 13



Configure Production, Test and Training Environments for PM upgrade.

The specifications for this deliverable are as follows: The Contractor will prepare Allscripts PM v10.5 for production.

Contractor will perform the following activities: Configuration and set up of v10.5 security, interfaces, and

reporting that are new to this version. Implement DOH specific configurations made to 10.0.5 in the

10.5 environments. Convert the v10.0.5 production data to the Testing environment. Provide a statistical analysis of the data converted proving that the

data was correctly converted PM v10.5. Provide expertise to the agency project team in developing test

plans for verifying the configurations of the new version.

Agency Acceptance

Contractor will participate in weekly meetings with the agency project team. The system configuration will be reviewed and accepted by the Procuring Agency project team.

F. Deliverable Number 6 System Testing and Validation for PM


System Testing and Validation for PM Upgrade 11/22/14

$2,500.00



Validate environments and system testing for PM upgrade.

The Contractor and DOH will coordinate the testing of the Allscripts PM 10.5 for production functionality and appropriate set up. This includes: Testing of v10.5 security, functionality and features that that are new to the version. It includes the “smoke testing”, and production testing of all of the new and existing features including interfaces and interface functionality with the end result being the acceptance testing. DOH will approve prior to the progression to production.

PAGE | 14


Resolve identified issues

Troubleshoot and resolve issues identified during testing. Contractor will also assist DOH staff in resolving any communication or data access issues.

Agency Acceptance

Contractor will participate in weekly meetings with the agency project team. Contractor will manage reports documenting material testing outcomes and will provide such reports to Procuring Agency project manager for acceptance and approval.

G. Deliverable Number 7 User Training for PM


User Training for PM Upgrade 12/13/13$4,000.00



User Training for PM upgrade.

The contractor and DOH staff will train the on Allscripts PM v10.5

The contractor will provide the training listed below: Identify, assist in the development of and provide training tools

(printed material, recorded webcasts, etc.) that could be used to familiarize end users and super users to the application prior to training.

Train agency identified super users. Each super user will receive 1 day of classroom training.

Provide one 4-hour training for Regional Support Users via the web. Super users trained previously will provide on-site support for this training.

Provide three 4-hour trainings for all agency identified end users via the web. Each user will receive 4 hours of training via the web. All users will be trained within 2 weeks of the go-live date. Super users and Regional Support users will provide on-site support for these trainings.

Agency Acceptance

Contractor will participate in weekly meetings with the agency project team. Contractor will assist with developing training materials and will provide such materials to Procuring Agency project manager for acceptance and approval.

PAGE | 15


H. Deliverable Number 8 Production Go Live for PM


Production Go Live for PM Upgrade 12/16/13

$2,500.00



Production Go Live for PM upgrade.

The specifications for this deliverable are as follows: The Contractor will test the Allscripts v10.5 for production functionality and appropriate set up. The Contractor will perform the required series of steps to bring the new functionality to the live production environment during an agency approved time outside of normal business hours. Contractor will bring all of the PM version 10.5servers live (available to end users) as well as shutting down the version previous production environment. Contractor will perform an additional series of testing steps to ensure the environment is production ready with the live data from the previous v10.5 environment.

Agency Acceptance

Contractor will participate in weekly meetings with the agency project team. Contractor will provide reports documenting material Go Live issues and will provide such reports to Procuring Agency project manager for acceptance and approval.

I. Deliverable Number 9 Implementation Plan for EHR upgrade


Develop Implementation Plan for EHR upgrade 12/1/13

$6,654.00



PAGE | 16


Develop Implementation Plan for EHR upgrade

The Contractor, with Procuring Agency’s participation, will develop a detailed project implementation plan outlining tasks to be completed, deliverables to be produced and responsibilities of the parties relative to these tasks and deliverables utilizing the Contractor’s implementation methodology as appropriate and agreed upon by the Procuring Agency. The Plan and supporting documentation will be created and maintained using Microsoft Office and Microsoft Project. The tasks and deliverables will relate to the project to implement the upgrade of Electronic Health Records (EHR) to all PHD offices and central offices. The Plan will include the setup of hosting environment, installation of software, super user training, design, build, test, and configuration of software, update of business processes, system and software training, implementation support, end-user training, transition to operations and production support processes. Plan will also include all documentation, tasks, and responsibilities required for a successful implementation of the software modules in a hosted environment for the completed rollout to the other regional and central offices, and for production. The Plan will include the design, configuration, build, and testing (configuration, system, integration, end-user) of the BEHR System.

Agency Acceptance

The Procuring Agency project manager will review, approve and accept the project implementation plan and notify the Contractor in writing of the acceptance of the plan.

J. Deliverable Number 10 Build Allscripts V 11.4.1 Environments


Build Allscripts V 11.4.1 Production, Test and Training

Environments

1/17/14 $56,556.00



PAGE | 17


Build Production, Test and Training Environments

The Contractor will prepare hosting environments for the Allscripts EMR 11.4.1 in Production, Test and Training and Allscripts Stimulus Set in Production and Test. The test and production hosting environments shall meet or exceed the minimum standards for hardware, networking, and connectivity for the Allscripts Software modules and any future Software releases or modules. The test environment will be able to incorporate all of the production data for testing purposes. A separate mirrored training environment will be developed with the option containing no protected patient information. See Deliverable 14 for details regarding the eradication of protected patient information. The Contractor will set-up multiple database servers, including clustering for the production environment, web servers, print servers and imaging servers. This deliverable does not replace deliverable 1 as amended. All of the requirements in deliverable 1 must continue to met or exceeded as part of the set-up of these environments.

Agency Acceptance

Contractor will participate in weekly meetings with the agency project team. Contractor will manage the documentation material of decisions made and will provide such reports to Procuring Agency project manager for acceptance and approval.

K. Deliverable Number 11 Configure Allscripts V 11.4.1 Environments


Allscripts Configuration for Production, Testing and Training Environments

4/4/14$64,873.00



PAGE | 18


Configure Production, Test and Training Environments

The specifications for this deliverable are as follows: The Contractor will prepare Allscripts v11.4.1 for production.

Contractor will perform the following activities: Configuration and set up of V11 security, interfaces, and reporting

that are new to this version. Implement DOH specific configurations made to v11.1.7 in the

V11.4.1 environments. Convert the v11.1.7 production data to the Testing environment. Provide a statistical analysis of the data converted proving that the

data was correctly converted to V11.4.1. Provide expertise to the agency project team in developing test

plans for verifying the configurations of the new version.

Agency Acceptance

Contractor will participate in weekly meetings with the agency project team. The system configuration will be reviewed and accepted by the Procuring Agency project team.

L. Deliverable Number 12 System Testing and Validation for EHR


System Testing and Validation for EHR 5/2/14

$14,971.00



Validate Production, Test and Training Environments and system Testing

The Contractor and DOH will coordinate the testing of the Allscripts v11.4.1 for production functionality and appropriate set up. This includes: Testing of V11 security, functionality and features that that are new to the version. It includes the “smoke testing”, and production testing of all of the new and existing features including interfaces and interface functionality with the end result being the acceptance testing. DOH will approve prior to progression to production.

Resolve identified issues

Troubleshoot and resolve issues identified during testing. Contractor will also assist DOH staff in resolving any communication or data access issues.

PAGE | 19


Agency Acceptance

Contractor will participate in weekly meetings with the agency project team. Contractor will manage documenting material decisions made and will provide such reports to Procuring Agency project manager for acceptance and approval. The system testing and validation will be reviewed and accepted by the Procuring Agency project team.

M. Deliverable Number 13 User Training for EHR


User Training for EHR 5/23/14$17,971.00



User Training for EHR

The Contractor will assist DOH staff in the training for Allscripts V11.4.1.

The Contractor will assist with the training listed below: Identify, assist in the development of and provide training tools

(printed material, recorded webcasts, etc.) that could be used to familiarize end users and super users to the application prior to training.

Train agency-identified super users. Each super user will receive two days of classroom training.

Provide two 1-day trainings for Regional Support Users via the web. Super users trained previously will provide on-site support for this training.

Provide five 1-day trainings for all agency identified end users via the web. Each user will receive 1 days of training via the web. All users will be trained within 2 weeks of the go-live date. Super users and Regional Support users will provide on-site support for these trainings.

Contractor’s travel costs must be pre-approved by the Procuring Agency and will be reimbursed based on actual costs. Travel contingency funds are included in this Deliverable. Procuring Agency will be responsible for the Procuring Agency’s attendees travel arrangements and costs.

PAGE | 20


Agency Acceptance

Contractor will participate in weekly meetings with the agency project team. Contractor will assist with developing training materials and will provide such materials to Procuring Agency project manager for acceptance and approval.

N. Deliverable Number 14 Production Go Live for EHR


Production Go Live for EHR 6/2/14$6,654.00



Production Go Live for EHR

The specifications for this deliverable are as follows: The Contractor will test the Allscripts V11.4.1 for production

functionality and appropriate set up. The Contractor will perform the required series of steps to bring

the new functionality to the live production environment during an agency approved time outside of normal business hours.

Contractor will bring all of the version 11.4.1 servers live (available to end users) as well as shutting down the version previous production environment.

Contractor will perform an additional series of testing steps to ensure the environment is production ready with the live data from the previous V11.4.1 environment.

Agency Acceptance

Contractor will participate in weekly meetings with the agency project team. Contractor will manage reports documenting Go Live issues and will provide such reports to Procuring Agency project manager for acceptance and approval.

O. Deliverable Number 15 ICD-10 Conversion Services


ICD-10 Conversion Support 11/1/14 $22,500.00

PAGE | 21




ICD-10 Conversion Support

The specifications for this deliverable are as follows: The Contractor will offer assistance to the DOH team with

planning the ICD-10 conversion project. The Contractor will assist in training DOH staff on ICD-10

impacts and changes to workflow. The Contractor will assist the DOH team with testing the ICD-10

conversion process.

Agency Acceptance

Contractor will participate in weekly meetings with the agency project team. Contractor will document specific contributions to the effort and will provide such reports to Procuring Agency project manager for acceptance and approval.

P. Deliverable Number 16 Eradicating Patient Information from PM and EHR Training Environments


Removing PHI from PM and EHR Training Environments 5/1/14

$7,000



PAGE | 22


Eradicating PHI from PM and EHR Training Environments

The specifications for this deliverable are as follows: The Contractor will provide the ability to eradicate PHI from the

single environment designated for Training The Contractor will provide the ability to overwrite the PHI of the

existing patient population (including name, ssn, phone, address, mrn) and replacing any information that could be used to identify a patient in violation of HIPAA.

The Contractor will, once the modified patients have been validated, take an image of the Training database that can be applied to refresh the data for future training needs.

Agency Acceptance

The di-identified patient data in the Training environment will be reviewed and accepted by the Procuring Agency project team.

4.2.2.x All deliverables listed aboveAll deliverables listed in implementation vendor scope of work

Deliverable Acceptance Criteria – Sign-off by Project TeamStandards for Content and Format – MS Word, Excel, Visio, and Adobe PDFQuality Review – Reviewed by project team members, director, and sponsor for completeness

4.2.3 D4.2.3 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

Complete the following table to identify the deliverables this project is to produce, and to name the person or persons who have authority to approve each deliverable.

DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))

DDATEATE AAPPROVEDPPROVED

3 - 16 Listed above Project Director

4.2.4 D4.2.4 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

Describe the process that this project will use for the formal acceptance of all deliverables. As part of the Deliverable Acceptance Procedure, the Project Team will review each of the deliverables. During the Project Team review period, any issues identified will be documented in the issue log and resolved if possible prior to the next step. After a deliverable is reviewed, a recommendation from the Project Team for acceptance will be sent to the Project Director for final sign-off.

PAGE | 23


5.0 PROJECT WORK5.0 PROJECT WORK

5.1 WORK BREAKDOWN STRUCTURE (WBS)5.1 WORK BREAKDOWN STRUCTURE (WBS)A WBS is a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Describe the work activities that comprise the work breakdown structure (WBS) or the work packages within the WBS. Identify the WBS element or other work package identifier and provide a general description of the tasks or activities, the definition or objectives, and the milestones and deliverables of each work package.

Use the chart below for highest level presentation, and provide a more detailed WBS as an attachment to this project plan.

Identifier Work Package Description Definition/Objective Milestone/Deliverable

1.0 Initiation Phase This phase defines overall parameters of the project and established the appropriate project management and quality environment required to complete the project

Project Charter, Initial Risk Assessment, High-level schedule, Approval for next phase.

2.0 Planning Phase This phase identifies the implementation approach, procurement method and establishes all necessary documentation.

Contract Amendment Negotiated and Executed, IV&V Contract Executed, Finalize PMP, Commit Resources. Approval for next phase.

3.0 Implementation Phase This phase deploys the upgraded system to a prepared set of users and positions on-going support and maintenance.

Confirm Schedule, Configuration, Testing, Training, and Deployment.

4.0 Closeout Phase This phase closes out the project and completes the Transition to Production.

Closeout report, Transition to Production document, Lessons Learned

5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE5.2 SCHEDULE ALLOCATION -PROJECT TIMELINEThe project timeline is a high-level view of project activities with a focus on project milestones. The project timeline does not replace the need for a detailed project schedule and it is to highlight key events such as deliverable due dates and when go/no-go decisions are made.

The table below should provide a high level view of the project time line, or a summary-level Gantt chart can be used to meet the timeline requirement.

Please provide a more detailed project schedule as an attachment to this plan

PAGE | 24


Identifier Task/Activity Name Resource Name

Milestone (Y/N)

Effort/ Duration

Start Finish Dependent Task

1.0 Initiation Phase Project Director Project Team Steering Committee

Y1 month 9/2013 10/2010 Confirm

Funding

2.0 Planning PhaseProject Director Project Team Steering Committee

Y1 month 9/2010 10/2010

Execute Vendor Contract Amendment

3.0 Implementation Phase Project Director

Project Team Steering Committee

Vendor Resources

Y

12 months

11/2013 11/2014Completion of Planning Phase

4.0 Closeout PhaseProject Director Project Team Steering Committee

Y1 month 11/2014 12/2014

Completion of Implementation Phase

5.3 PROJECT BUDGET5.3 PROJECT BUDGETCosts estimates are the costs applied to an activity in a project by assigning resources with associated rates or fees. Resources can include equipment, material, technology, processing cycles, or people. The total cost is critical and should be consistent with the proposal; include breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or deliverable).

Identifier Work Package or Budget Category Cost

1 IV&V – professional services $30,000

2 BEHR Practice Management and Electronic Health Record upgrade and ICD-10 implementation – professional services

$220,000

5.4 PROJECT TEAM5.4 PROJECT TEAM

PAGE | 25


5.4.1 P5.4.1 PROJECTROJECT T TEAMEAM O ORGANIZATIONALRGANIZATIONAL S STRUCTURETRUCTURE

Insert a graphical Organization Chart here. The Organizational Structure (OS) is a hierarchical configuration defining levels of program management and may identify all project personnel. The OS should be simple and straightforward. Include role names and people’s names. Consider identifying the core project team by shading their respective boxes on the chart. On complex projects, consider using a second OS to identify core project team. The OS can also be used for management reporting.

5.4.2 P5.4.2 PROJECTROJECT T TEAMEAM R ROLESOLES ANDAND R RESPONSIBILITIESESPONSIBILITIES

List the team members, their role, responsibility and functional manager. Make sure to include a comprehensive listing including those from the organization managing the project, business members involved to ensure business objectives are met and the vendor members that may have a specific role.

RROLEOLE RRESPONSIBILITYESPONSIBILITY NNAMEAME FFUNCTIONALUNCTIONAL AAREAREA

Project Director To ensure business requirements are met and to provide project leadership


NMDOH PHD

Project Manager To provide project management

Michael Snouffer NMDOH ITSD

PAGE | 26


RROLEOLE RRESPONSIBILITYESPONSIBILITY NNAMEAME FFUNCTIONALUNCTIONAL AAREAREA

DOH Technical resources

To provide technical leadership and provide project technical resources

TBD NMDOH

Business Process Team

To provide business process and program area leadership, and to provide project business process resources

TBD NMDOH PHD

Implementation Will perform the upgrades Mednetworx Implementation Vendor

5.5 STAFF PLANNING AND RESOURCE ACQUISITION5.5 STAFF PLANNING AND RESOURCE ACQUISITIONComplete the chart below identifying the project team members and details concerning their project commitment. Project staff should include State, Contract, Customer (Business Owner), or Vendor team members

5.5.1 P5.5.1 PROJECTROJECT S STAFFTAFF

Resource Cost Estimate

Estimated Hours Availability Skill Set Work Product/Deliverable

Maggi Gallaher, MD, MPH Management Project oversight and direction

Michael Snouffer Project Management

Project management deliverables

PHD Staff Business process, project tasks, training

Implementation Vendor $220,000 Yes Practice Management and Electronic Health Record upgrade

IV&V Vendor $30,000 IV&V deliverables

5.5.2 N5.5.2 NONON-P-PERSONNELERSONNEL RESOURCESRESOURCES

Use this section to list services or product (HW/SW and such) needed for project

Resource Cost Estimate

Estimated units/hours Availability Source Work Product/Deliverable

Hardware $0

Software $0

5.6 PROJECT LOGISTICS5.6 PROJECT LOGISTICS

PAGE | 27


Logistics describes how the project manager, project team, the business owner/customer and any vendor resources will physically work together. Include anything to do with moving or starting resources. Training specifically related to project team members should be included here.

5.6.1 P5.6.1 PROJECTROJECT T TEAMEAM T TRAININGRAINING

Describe training if any needed by project team members. This is not to include training for end users, system administrators or business owners; those should be handled within a training document or part of the transition to operations planning.The BEHR Project Team will use tools available at NMDOH and the Implementation Vendor to work together. These tools include telephone calls, conference calls and web meetings. The Project Team will also use resident software packages such as MS Word, Excel, Visio, Project and Adobe PDF. Trainers, Regional Support Users and others will be identified and training provided for these resources.

6.0 PROJECT MANAGEMENT AND CONTROLS6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT6.1 RISK AND ISSUE MANAGEMENTPMBOK©:

Risk: “An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.”

Issue: “A point or matter in question or dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.”

Both Risks and Issues can significant impact a project’s success, and both should be handled in similar ways.

6.1.1 R6.1.1 RISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGY

Provide a detailed explanation on the strategy for how risks are identified, analyzed/ quantified, mitigated, reported, escalated and tracked. Include the use of tools such as project management software, forms, and templates. A separate risk management plan may also be developed if needed for the project and included as an Appendix to this document. If that is the case, a high level summary of this plan needs to be included here with the specific reference.Projects have many inherent risks associated with them. The technology itself, risks associated with introduction of new and/or innovative ideas, organizational change issues, internal project issues, external issues such as politics and the economy not to mention social concerns around the introduction of technology. The list of potential risks is almost limitless.

Risk management is the process of identifying potential project risk, assessing the probability and severity of risk events, and planning appropriate responses. Risk management is a priority task on any IT project and is managed just like cost, schedule, scope and quality.

The best way to deal with a large amount of data/information is to categorize it in such a way that you can begin to understand the relationships between the data and start to see structure.

PAGE | 28


1. Risk Identification – The process of identifying potential risks and documenting the specific characteristics of each.

2. Risk Analysis – The process of determining the impact and likelihood of the identified risks. This process may employ both qualitative and quantitative techniques as deemed necessary to objectively evaluate potential risks to the project.

3. Risk Mitigation – The process of mitigating the possibility of the risk and assigning responsible individuals to identified risks. All identified risks will have appropriate mitigation strategies/plans. For those risks that are highly probable and have significant impact to the project will develop contingency plans.

4. Risk Monitoring and Control – The process of tracking, evaluating and responding to ongoing developments relative to project plans, risk mitigation plans and specific contingency plans. Risk management is an integral component of integrated project control. This is an ongoing process for the duration of the project and will be part of every project status meeting.

6.1.2 P6.1.2 PROJECTROJECT R RISKISK I IDENTIFICATIONDENTIFICATION

This is the process of identifying potential risks and documenting the specific characteristics of each. The BEHR Upgrade Project Team will discuss the project risks on a periodic basis or as a specific risk occurs.

6.1.3 P6.1.3 PROJECTROJECT R RISKISK M MITIGATIONITIGATION A APPROACHPPROACH

The approach for the BEHR Upgrade Project will be the process of mitigating the possibility of the risk and assigning a responsible individual to monitor identified risks. All identified risks will have appropriate mitigation strategies/plans. For those risks that are highly probable and have significant impact to the project will develop contingency plans.

6.1.4 R6.1.4 RISKISK R REPORTINGEPORTING ANDAND E ESCALATIONSCALATION S STRATEGYTRATEGY

Once a risk is identified, the BEHR Upgrade Project Team will analyze the risk to determine the source, the probability it will happen and the impact to time, cost, quality and scope. An initial strategy may be laid out. Risks will be prioritized and assigned to a team member. The team member’s manager will be required to document the response to the potential risk and assumes responsibility for communicating and escalating to the appropriate parties.

6.1.5 P6.1.5 PROJECTROJECT R RISKISK T TRACKINGRACKING A APPROACHPPROACH

Potential risks will be tracked using a Risk Tracking Log.

6.1.6 ISSUE MANAGEMENT6.1.6 ISSUE MANAGEMENT

6.1.6.1 Internal Issue Escalation and Resolution ProcessThis internal process is provided for issues that involve project resources, processes, procedures, or methodology that should be resolved within the Division that is 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.

PAGE | 29


When an issue is identified, most likely by the project team, it will be added to the Issue Tracking Log. An issue can also be identified by anyone affiliated with the project; however the project team will be primarily responsible for tracking issues through to resolution. The project team will review the issues list on a periodic basis. Issues which could negatively impact the project or require senior level participation will be brought to executive sponsor’s and project manager’s attention for resolution.

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 that is responsible for managing the project without affecting the overall project schedule, cost, or quality.

The process for issue escalation and resolution for issues that cannot be addressed within NMDOH will be handled in the same manner as internal issues. If necessary, resources outside the agency maybe brought in to resolve the issue. If at any time it is apparent the issue needs escalation outside of NMDOH, the Project Sponsor will communicate with the resource and ask for assistance in resolving the issue.

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&VIndependent Verification and Validation (IV&V) means the process of evaluating a system to determine compliance with specified requirements and the process of determining whether the products of a given development phase fulfill the requirements established during the previous stage, both of which are performed by an organization independent of the development organization. Describe the process that will be employed to meet IV&V requirements.Independent Verification and Validation (IV&V) is a risk mitigation strategy designed to provide management with project oversight through an independent evaluation a project’s product and process quality. The project has adopted a low risk implementation strategy by upgrading an existing application with a well-established and tested version. The IV&V plan will be tailored to address the unique risks associated with the upgrade.

The IV&V plan will:

1. Evaluate and validate that products and deliverables of a given development phase fulfill the requirements and performance outcomes set forth in the scope and project plan.

2. Provide a “close-out” report to the Steering Committee at the end of project

Specific deliverables from the IV&V contract: IV&V Project Management Plan. Initial Review and Risk Assessment. Periodic Review Close-out Report

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

PAGE | 30


Most changes to scope are requests that add, change, or delete project objectives or deliverables. Changes in scope, if at all possible, will be avoided and any new objectives and/or deliverables deferred to a follow-on project. Any proposed changes in scope will be analyzed for impacts on the project including schedule, budget and quality. The findings will be presented to the Steering Committee for approval or rejection.

6.3.1 C6.3.1 CHANGEHANGE C CONTROLONTROL

6.3.1.1 Change Control ProcessChange Control establishes how change will be managed, including capturing, tracking, communicating, and resolving change. Due to much ambiguity regarding change, it is vital that we document and discuss the change process with the executive sponsor.

Project changes will follow a decision making process. These changes include modifications to scope, schedule, budget, and quality. Significant changes of these planning components will be reviewed and approved or disproved by the Steering Committee. If a modification or enhancement to the project has been identified, a change request form will be completed. The Steering Committee will review the request to determine impacts to scope, schedule, budget, quality and resources. The Steering Committee will recommend accepting the change, rejecting the change, or may request additional information. The request will be documented by the Project Manager and if the change is approved, appropriate changes will be made to the Project Management Plan and other project documentation.

6.3.1.2 Change Control Board (CCB)Insert a graphic or textual description identifying the Change Control Board (or function) for this project. The CCB may be an individual or group of individuals authorized to approve changes to the project plan.During the course of the BEHR Upgrade Project, the Steering Committee will fill the role of the Change Control Board. A production-based Change Control Board is already established for the existing BEHR system and will resume their duties upon the successful implementation of the upgraded BEHR system.

6.4 PROJECT BUDGET MANAGEMENT6.4 PROJECT BUDGET MANAGEMENTCosts estimates are the costs applied to an activity in a project by assigning resources with associated rates or fees. Resources can include equipment, material, technology, processing cycles, or people. The total cost is critical and should be consistent with the proposal; include breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or deliverable).

6.4.1 B6.4.1 BUDGETUDGET T TRACKINGRACKING

Costs estimates are the costs applied to an activity in a project by assigning resources with associated rates or fees. Resources may include equipment, material, technology, processing cycles, or people. The total cost is critical and should be consistent with the proposal and include breakouts per category as needed. The Project Manager will verify these cost estimates and proposed amounts with the actual billed amounts.

PAGE | 31


6.5 COMMUNICATION PLAN6.5 COMMUNICATION PLANCommunication planning involves determining the information and communication needs of the stakeholders, executive sponsors, project team and others as needed. The communication plan needs to address who needs what information, when they will need it, how it will be given to them, and by whom. The complexity of the project may require a separate communication plan; however a high level summary of that plan will need to be included here and a reference made to the appropriate Appendix.Communication will be effected through the distribution of Project Management deliverables as specified below. This PMP and any changes to it constitute one of the deliverables. Status Reports will be distributed as indicated below and for other communication needs, appropriate communication methods will be utilized.

Status, issues, and risks will also be discussed at regularly scheduled meetings preceded by the distribution of an agenda and followed by the distribution of meeting minutes or notes.

6.5.1 C6.5.1 COMMUNICATIONOMMUNICATION M MATRIXATRIX

Meetings Status Reports Other Communications

To Executive Sponsor Monthly Monthly As Needed

To Steering Committee Monthly Monthly As Needed

To Project Director Bi-Weekly Bi-Weekly As Needed

To Project Team Bi-Weekly Receive From Members

As Needed

To Stakeholders As Requested As Requested As Needed

6.5.2 S6.5.2 STATUSTATUS M MEETINGSEETINGS

Status Meetings with the core project team will be held on a weekly basis. This will include the project manager, project director and vendor project manager. Project Status will be the first agenda item. If needed, special meetings will be called to discuss and address issues.

6.5.3 P6.5.3 PROJECTROJECT S STATUSTATUS R REPORTSEPORTS

Project Status Reports will be distributed to the Project Sponsor and the Project Director and will be presented at each Steering Committee Meeting. As the project moves into implementation and the vendor is engaged, status reports will be required from the vendor as well as from BEHR Upgrade Project Resources. These status reports will be rolled up into the Steering Committee status report and reviewed at each meeting.

The monthly DoIT Status Report will be completed by the Project Manager and submitted per the DoIT process.

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)The Project Manager and Executive Sponsor define the project metrics that will be used to control the project. Each project will need to have an established metrics program. Metrics are

PAGE | 32


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. At a minimum metrics must be established for time (schedule), cost (budget) and quality.

6.6.1 B6.6.1 BASELINESASELINES

Project Area Category Measure

Schedule Milestone performance Milestone dates

Status reports, issue log, risk log, and other identified measures

Budget Financial performance Current and forecasted costs and maintaining budget

Quality Business Process Upgrade configuration and supporting business processes, data conversion, uninterrupted electronic claim submission

6.6.2 M6.6.2 METRICSETRICS L LIBRARYIBRARY

The reviewed metrics in various software programs will be versioned by date and saved to the Project Library.

6.7 QUALITY OBJECTIVES AND CONTROL6.7 QUALITY OBJECTIVES AND CONTROLQuality Management includes the processes required to ensure that the project will satisfy the needs for which it was undertaken. It includes all activities of the overall management function that determine the quality policy, objectives, quality assurance, quality control, and quality improvement, within the quality system. If a separate Quality Plan is used, include a high level summary in this document and refer to the appropriate appendix.

6.7.1 6.7.1 QUALITYQUALITY S STANDARDSTANDARDS

Describe the agency, industry or regulatory project performance standards that will be followed and assessed by the project. These quality standards will be used to assess whether the quality objectives were achieved.

Identify each of the project quality standards that are directly related to the project and not to the performance of the actual product and/or service. For each quality standard, identify the tracking tool or measure such as number of project reviews or Project Status.

PAGE | 33


No. Quality Standard Tracking Tool or Measure

1 Project management plan approved and followed• PMP signed off by

Steering Committee• Project status

reports

2 Certification to proceed to next phase by DoIT

• Approval from DoIT Project Certification Committee and release of funds

3 Project risks documented, mitigated and tracked • Risk Management Log

4 Project issues documented, tracked, and worked to resolution • Issue Log

5 Project is within budget • Project status• Budget management

6 Independent Verification and Validation• Periodic reviews• Respond to

identified issues and risks

7 Project completed based on the original project scope and approved scope changes

• Project Management Plan

• Change Control Process

• Scope Management• Steering Committee

Meeting Decisions

PAGE | 34


6.7.2 P6.7.2 PROJECTROJECT ANDAND P PRODUCTRODUCT R REVIEWEVIEW AND ASSESSMENTS AND ASSESSMENTSReview Type Quality Standard Tools Reviewer Reports

Requirements Requirements are created with input from all project team members, approved by project team and the Steering Committee

Meetings, MS Project, Visio, and other software

Project TeamProject Director

Monthly or as presented

Plans Plans are created with input from all project team members, approved by project team and the Steering Committee

Meetings, MS Project, Visio, and other software

Project TeamProject Director


Milestones Milestones are met by date; reported to Steering Committee

MS Project Project DirectorSteering Committee


Testing Test results verified by Project Team testing resources

Various software packages

Project Team Test Plan and acceptance testing report

6.7.3 A6.7.3 AGENCYGENCY/C/CUSTOMERUSTOMER S SATISFACTIONATISFACTION

The project manager should assess the on-going sense of the customer agency about how they feel the project is going, and how team members are acting on the project. This feedback would be helpful to the success of the project and the professional growth of the project team members.

Examples:

Areas of feedback When How Often

Agency awareness Feedback from the NMDOH PHD employees and end-users

Monthly

Quality of communications Feedback during the various meetings

At Project Team meetings and Steering Committee meetings; other meetings when held

Manages project tasks Feedback from Project Sponsor, Steering Committee, Project Director

Monthly

Productive Meetings Feedback from Project Sponsor, Monthly and per phase of the

PAGE | 35


Steering Committee, Project Director, Project Team

project

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESSHow the client takes procession of the product. Delivery of media; manuals; contracts; licenses; services agreements; configuration settings; status of patches to COTS products; in-house or vendor developed code; test cases, routines, and scripts; and other items required to operate the product.

Deliverable Final Approval Process Customer Acceptance Criteria

Environment Project Team Review; Project Director sign-off

Training, Test and production environments are available for configuration

ConfigurationProject Team Review; Project Director sign

System set up per agreed upon configuration and work flow documents

Testing Project Team Review; Project Director sign

Testing environment set up and system tested for accuracy

Training Project Team Review; Project Director sign

Training completed based upon agreed training plan and training documents

6.8 CONFIGURATION MANAGEMENT6.8 CONFIGURATION MANAGEMENTConfiguration Management determines how project information (files, reports, designs, memos, documents, etc.) will be managed (tracked, approved, stored, secured, accessed, version control, etc.) and owned by (e.g., Agency managing the project or the Customer). Standards and team awareness are critical.

6.8.1 V6.8.1 VERSIONERSION C CONTROLONTROL

Documents will be stored on the NMDOH SharePoint server in the BEHR Upgrade Project Folder. If a document needs to be changed or updated, the document must be saved and renamed. After changes or updates are made, the renamed document is saved to the project shared folder. Larger documents such as the Project Management Plan will be controlled by the revision history log. Entries will be made into the revision history log when changes are made. A copy of the Project Library will be placed on a PHD share drive on a monthly basis.

PAGE | 36


6.8.2 P6.8.2 PROJECTROJECT R REPOSITORYEPOSITORY (P (PROJECTROJECT L LIBRARYIBRARY))“Provide to the Department all project management and product deliverables. Deliverables shall include but not limited to the project plan, project schedule, initial and periodic risk assessments, quality strategies and plan, periodic project reports, requirements and design documents for entire project. The lead agency must make available all deliverables in a repository with open access for the Department to review” PROJECT OVERSIGHT PROCESS Memorandum.

The BEHR Upgrade Project has a folder on a PHD share drive and on the NMDOH SharePoint server for all project documentation.

6.9 PROCUREMENT MANAGEMENT PLAN6.9 PROCUREMENT MANAGEMENT PLANProjects often have some element of procurement, i.e. the requirement to purchase goods and/or services from outside the organization. The procedures to be used to handle these procurements should be included here. Activities such as a make-or-buy analysis; writing requirements; solicitation planning, evaluation and selection; inspection and acceptance; contract closeout should all be included.The BEHR Upgrade Project will be accomplished using an amendment under the existing contract with Mednetworx. The procurement will follow the State Purchasing Division’s process and protocol.

The IV&V vendor will be procured executing a contract against a statewide price agreement.

7. 0 PROJECT CLOSE7. 0 PROJECT CLOSEProject Close will always consist of administrative project activities and possibly contractual project activities and an external vendor is employed. Completing both sets of activities is a mandatory step in the project life cycle. Administrative activities complete the internal needs for the Agency/Unit that is responsible for managing the project, such as lessons learned, recording the last hours against the project, and providing transition for the staff to other assignments. Contractual activities meet the contractual needs, such as executing a procurement audit and formal acceptance of the project work products. Project Close consists of administrative project activities and contractual project completion activities. It is important for the proper project closeout to complete both sets of activities. Administrative closeout activities complete the agency requirements for the NMDOH who is responsible for managing the project. This includes developing the lessons learned, processing the last of the invoices, and providing a transition plan for system and staff to the production mode. Contract closeout activities complete the contracting requirements, such as the formal acceptance of the project work products and final invoice processing. Required documentation and presentations will also be completed.

7.1 A7.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE

Administrative Close occurs at both the end of phase and end of project. This closure consists of verification that objectives and deliverables were met. Acceptance is formalized and phase activities are administratively closed out. Administrative closure occurs on a “by-phase” basis in accordance with the WBS and should not be delayed to project end. At that point, the burden of closing is too great and audits inaccurate. The specific project close activities for a given project are contingent on the project’s complexity and size. Project managers should work with the

PAGE | 37


project’s project management consultant to tailored Project Close procedures to compliment the project’s objectivesAdministrative Close occurs at both the end of each phase and at the end of project. This closeout activity consists of verification that deliverables were met. Acceptance is formalized and phase activities are administratively closed out. The identification of closeout activities for the BEHR Upgrade Project will be the final deployment of the upgrade and the transition to production. The final closeout will include the completion of NMDOH documentation, the DoIT closeout report and a presentation to the DoIT Project Certification Committee for approval to formally close the project.

7.2 C7.2 CONTRACTONTRACT C CLOSELOSE

Contract close is similar to administrative close in that it involves product and process verification for contract close.Contract closeout activities will include the verification of all contracting requirements, deliverables, and work products. It will also include confirming that all final invoices have been submitted for the Project.

PAGE | 38