New Mexico Department of Health

Public Health Division

Billing and Electronic Health Record (BEHR) Upgrade

PROJECT MANAGEMENT PLAN
(PMP)

Executive Sponsor – Jane Peacock, MS
Director, Public Health Division
Business Owner - Maggi Gallaher, MD, MPH
Medical Director, Public Health Division
Project Manager – Michael Snouffer
Original Plan Date: September 3, 2013
Revision Date: N/A
Revision: 1.0

Project Management Plan for [Project Name]

Revision History

Preparing the Project Management plan

About This Document

Project Oversight Process Memorandum – DoIT, July 2007

1.0 Project Overview

1.1 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.1 Describe the organizational structure – Org Chart

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.6.2 Metrics Library

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

AttachmentS

Revision History

Revision Number / Date / Comment
1.0 / July 27th, 2007 / DoIT Project Management Office Revision
2.0
2.1
2.2

Preparing 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 Document

Project 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.0DoIT-PMO-TEM-0201 of vi

Project Management Plan for [Project Name]

1.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.1Executive 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 sources

Source / Amount / Associated restrictions / Approvers
General Appropriations Act of 2010, Laws 2010, Chapter 6, Section 4, Department of Health General Fund Appropriation. / $250,000 / None / Jane Peacock

1.3 constraints

Constraints are factors that restrict the project by scope, resource, or schedule.

Number / Description
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 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 / EHR upgrade must be completed before ICD-10 Conversion can begin. / M,E

1.5 ASSUMPTIONS

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

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

1.6 Initial Project Risks Identified

In 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 Engagement

Description - Project will be at risk if all stakeholders are not engaged at the beginning of the project. / Probability
Low / Impact
High
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
Low / Impact
High
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
Low / Impact
High
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 Structure

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 Stakeholders

List 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.

name / Stake in Project / Organization / Title
Jane Peacock, MS / Executive Sponsor / Public Health Division (PHD) / Director
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 Structure

2.2.1 Describe the organizational structure – Org Chart

2.2.2 Describe the role and members of the project steering committee

Name / Group / Role / Responsibility
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 Committee Member /
  • Provide Information Technology guidance
  • Attend and participate in meetings
  • Review and accept deliverables
  • 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 Organizational Boundaries, interfaces and responsibilities

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.

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 Reporting

The 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 Scope

3.1 Project Objectives

3.1.1 Business Objectives

Number / Description
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.

3.1.2 Technical Objectives

Number / Description
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 exclusions

Implementation 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 Factors

Identify 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.

Number / Description
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.

4.0 Project Deliverables and methodology

4.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 Project Management Deliverables

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