New Mexico Department of Health

New Mexico Department of Health Health Emergency Management (HEM) Systems

PROJECTPROJECT MANAGEMENTMANAGEMENT PLANPLAN (PMP)(PMP)

EXECUTIVE SPONSOR: KAREN ARMITAGE, MD BUSINESS OWNER: MARY SCHUMACHER PROJECT MANAGER: DARSHANA KANABAR ORIGINAL PLAN DATE: APRIL 16, 2010 REVISION DATE: APRIL 16, 2010 REVISION: 1.0 Project Management Plan for HEM SYSTEMS

REVISION HISTORY...... III 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...... 1 1.2 funding and sources...... 3 1.3 constraints...... 3 1.4 dependencies...... 3 1.5 ASSUMPTIONS...... 4 1.6 Initial Project Risks Identified...... 4 2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE...... 5 2.1 Stakeholders...... 5 2.2 Project Governance Structure...... 5 2.2.1 Describe the organizational structure – Org Chart...... 5 2.2.2 Describe the role and members of the project steering committee...... 6 2.2.3 Organizational Boundaries, interfaces and responsibilities...... 10 2.3 Executive Reporting...... 11 3.0 SCOPE...... 11 3.1 Project Objectives...... 11 3.1.1 Business Objectives...... 11 3.1.2 Technical Objectives...... 11 3.2 Project exclusions...... 12 3.3 Critical Success Factors...... 12 4.0 PROJECT DELIVERABLES AND METHODOLOGY...... 12 4.1 Project Management Life Cycle...... 12 4.1.1 Project Management Deliverables...... 13 4.1.2 Deliverable Approval Authority Designations...... 15 4.1.3 Deliverable Acceptance Procedure...... 15 4.2 PRODUCT LIFE CYCLE...... 15 4.2.1 Technical Strategy...... 16 4.2.2 Product and Product Development Deliverables...... 16 4.2.3 Deliverable Approval Authority Designations...... 18 4.2.4 Deliverable Acceptance Procedure...... 18 5.0 PROJECT WORK...... 19 5.1 Work Breakdown Structure (WBS)...... 19 5.2 Schedule allocation -Project Timeline...... 19 5.3 Project Budget...... 20 5.4 Project Team...... 21 5.4.1 Project Team Organizational Structure...... 21 5.4.2 Project Team Roles and Responsibilities...... 21 5.5 STAFF PLANNING AND Resource ACQUISITION...... 22 5.5.1 Project Staff...... 22 5.5.2 Non-Personnel resources...... 22 5.6 PROJECT LOGISTICS...... 22

REVISION: 1.0 DOIT-PMO-TEM-020 I OF VI Project Management Plan for HEM SYSTEMS

5.6.1 Project Team Training...... 23 6.0 PROJECT MANAGEMENT AND CONTROLS...... 23 6.1 Risk and issue Management...... 23 6.1.1 Risk Management Strategy...... 23 6.1.2 Project Risk Identification...... 23 6.1.3 Project Risk Mitigation Approach...... 23 6.1.4 Risk Reporting and Escalation Strategy...... 23 6.1.5 Project Risk Tracking Approach...... 23 6.1.6 ISSUE MANAGEMENT...... 24 6.2 INDEPENDENT Verification And Validation - Iv&V...... 24 6.3 Scope Management Plan...... 25 6.3.1 Change Control...... 25 6.4 Project Budget Management...... 25 6.4.1 Budget Tracking...... 25 6.5 Communication Plan...... 25 6.5.1 Communication Matrix...... 26 6.5.2 Status Meetings...... 26 6.5.3 Project Status Reports...... 26 6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)...... 26 6.6.1 Baselines...... 26 6.6.2 Metrics Library...... 27 6.7 QUALITY OBJECTIVES AND CONTROL...... 27 6.7.1 quality Standards...... 27 6.7.2 Project and Product Review AND ASSESSMENTS...... 28 6.7.3 Agency/Customer Satisfaction...... 29 6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS...... 29 6.8 CONFIGURATION MANAGEMENT...... 30 6.8.1 Version Control...... 30 6.8.2 Project Repository (Project Library)...... 30 6.9 PROCUREMENT MANAGEMENT PLAN...... 30 7. 0 PROJECT CLOSE...... 30 7.1 Administrative Close...... 31 7.2 Contract Close...... 31

REVISION: 1.0 DOIT-PMO-TEM-020 II OF VI Project Management Plan for HEM SYSTEMS

REVISION HISTORY

REVISION NUMBER DATE COMMENT 1.0 April 16, 2010 For Planning PCC certification 2.0 2.1 2.2

REVISION: 1.0 DOIT-PMO-TEM-020 III OF VI Project Management Plan for HEM SYSTEMS

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

1 “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.

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

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

4 “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.

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

6 “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 Project Management Plan for HEM SYSTEMS

1.0 PROJECT OVERVIEW

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT The New Mexico Department of Health (NMDOH) Bureau of Health Emergency Management (BHEM) utilizes IT systems to help prepare for and manage health emergencies within the State of New Mexico in compliance with requirements set forth by two agencies within the federal government: the Centers for Disease Control and Prevention (CDC) and the Assistant Secretary for Preparedness and Response (ASPR), both of which are part of the Department of Health and Human Services (HHS) and both of which provide significant funding for this work.

The purpose of this project is to procure and implement four such applications required to continue to meet both state and federal needs. All four systems, and their current operational status, are identified below.

1. National Hospital Available Beds for Emergencies and Disasters (HAvBED): Each State is required to develop and maintain an electronic bed polling system for providers and decision makers to capture, track, and understand acute hospital and alternative care-site bed availability in “real time” on a local, regional, and national basis.

In New Mexico, a HAvBED system has been in use for several years. Called EMResource, the software is provided by EMSystems, Inc., which also provides off-site hosting of the application in its datacenter, as well as all system and application support functions. Currently this system is acquired on a month-to- month basis and is paid by federal grant funds from ASPR.

2. Emergency Systems for the Advance Registration of Volunteer Health Professionals (ESAR-VHP): Each State is required to develop an electronic registration system for recording and managing volunteer information based on the data definitions presented in the Interim ESAR-VHP Technical and Policy Guidelines, Standards and Definitions (Guidelines).

In New Mexico, an ESAR-VHP system called EMCredential has been in use for more than two years in the NMserves program. The software is provided by EMSystems, Inc., which also provides off-site hosting of the application in its datacenter, as well as all system and application support functions. Currently this system is acquired on a month-to-month basis, and is paid by federal grant funds from ASPR.

3. Patient Tracking: Each State will be required to implement an electronic tracking system to track patients from admission to discharge or transfer to another facility on a regional or national basis. Patient tracking is a new requirement from ASPR. No version exists in New Mexico at this time.

PAGE | 1 Project Management Plan for HEM SYSTEMS

4. Health Alert Network (HAN): Each state is required to implement a targeted alerting system to enable public health practitioners to prepare for and respond to public health threats and emergencies. The HAN must provide secure and redundant methods to rapidly communicate critical emergency or emergent situation information to the appropriate key providers in the public health arena. Therefore, its primary design principles are to ensure survivability and continuous operations in the face of extreme circumstances, and to do so in full compliance with the Public Health Information Network (PHIN) requirements established by CDC.

HAN systems have been in use in New Mexico for approximately ten years; however the current system is based on aged technologies and requires replacement. It has not proved able to satisfactorily meet all CDC and BHEM requirements, over time, and pending requirements from CDC this year will render it entirely obsolete. The current system is based on software called CityWatch, from Avtex, Inc., and the annual maintenance and support agreement expires in May, 2010. CityWatch is implemented at an off-site data center and the annual co-location agreement (with BigByte, Inc.) for that facility expires in June, 2010. DOH ITSD is currently negotiating with both vendors for the month-to-month agreements needed to bridge the gap until the procurement and implementation of a new system is complete. The HAN maintenance, support, and operational expenses are paid from the Public Health Emergency Preparedness (PHEP) grant administered by CDC.

It is the intent of NMDOH to pursue commercial-off-the-shelf (COTS) application software to meet the requirements above. Custom developed software would require much too long, cost too much, and represents too great a risk. For procurement, the RFP process will be used in compliance with state purchasing regulations and practices and to minimize lengthy justifications that would be required for other options.

For deployment, either a locally hosted solution, at the NM state data center (DoIT), or a vendor-hosted software as a service (SaaS) solution will meet the requirements. The RFP will require interested vendors to propose both options for all four applications.

Costs and schedules associated with this project are rough estimates. Until the RFP is issued and proposals are received, it will be difficult to schedule or budget the project with any degree of certainty, and a true cost picture will depend on which implementation strategy is chosen, the vendor-hosted SaaS solution or the solution locally hosted at DoIT data center. The range of project implementation costs are estimated at $290,000 to $325,000 and are based on a COTS solution provided by the existing system provider for all four applications.

Ongoing costs for production operations and support services are roughly estimated at $300,000 to $350,000 a year.

1.2 FUNDING AND SOURCES

SOURCE AMOUNT ASSOCIATED APPROVERS RESTRICTIONS H1N1 Influenza $ 240,000 Grant expires and money must be DOH/ERD/BHEM; Grant spent by end of July 2010. CDC (for new HAN) Program has requested carry-over funding for these unspent monies; however, no decision has yet been made at the federal level. Failing carry-over approval, program area intends to fund from CDC Cooperative Agreement for Public Health Emergency Preparedness and Response.

ASPR Grant $ 80,000 End of current grant-year is June DOH/ERD/BHEM; (for new HAvBED, 30, 2010. Program area will ASPR ESAR-VHP, and make money available from new Patient Tracking) grant year funding.

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

NUMBER DESCRIPTION 1 Project is potentially constrained by the ability to find multiple providers who can meet all the requirements for all the applications specified, resulting in limited choices and limited competition in the marketplace.

2 The scope of the project is constrained by the existing grant funding that has been identified for this project.

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 Existence of system vendor(s) with the ability to meet all of the M, E mandatory requirements set forth in this RFP.

NUMBER DESCRIPTION TYPE M,D,E 3 Successful negotiation of contract terms and conditions, and scope of M, E work, meeting the needs of the program areas, DoIT, State Purchasing, and selected vendor, and resulting in a contract award.

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

NUMBER DESCRIPTION 1 Epidemiology and Response Division, Bureau of Health Emergency Management will provide appropriate resources for the project team(s).

1.6 INITIAL PROJECT RISKS IDENTIFIED

Risk 1 - Project Cost Estimates Description - Probability Impact Project costs are estimates Medium HIGH until the RFP process is Mitigation Strategy – Accept this risk until vendor, hosting option, and completed. Choice of system costs are accurately defined by the RFP evaluation and contract award. provider and determination of In the meantime, DOH is working with DoIT to ensure that all hosting hosting option will have requirements, infrastructure needs, and support requirements are well major impact on the actual understood, and accurate costs defined. costs of this initiative. Contingency Plan – Project team and Executive sponsor understand the inherent nature of this risk. Any changes in budget will be accounted for in the upcoming grants.

Risk 2 - Funding Uncertainty Description - Probability Impact All funding is federal grant High HIGH based. In general these funds Mitigation Strategy – Program area has petitioned CDC for permission have been secure; however, to carry-over funds. Failing that, program area will seek alternate H1N1 funding that is funding, approved for the HAN system Contingency Plan – project will be prepared to remove HAN acquisition and requirements from the project scope. implementation comes with an impending time- restriction, funds must be expended by July 31, 2010

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE

2.1 STAKEHOLDERS NAME STAKE IN PROJECT ORGANIZATION TITLE Dr. Karen Armitage Agency Executive Sponsor NMDOH Chief Medical Officer Mack Sewell State Epidemiologist NMDOH State Epidemiologist Mary Schumacher Project Director NMDOH/BHEM Bureau Chief Department of Health Commitment to Citizens of New NMDOH Agency Mexico to provide and oversee health emergency response planning and services. Wynn Brannin HAvBED and Patient Tracking NMDOH/BHEM Interoperable coordinator and subject matter expert. Communications Coordinator Paulette Johnston Primary HAN administrator, user, and NMDOH/BHEM HAN subject matter expert. Administrator Bobbie MacKenzie ESAR-VHP coordinator and subject NMDOH/BHEM NMserves matter expert. Member Services Coordinator Public health External providers of data and users of Various Various preparedness and systems’ information. response communities, including federal, state, and local. Federal partners – Source of requirements and funding; CDC and ASPR Various CDC and ASPR. program oversight and compliance.

2.2 PROJECT GOVERNANCE STRUCTURE 2.2.1 DESCRIBE THE ORGANIZATIONAL STRUCTURE – ORG CHART

EXECUTIVE SPONSOR Karen Armitage

STEERING COMMITTEE Independent Verification and Exec Sponsor Validation Proj Director (Consultant) ITSD Mgr.

Project Director Mary Schumacher

Project Manager Darshana Kanabar

Business Process Tech Lead Vendor Business Owners Team/SMEs Ed Rose Project Manager

PATIENT HAVBED ESAR VP HAN Vendor TRACKING Wynn Brannin Bobbie Mackemzie Paulette Johnston Project Staff Wynn Brannin

2.2.2 DESCRIBE THE ROLE AND MEMBERS OF THE PROJECT STEERING COMMITTEE

NAME FUNCTIONAL ROLE RESPONSIBILITY AREA Karen Armitage, Chief Medical Project Executive Ensure project staff availability, funding, MD Officer, DOH Sponsor and contract management

Steering Review and accept the initial risk Committee assessment, management plan, project plan, Member 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

NAME FUNCTIONAL ROLE RESPONSIBILITY AREA Mary Bureau Chief, Project Director Facilitate Steering Committee Meetings Schumacher DOH Health Emergency Steering Participate in planning sessions Management, Committee Member 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

Contribute to lessons learned

NAME FUNCTIONAL ROLE RESPONSIBILITY AREA Sean Pearson Deputy CIO, Steering Provide Information Technology guidance DOH Committee Information Member Attend and participate in meetings Technology Services Review and accept deliverables Division Review presented documentation

Balance larger picture versus details of project

Review project funding and expenditures

NAME FUNCTIONAL ROLE RESPONSIBILITY AREA Darshana DOH ITSD Project Manager; Develop initial management plan and Kanabar procurement project plan manager. Provide leadership for a coordinated Steering project effort Committee Advisory Document project assumptions, constraints, Member and critical success factors

Conduct initial risk assessment and facilitate continuous risk identification and mitigation

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 and actions log

Promote and practice change management

Close-out action items

Value teamwork, cooperation, and planning

Facilitate lessons learned process

2.2.3 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES The HEM Systems Project will work closely with the Department of Information Technology (DoIT) for RFP review and approval, contracting review and approval, project status reporting, technical standards, and hosting strategy oversight. NMDOH will also continue to work with provider organizations, primarily hospitals, other public health providers, and emergency first responders throughout the state, and where appropriate include their participation with the HEM Systems Project.

2.3 EXECUTIVE REPORTING The project manager will communicate regularly on all aspects of the project.  The PM will meet with the Steering Committee at least once every two months. Notes of the meeting will be published by the PM and be distributed to the Steering Committee and the Project Team.  Status on progress, schedule, issues, and risks will be provided through the DOH ITSD weekly project reporting process.  As a certified project, monthly progress reports will be submitted using the standard DoIT template.

3.0 SCOPE

3.1 PROJECT OBJECTIVES 3.1.1 BUSINESS OBJECTIVES NUMBER DESCRIPTION BUSINESS OBJECTIVE 1 Provide the systems and processes to prepare for and manage health threats and emergencies within the State of New Mexico, as well as provide assistance to other jurisdictions at the regional or national level, as needed. BUSINESS OBJECTIVE 2 Meet the CDC and ASPR requirements for information, compliance, and participation, supporting the ability for continued receipt of CDC and ASPR grant fund. BUSINESS OBJECTIVE 3 HAvBED: Procure and implement an electronic bed polling system in accordance with DOH/BHEM needs and federal guidance from ASPR. BUSINESS OBJECTIVE 4 ESAR VHP: Procure and implement an electronic registration system for recording and managing volunteer information in accordance with DOH/BHEM needs and federal guidance established by ASPR. BUSINESS OBJECTIVE 5 PATIENT TRACKING: Procure and implement an electronic patient tracking system in accordance with DOH/BHEM needs and federal guidance from ASPR. BUSINESS OBJECTIVE 6 HAN: Procure and implement a health alert network to help prepare for and respond to public health threats and emergencies in accordance with DOH/BHEM needs and in full compliance with the Public Health Information Network (PHIN) requirements established by CDC. BUSINESS OBJECTIVE 7 Ensure complete compliance with State procurement regulations and federal grant procedures.

3.1.2 TECHNICAL OBJECTIVES NUMBER DESCRIPTION TECHNICAL OBJECTIVE Complete and accurate specification of known requirements for 1 systems technology and infrastructure. TECHNICAL OBJECTIVE Ensure systems compliance with all state and agency system 2 architecture requirements. TECHNICAL OBJECTIVE Procure, evaluate, and implement a web-based solution for each of 3 the four targeted systems.

NUMBER DESCRIPTION TECHNICAL OBJECTIVE Meet all mandatory Technical Requirements specified in Appendix 4 F.5 of the HEM Systems RFP.

3.2 PROJECT EXCLUSIONS No project exclusions are known at this time.

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 The new HAvBED application will, at a minimum, provide equivalent 1 functionality as the existing system, and meet all mandatory requirements as specified in Appendix F.1 of the HEM Systems RFP. QUALITY METRICS The new ESAR-VHP application will, at a minimum, provide 2 equivalent functionality as the existing system, and meet all mandatory requirements as specified in Appendix F.2 of the HEM Systems RFP. QUALITY METRICS The new Patient Tracking application will, at a minimum, meet all 3 mandatory requirements as specified in Appendix F.3 of the HEM Systems RFP. QUALITY METRICS The new HAN application will, at a minimum, provide equivalent 4 functionality as the existing system, and meet all mandatory requirements as specified in Appendix F.1 of the HEM Systems RFP.

4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE

Phase Summary of Phase Key Deliverables Proposal (Internal DOH) This phase announces the need Project Proposal and identifies the approximate extent of the project for program and IT management. The approved proposal serves as the trigger for beginning project initiation activities. Initiation This phase defines overall Project Charter, Initial Risk parameters of the project and Assessment, High level schedule, establishes the appropriate Procurement Strategy, Approval project management and quality for next phase environment required to complete the project.

Planning This phase defines the exact Project Management Plan, Team parameters of the project and members identified, Final scope ensures all the pre-requisites for statement, High level WBS, execution and control are in Resources identified, High level place. Schedule, Budget and Communication Plans, Roles and Responsibilities, Status reports, Approval for next phase Implementation The phase configures and Configuration Documentation, deploys the system. Testing Documentation, Training Documentation, Updated Project Schedule, Updated Budget, Risk Management Log, Issue Log, Status Report, Acceptance Closeout The phase assesses the project Post Implementation Review and and documents any lessons Report, Administrative Close- learned and/or best practices. 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.

4.1.1.1 Project Proposal (Internal DOH) Description – The project proposal Deliverable Acceptance Criteria announces the need and identifies the Sign-off by DOH CIO. approximate extent of the project for Standards for Content and Format - program and IT management. The DOH ITSD project proposal template. approved proposal serves as the trigger Quality Review – for beginning project initiation activities. Peer review within Implementation Services Bureau. Content review with key program area personnel.

4.1.1.2 Project Charter Description – Deliverable Acceptance Criteria - The Initiation phase will include Sign-off by Project Sponsor or Project Director the Project Charter as a main deliverable. This deliverable may Standards for Content and Format – be revised during planning. Use of DoIT Project Charter template

Quality Review – Peer review for grammar and spelling

Key project team members review for consensus

4.1.1.3 Project Management Plan Description – Deliverable Acceptance Criteria – The Project Management Plan will Approval by Project Team and Steering Committee be the guide used throughout the Sign-off by Project Sponsor or Project Director project. This plan will contain the Standards for Content and Format – following plans Scope Use of DoIT Project Management Plan template Management, Schedule Quality Review – Management, Budget, Risk Peer review for grammar and spelling Management, Communications, Change Management, Lessons Key project team members review for consensus learned and Roles/Responsibilities Final review by Steering Committee, Project Director and of team members. This plan is an Sponsor evolving document as new information will be added and existing information will be revised during initiation and planning.

4.1.1.4 Project Status Reports Description – Project status Deliverable Acceptance Criteria – Steering Committee and reporting will include weekly DoIT. reports to DOH ITSD and Standards for Content and Format – depends on the report: program management, monthly ITSD report formats and standards; DoIT template; specific progress reporting on the ITSD IV&V content based on contracted scope of work. dashboard, monthly progress Quality Review – Peer review for grammar and spelling reporting to DoIT, and contracted IV&V reporting Key project team members review for consensus according to its established schedule. Recipient agency or office review for content and clarity.

4.1.1.5 Project Closeout Report Description - The close-out report Deliverable Acceptance Criteria – sign off by DoIT. provides the opportunity to evaluate the project against its Standards for Content and Format - functional, technical, and financial Post Implementation Review and Report, Administrative goals, and documents lessons Close-Out Report. learned and best practices. Sign- Quality Review -. off by DoIT officially closes the Key project team members review for consensus. project. DoIT acceptance for content; sign-off.

4.1.2 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS 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. DELIVERABLE DELIVERABLE APPROVERS (WHO DATE NUMBER CAN APPROVE) APPROVED 1 Project Proposal Robert Mayer 09/10/2009 2 Project Charter Mary Schumacher 10/15/2009 3 Project Management Plan (PMP) Mary Schumacher 4 Project Close-out Report Mary Schumacher, DoIT

4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE

The Project Director will review and the Project Sponsor will accept the project documents, including the formal acceptance and sign-off for this Project Management Plan.

4.2 PRODUCT LIFE CYCLE

Phase Summary of Phase Key Deliverables Requirements Definition and documentation Requirements documents – of mandatory and desirable direct input to procurement characteristics of the HEM phase. systems. Procurement Conduct of the entire RFP RFP; negotiated, signed process: development and contract to perform work issuance of the RFP; specified in an agreed-to scope evaluation of proposals; of work. selection of vendor; negotiation of contract. Configuration Review of requirements and System configuration detailed understanding of business need – both system and process. Gap analysis issues resolved and initial system configuration. Installation Implementation of chosen Complete system environments systems, configured as specified, ready for data load and testing. and prepared for conversion and testing phases. Conversion Preparation of specific data Capture of existing data assets in formats for conversion and the new systems. migration to installed systems. Testing Testing of installed Test plan and final acceptance. configurations and data. Training Training on system – both Training documentation and user

technical and process. list. Deployment Deployment of system to all Deployment Strategy, Final User trained users, both Agency and List, Shift to Transition to external users and providers. Operations/Production Transition to Completed System Deployment Training, Manuals, Transition to Operations/Productions and move to close-out Project. Operations/Application Support Plan

4.2.1 TECHNICAL STRATEGY Discuss the key technical strategies for achieving success in this project.  The project will pursue COTS solutions only.  All solutions will include and ensure adequate backup/recovery and disaster recovery/failover capabilities for all critical components.  Leverage on existing data assets and infrastructure wherever possible. O Ensure data capture, translation or conversion processes and methodologies are included in project requirements.  Ensure technology choices and decisions support or comply with federal requirements as specified by CDC and ASPR.

4.2.2 PRODUCT AND PRODUCT DEVELOPMENT DELIVERABLES 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.

4.2.2.1 Requirements Documents Description - Requirements Deliverable Acceptance Criteria – documents – direct input to Sign-off by Project Team, Director procurement phase. Standards for Content and Format – MS Word, Excel, Visio, and Adobe PDF Quality Review – Reviewed by project team members, director, and sponsor for completeness

4.2.2.2 Procurement Documents Description – Procurement Deliverable Acceptance Criteria – documents: RFP and contract. Sign-off by Project Team, Director, DoIT, and State Purchasing.

Standards for Content and Format – SPD RFP template; DoIT contract template. Quality Review – Reviewed by project team members, director, and sponsor for completeness. Contract review by DOH General Counsel and DoIT.

4.2.2.3 System Configuration Description - Review of Deliverable Acceptance Criteria – requirements and detailed Sign-off by Project Team understanding of business need – Standards for Content and Format – both system and process. Gap MS Word, Excel, Visio, and Adobe PDF analysis issues resolved and initial Quality Review – Reviewed by project team members, system configuration. director, and sponsor for completeness

4.2.2.4 Installation Description - Complete system Deliverable Acceptance Criteria – environments ready for data load Sign-off by Project Team and testing. Standards for Content and Format – MS Word, Excel, Visio, and Adobe PDF Quality Review – Reviewed by project team members, director, and sponsor for completeness

4.2.2.5 Conversion Description – Conversion Deliverable Acceptance Criteria – Capture of existing data assets in Sign-off by Project Team, project manager, technical lead the new systems. Standards for Content and Format – MS Word, Excel, Visio, and Adobe PDF Quality Review – Reviewed by project team members, director, and sponsor for completeness

4.2.2.6 Testing Description - Test plan and final Deliverable Acceptance Criteria – acceptance. Sign-off by Project Team, project manager, technical lead Standards for Content and Format – Executed test plan; MS Word, Excel, Visio, and Adobe PDF Quality Review – Reviewed by project team members, director, and sponsor for completeness

4.2.2.7 Training Description – Documented, Deliverable Acceptance Criteria – completed training and user list. Sign-off by Project Team, project manager, technical lead Standards for Content and Format – MS Word, Excel, Visio, and Adobe PDF Quality Review – Reviewed by project team members, director, and sponsor for completeness

4.2.2.8 Deployment Description - Deployment Deliverable Acceptance Criteria – Strategy, Final User List, System Sign-off by project manager, project director, sponsor, and Acceptance technical lead Standards for Content and Format – MS Word, Excel, Visio, and Adobe PDF Quality Review – Reviewed by project manager, technical lead, project team members, director, and sponsor for completeness

4.2.2.9 Transition to Operations Description - Transition to Deliverable Acceptance Criteria – Operations/Application Support Sign-off by DOH ITSD Plan; Close-out Report. Standards for Content and Format – Applications Support Plan template (ITSD); DoIT Close-out Report template. Quality Review – Reviewed by project team members, director, and sponsor for completeness

4.2.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS 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.

DELIVERABLE DELIVERABLE APPROVERS (WHO DATE NUMBER CAN APPROVE) APPROVED 1 Requirements Project director 3/31/10 2 Procurement Project director; SPD; DoIT 3 Configuration Project director 4 Installation Project director 5 Conversion Project director 6 Testing Project director 7 Training Project director 8 Deployment Project director 9 Transition/Close-out ITSD; DoIT 4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE As part of the Deliverable Acceptance Procedure, the Project Team, including the project manager and technical lead, 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.

5.0 PROJECT WORK

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 Project Charter, Initial parameters of the project Risk Assessment, High- and establishes the level schedule, appropriate project Procurement Strategy, management and quality Approval for next phase. environment required to complete the project 2.0 Planning Phase This phase identifies the Approval from appropriate implementation approach, state agencies on procurement method and procurement method, establishes all necessary System Selection, Contract documentation. negotiated and executed, and preparation for Implementation. Approval for next phase. 3.0 Implementation Phase This phase deploys the Configuration, Installation, system to a prepared set of Conversion, Testing, users and positions on- Training, and Deployment. going support and maintenance. 4.0 Closeout Phase This phase closes out the Closeout report, Transition project and completes the to Operations and Transition to Operations Production document, and Production. Application Support Plan.

5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE The project timeline is a high-level view of project activities with a focus on project milestones. This timeline highlights key project phases. A more detailed project schedule will be created during the planning phase itself.

Task/Activity Name Resource Milestone Start Finish Dependent Task Name (Y/N)

Initiation Phase Project Y 9/10/09 10/28/09 Manager

Planning Phase Project team Y 04/28/10 09/01/10 Completion of Initiation Phase

Implementation Project team Y 9/2/10 12/29/10 Completion of Phase Develop/Test Phase

Closeout Phase Project team Y 12/29/10 01/31/2011 Completion of Implementation Phase

Product Deliverables

Request for Project Y 10/28/09 04/30/10 Initiation Certification Proposals Manager

RFP Evaluation Evaluation Y 04/30/10 07/07/10 RFP Evaluation, Report Committee Selection of most advantageous proposal

IT Professional Project Y 07/07/10 09/01/10 Approved Evaluation Services Contract Manager Report

Operational System Project Team Y 09/01/10 12/29/10 Executed contract and – statement-of-work HAvBED

Operational System Project Team Y 09/01/10 12/29/10 Executed contract and – statement-of-work ESAR-VHP

Operational System Project Team Y 09/01/10 12/29/10 Executed contract and – statement-of-work Patient Tracking

Operational System Project Team Y 09/01/10 12/29/10 Executed contract and – statement-of-work HAN

5.3 PROJECT BUDGET Costs associated with this project budget are rough estimates. Until the RFP is issued and proposals are received, it will be difficult to schedule or budget the project with any degree of certainty, and a true cost picture will depend on which implementation strategy is chosen, the vendor-hosted SaaS solution or the solution locally hosted at DoIT data center. The range of minimum project implementation costs are estimated at $290,000 to $325,000 and are based on extending a SaaS strategy with an existing system provider for all four applications.

Identifier Work Package or Budget Category Cost 1 HAvBED System/Service (cost if incumbent chosen) $0 2 ESAR-VHP System/Service (cost if incumbent chosen) $0 3 Patient Tracking System/Service $65,000 4 HAN System/Service $240,000 5 IV&V Consultant $15,000 TOTAL 320,000

5.4 PROJECT TEAM 5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE

Project Director Mary Schumacher

Project Manager Darshana Kanabar

Business Process Tech Lead Vendor Team/SMEs Ed Rose Project Manager

PATIENT HAVBED ESAR VP HAN Vendor TRACKING Wynn Brannin Bobbie Mackemzie Paulette Johnston Project Staff Wynn Brannin

5.4.2 PROJECT TEAM ROLES AND RESPONSIBILITIES 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.

ROLE RESPONSIBILITY NAME FUNCTIONAL AREA Project Manager Project Manager – to provide Darshana Kanabar DOH/ITSD/ISB project management.

ROLE RESPONSIBILITY NAME FUNCTIONAL AREA Technical Lead To provide technical Ed Rose DOH/ITSD/ASB leadership and to provide project technical resources Business Process To provide business process Wynn Brannin DOH/ERD/BHEM Team and Program Area leadership, Bobbie MacKenzie and subject matter expertise. Paulette Johnston Vendor Project To provide vendor leadership TBD Vendor TBD Manager and ensure project resources Vendor Technical To provide detailed TBD Vendor TBD Team technical and application expertise, and to perform configuration, installation, conversion, testing, training, and deployment tasks as required.

5.5 STAFF PLANNING AND RESOURCE ACQUISITION Complete 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 PROJECT STAFF Estimated Resource Cost Estimate Hours Availability Skill Set Work Product/Deliverable Project Director N/A Unknown 10% various Oversight Project Manager - N/A Unknown 50% PMP Successful project Staff Business Owners - N/A Unknown 50 – 75% Program area Various throughout the SMEs knowledge project IV&V Consultant $15,000 N/A As N/A Project plan for IVV, required initial review, periodic reviews, close-out review. 5.5.2 NON-PERSONNEL RESOURCES Details of the required non-personnel resources such as hardware and software, cannot be known until the RFP process is completed, the product options and delivery methods identified, and the vendor selected.

5.6 PROJECT LOGISTICS The HEM Systems Project Team will use tools available at NMDOH to work together. These tools include telephone calls, conference calls, web meeting, email, and face-to-face meetings. The team will also use resident software packages such as MS Word, Excel, Visio, Project, and Adobe PDF.

5.6.1 PROJECT TEAM TRAINING Project team subject matter experts SME) will also participate in the RFP process, identifying requirements and evaluating proposals. Preparatory training in RFP processes will be performed in conjunction with the assigned procurement analyst from State Purchasing.

6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT 6.1.1 RISK MANAGEMENT STRATEGY Information technology (IT) 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. For this project, the risk management approach will include:  Identifying risks associated with this project.  Categorizing risks by type and severity.  Rating risks by probability and impact.  Managing these risks throughout project duration.  Risk tracking, documentation, and reporting. 6.1.2 PROJECT RISK IDENTIFICATION This is the process of identifying potential risks and documenting the specific characteristics of each. 6.1.3 PROJECT RISK MITIGATION APPROACH 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. 6.1.4 RISK REPORTING AND ESCALATION STRATEGY Once a risk is identified, the Project Manager 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 are then prioritized and assigned a Risk Manager. The risk 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 PROJECT RISK TRACKING APPROACH Potential risks will be tracked and reported using the Risk Log. 6.1.6 ISSUE MANAGEMENT 6.1.6.1 Internal Issue Escalation and Resolution Process When an issue is identified, primarily by the project team, it will be added to the issue log stored in the project library. An issue can also be identified by anyone affiliated with the project

although the project team will be primarily responsible for tracking issues through to resolution. The project team will review the issues list twice a month. Issues, which could negatively impact the project, will be brought to executive sponsor’s attention for resolution. The process of tracking an issue is below:

1) An issue is identified. 2) It is added to the issue document, assigned an issue number with a brief explanation of the issue and date entered. 3) The issue is assigned to someone and potential action to be taken. 4) As action is taken it is noted with the issue. 5) If possible, an estimated completion date is entered. 6) Upon completion of an issue the actual completion date is noted with the resolution.

6.1.6.2 External Issue Escalation and Resolution Process The process for issue escalation and resolution for issues that can not be addressed within DOH, will be handled in the same manner as internal issues. If necessary, resources outside the agency maybe brought in to resolve the issue. At any time it is apparent the issue needs escalation outside of DOH, the Project Sponsor will communicate with the Secretary and ask for assistance in resolving the issue.

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V 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 requiring the procurement of commercial-off-the-shelf (COTS) solutions. The IV&V plan will be tailored to address the unique risks associated with package implementation projects. The IV&V plan will: 1. Evaluate and verify that processes, contracts, and system designs comply with the specified requirements of the Enterprise Architecture and Standards 2. 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 3. 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. . Two Periodic Reviews . Close-out Report

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

6.3.1 CHANGE CONTROL 6.3.1.1 Change Control Process

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 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) During the course of the HEM Systems Project, the Steering Committee will fill the role of the Change Control Board.

6.4 PROJECT BUDGET MANAGEMENT Costs 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 BUDGET TRACKING The spreadsheet for budget tracking will be created during the planning process and following the selection of vendor through the RFP evaluation process.

6.5 COMMUNICATION PLAN 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, Special Bulletins will be distributed as needed. Status, issues, and risks will also be discussed at regularly scheduled project meeting on a monthly basis, preceded by the distribution of an Agenda and followed by the distribution of Meeting Notes.

6.5.1 COMMUNICATION MATRIX 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 As Needed Members To Stakeholders As Requested As Requested As Needed

6.5.2 STATUS MEETINGS Status will be communicated at every meeting. Project Status will be the first agenda item. If needed, special meetings will be called to discuss and advance status. Project team members will meet individually with the PM as needed and as a team at least monthly to discuss project status. The result of these meetings will form the basis of the project manager’s weekly and monthly reports.

6.5.3 PROJECT STATUS REPORTS Project Status Reports will be distributed at the Steering Committee Meeting. Each team and the Project Director will review the report before it is published. As the project moves into implementation and the vendor is engaged, status reports will be required from the vendor as well as from DOH technical resources. The Business Process team will provide status reports on the progress of their assignment. All status reports will be rolled up into the Steering committee status report, the weekly and monthly status reports for DOH ITSD and DoIT.

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS) The Project Manager will meet with the Project Sponsor and the Project Director to define the project metrics that will be used to control the project. At a minimum, metrics will be established for time (schedule), cost (budget) and scope (quality).

6.6.1 BASELINES Project Area Category Measure Schedule and progress Milestone performance Milestone dates – are milestones hitting the delivery date? Work package progress Status reports, test results, issue log, risk log, weekly tech meetings Resources/Cost Financial performance Cost and maintaining budget Personnel Level of effort, experience of Staff, training effort Quality Business Process Redesigned business processes for emergency preparedness and response functions supported by HEM systems.

6.6.2 METRICS LIBRARY The defined metrics and review results will be addressed in project status reports and saved to the Project Library.

6.7 QUALITY OBJECTIVES AND CONTROL Quality 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. 6.7.1 QUALITY STANDARDS The quality standards listed below will be used to assess whether the quality objectives were achieved. For each standard, the tracking tool or measure is also listed.

No. Quality Standard Tracking Tool or Measure

1 Project Management Plan approved and followed • Steering Committee review • Project status reports 2 Project Certification by phases • Approval from DoIT Project Certification Committee and release of funds 3 Risks are documented, managed, and tracked • Risk Management Log • IV&V 4 Project issues are documented, tracked, and worked • Issue Log • IV&V 5 Project is within budget • Project status • Budget management 6 Independent Verification and Validation • Periodic reviews and reports • Response to identified issues 7 Project scope management • Project Management Plan • Change Control Process • Steering Committee Meeting Decisions

6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTS Quality Review Type Standard Tools Reviewer Reports Requirements Requirements Requirements in Project Team RFP are documented, RFP Requirements Project Director understood by Section all project team members; approved by Project Director Plans Plans are created Meetings, MS Project Team Monthly or as with input from Project, Visio, and Project Director presented all project team other software members, approved by project team and the Steering Committee Milestones Milestones are MS Project Project Director Monthly or as met by date; Steering presented reported to Committee Steering Committee Meeting Minutes, Documents are MS Word versions Project Team Monthly or as Issues Log, Risk Log up-to-date and of documents Project Director presented accurate Configuration Configuration is Various software Project Team Vendor Review & understood by packages Project Director Gap Analysis all project team member; approved by Project Director Data Conversion Data conversion Various software Project Team Data Conversion is understood by packages Project Director Plan all project team members; approved by Project Director Testing Test results Various software Project Team Test Plan and verified by packages acceptance testing Project Team report testing resources Training Training is Various software Project Director Training Plan understood by packages all project team members; approved by Project Director

6.7.3 AGENCY/CUSTOMER SATISFACTION The project manager will 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.

Areas of feedback When How Often Agency awareness Feedback from Facility Monthly Administrators, visits to facilities speaking with employees Quality of communications Feedback during the various At each meeting for technical meetings team, business process team Manages project tasks Feedback from Steering Monthly for steering committee, project committee, weekly for director/sponsor director/sponsor Productive Meetings Feedback from each meeting Monthly or at each meeting

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS Details of the product deliverables and their associated acceptance criteria cannot be identified until the RFP process is completed, the vendor selected, and a contract with scope-of-work is executed that contains the detailed deliverables with performance dates and costs. The table below lists the general categories within which the detailed deliverables will fall.

Deliverable Final Approval Process Customer Acceptance Criteria System configuration Project Team Review and Detailed requirements and Recommendation; Project detailed understanding of Director sign-off business need – both system and process. Gap analysis issues resolved. Installation Project Team Review and Complete system Recommendation; Project environments ready for data Director sign-off load and testing. Conversion Project Team Review and Capture of existing data assets Recommendation; Project in the new systems. Director sign-of. Testing Project Team Review and Test plan successfully Recommendation; Project executed – testing complete Director sign-off with final acceptance. Training Project Team Review and Training plan executed – Recommendation; Project training completed on systems Director sign-off – both technical and process.

Deliverable Final Approval Process Customer Acceptance Criteria Deployment Project Team Review and Deployment of system to all Recommendation; Project trained users, both Agency and Director sign-off external users and providers. Transition to Project Manager Review and Completed Systems Deployed Operations/Productions Recommendation; Project and moved operational status; Director sign-off; DoIT sign- Application Support Plan off. completed; project closed out.

6.8 CONFIGURATION MANAGEMENT Configuration 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 VERSION CONTROL Project documents will be stored on DOH’s Sharepoint system in the HEM Systems project fibrary. Version control has been enabled. If a document needs to be changed or updated, the document must be checked out. After changes or updates are made, the document is checked back in saving all the changes, time stamped and author’s name. Larger documents such as the Project Management Plan will also be controlled by the revision history log. Entries will be made into the revision history log when changes are made.

6.8.2 PROJECT REPOSITORY (PROJECT LIBRARY) The HEM Systems Project has folders and sub-folders on the NMDOH Sharepoint server for all project documentation. Project folders are organized by content and nomenclature according to standards established by the Implementation Services Bureau of NMDOH/ITSD.

6.9 PROCUREMENT MANAGEMENT PLAN The HEM Systems Project will utilize the Request-For-Proposal (RFP) process for identifying and selecting the solution. The procurement will follow the State Purchasing Department’s process and protocol.

7. 0 PROJECT CLOSE 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/operations 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 ADMINISTRATIVE CLOSE Administrative 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 specific project close activities for a given project are contingent on the project’s complexity and size. The identification of closeout activities for the HEM Systems Project will be the final deployment and the transition to production/operations. 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 CONTRACT CLOSE Contract close is similar to administrative close in that it involves product and process verification for contract close.

PAGE | 31