· Web viewMS Word, Excel, Visio, and Adobe PDF Quality Review – Reviewed by project team members, director, and sponsor for completeness 4.2.3 Deliverable Approval Authority Designations

NNEWEW M MEXICOEXICO S STATETATE I IMMUNIZATIONMMUNIZATION IINFORMATIONNFORMATION S SYSTEMYSTEM (NMSIIS) (NMSIIS)

INTEROPERABILITYINTEROPERABILITY PROJECTPROJECT

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

EXECUTIVE SPONSOR – DR. MAGGI GALLAHER, ACTING PUBLIC HEALTH DIVISION DIRECTOR

BUSINESS OWNER – KEVIN BERSELL, IMMUNIZATION PROGRAM MANAGER

PROJECT MANAGER – TIM ELSBROCK, PROJECT MANAGER

ORIGINAL PLAN DATE: JULY 13TH, 2011REVISION DATE: OCTOBER 13TH, 2011

REVISION: 1.1

PROJECT MANAGEMENT PLAN FOR [PROJECT NAME]

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

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

1.1 Executive Summary -rationale for the project...................................................................................................11.2 funding and sources..........................................................................................................................................11.3 constraints.........................................................................................................................................................11.4 dependencies....................................................................................................................................................21.5 ASSUMPTIONS...................................................................................................................................................21.6 Initial Project Risks Identified..........................................................................................................................3

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE.............................................................................4

2.1 Stakeholders......................................................................................................................................................52.2 Project Governance Structure...........................................................................................................................5

2.2.1 Describe the organizational structure – Org Chart.....................................................................................52.2.2 Describe the role and members of the project steering committee...........................................................52.2.3 Organizational Boundaries, interfaces and responsibilities.......................................................................8

2.3 Executive Reporting.............................................................................................Error! Bookmark not defined.

3.0 SCOPE........................................................................................................................................................... 8

3.1 Project Objectives.............................................................................................................................................83.1.1 Business Objectives....................................................................................................................................93.1.2 Technical Objectives..................................................................................................................................9

3.2 Project exclusions..............................................................................................................................................93.3 Critical Success Factors......................................................................................................................................9

4.0 PROJECT DELIVERABLES AND METHODOLOGY.............................................................................................10

4.1 Project Management Life Cycle.......................................................................................................................104.1.1 Project Management Deliverables...........................................................................................................114.1.3 Deliverable Acceptance Procedure...........................................................................................................12

4.2 PRODUCT LIFE CYCLE.......................................................................................................................................124.2.1 Technical Strategy...................................................................................................................................124.2.2 Product and Product Development Deliverables......................................................................................134.2.3 Deliverable Approval Authority Designations..........................................................................................134.2.4 Deliverable Acceptance Procedure...........................................................................................................14

5.0 PROJECT WORK........................................................................................................................................... 14

5.1 Work Breakdown Structure (WBS)..................................................................................................................145.2 Schedule allocation -Project Timeline.............................................................................................................155.3 Project Budget.................................................................................................................................................165.4 Project Team...................................................................................................................................................17

5.4.1 Project Team Organizational Structure....................................................................................................175.4.2 Project Team Roles and Responsibilities..................................................................................................18

6.0 PROJECT MANAGEMENT AND CONTROLS....................................................................................................19

6.1 Risk and issue Management............................................................................................................................196.1.1 Risk Management Strategy......................................................................................................................196.1.2 Project Risk Identification........................................................................................................................196.1.3 Project Risk Mitigation Approach............................................................................................................196.1.4 Risk Reporting and Escalation Strategy...................................................................................................196.1.5 Project Risk Tracking Approach................................................................................................................206.1.6 ISSUE MANAGEMENT..............................................................................................................................20

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


6.2 INDEPENDENT Verification And Validation - Iv&V...........................................................................................206.3 Scope Management Plan.................................................................................................................................21

6.3.1 Change Control........................................................................................................................................216.4 Project Budget Management..........................................................................................................................21

6.4.1 Budget Tracking.......................................................................................................................................226.5 Communication Plan...................................................................................................................................226.5.1 Communication Matrix............................................................................................................................226.5.2 Status Meetings.......................................................................................................................................236.5.3 Project Status Reports..............................................................................................................................23

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS).....................................................................................236.6.2 Metrics Library.........................................................................................................................................24

6.7 QUALITY OBJECTIVES AND CONTROL..............................................................................................................246.7.1 quality Standards.....................................................................................................................................246.7.2 Project and Product Review AND ASSESSMENTS.....................................................................................256.7.3 Agency/Customer Satisfaction.................................................................................................................256.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS......................................................................................26

6.8 CONFIGURATION MANAGEMENT...................................................................................................................266.8.1 Version Control........................................................................................................................................276.8.2 Project Repository (Project Library).........................................................................................................27

6.9 PROCUREMENT MANAGEMENT PLAN............................................................................................................27

7. 0 PROJECT CLOSE........................................................................................................................................... 27

7.1 Administrative Close...................................................................................................................................277.2 Contract Close............................................................................................................................................28

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


REVISION HISTORYREVISION HISTORY

RREVISIONEVISION N NUMBERUMBER DDATEATE CCOMMENTOMMENT

1.0 July 27th, 2007 Initial version

1.1 August 11, 2011 Updated budget numbers

1.2 October 13, 2011 Implementation update

REVISION: 1.0 DOIT-PMO-TEM-020 III 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.1 EXECUTIVE SUMMARY -RATIONALE FOR THE PROJECT1.1 EXECUTIVE SUMMARY -RATIONALE FOR THE PROJECTThe purpose of this project is to support developing electronic interfaces between the New Mexico Statewide Immunization Information System (NMSIIS) and health care providers in the state. NMSIIS is a registry that tracks immunization records for doses administered within New Mexico.

These interfaces will allow providers’ Electronic Health Records (EHR) systems to electronically submit immunization data to NMSIIS, and to query NMSIIS for the immunization status of patients. Interfacing these systems will improve the completeness of immunization records for New Mexico residents by;

decreasing the number of children that receive too many or too few immunizations because a provider/family did not have a complete record;

reduce keying errors for manually entering immunizations and; reduce the time required for reporting immunizations to NMSIIS.

This project will also drive compliance to the Health Information Technology for Economic and Clinical Health (HITECH) act by helping immunization providers satisfy meaningful use criteria and is funded by a grant from the CDC. This is a nationwide initiative as other states have received money from this grant program to build interfaces for their immunization registries.

1.2 FUNDING AND SOURCES1.2 FUNDING AND SOURCES

SOURCESOURCE AMOUNTAMOUNT ASSOCIATED ASSOCIATED RESTRICTIONSRESTRICTIONS

APPROVERSAPPROVERS

Department of Health and Human Services Grant Number 1U66IP000422-01

$1,057,800 Changes to CDC approved budget need to be submitted to CDC for approval.

MAGGI GALLAHER

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

PAGE | 1


NNUMBERUMBER DDESCRIPTIONESCRIPTION

#1 This project is limited to immunization data. No other record type will be handled.

#2 This project is limited to organizations that provide immunization within the state of New Mexico. This project does not deal with any record type or data element other than immunization related data.

#3 The project must work within the funding timeline of the CDC grant which is currently set to end 8/21/2012

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

E-1 The project requires that the immunization providers work with NMSIIS and devote the resources needed to build the interfaces within the allotted term of the grant. The terms of the grant apply to DOH only and the only pressure borne by the providers is meeting meaningful use. Moreover, the immunization providers are a mix of large and small, for profit and non profit, entities. The project is dependent on all these entities working to help DOH meet the terms of the grant.

M-2 The terms of the grant stipulate that the interfaces be operating bi-directionally by the end of the grant period. However, the primary vendor of the NMSIIS is HP. They, in turn, are working to align the needs of several states in their release of the HL7 2.5, which is the required HL7 version for bidirectional functionality between NMSIIS and the immunization provider. As such, NMSIIS is dependent on HP to deliver HL7 2.5 functionality in a timeframe that will allow for DOH to meet he the terms of the grant.

PAGE | 2


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


A-1 DOH is assuming that the providers will want to send immunization data to satisfy meaningful use requirements to the degree that they will allocate all necessary resources to achieve said interoperability within the terms of the grant under which DOH much work.

A-2 DOH is assuming that the providers outbound messages will largely meet the NMSIIS message specifications and little if any code translations will need to be done by NMSIIS.

A-3 The DOH Information Technology Services Division assumes that the program will lead the outreach effort to the providers to include scheduling meetings, first and subsequent engagements with the pilot sites.

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.

Risk 1 - Lack of engagement from providers

Description – Immunization providers do not engage sufficiently to meet the terms of the grant.

Probability - Likely Impact - H - HIGHIGH

Mitigation Strategy – There is money in the grant to help the providers defray system development costs. If the providers are slow to engage, then DOH can offer this money in support of their efforts. The providers also have reason to achieve the interoperability as it will help them satisfy meaningful use.Contingency Plan - The grant will allow us to change pilot sites, so the project could change pilot sites in an effort to meet the terms of the grant. This would mean replacing the pilot sites designated in the grant application with another provider site that is more prepared to commit the required resources.

Risk 2 - Technological skill set

PAGE | 3


Description – The effort to interface, both one-directional and then bi-directional, will be a challenge for DOH in general. The skill sets required are being built as we complete this project. It is possible that the project could be delayed, or the terms of the grant not met, if DOH is unable to complete the technological aspect of the project.

Probability - Likely Impact - M - MEDIUMEDIUM

Mitigation Strategy – The project is already working with NMHIC to complete the interface work for Presbyterian Health Services and ABQ Health partners. DOH could further leverage their technical abilities to build additional interfaces.Contingency Plan - Work with NMHIC or otherwise outsource. Could also contract for additional in-house expertise.

Risk 3 – HL7 2.5.1

Description – The bidirectional interfaces required by the end of the grant period are predicated on HP delivering the HL7 2.5.1 functionality in NMSIIS. HP is developing this functionality for several states in addition to New Mexico, and several of those states are also in receipt of this grant. This is now slated to be delivered in October of 2010. If delivery of this functionality slips, the project schedule will slip as well.

Probability - Moderate Impact - M - MEDIUMEDIUM

Mitigation Strategy – The project can work on all other aspect of the interfaces to give HP time to deliver the HL7 2.5.1 functionality. Contingency Plan - Should this functionality be delayed, it is likely that the CDC will ease the terms of the grant, either in schedule or required functionality or both, to accommodate the slip by HP. As stated previously, New Mexico is not the only grantee working with this risk within this timeline.

PAGE | 4


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 STAKE IN PROJECTSTAKE IN PROJECT ORGANIZATIONORGANIZATION TITLETITLE

Maggi Gallaher, MD, MPH Executive Sponsor Public Health Division (PHD)

ACTING DIRECTOR

Kevin Bersell Business Owner PHD/Immunization Program

ACTING NMSIIS MANAGER

Immunization Program Staff Users/Supporters of NMSIIS

PHD/Immunization Program

N/A

Dave Perry and Matt Berlin

New Mexico Health Information Exchange (NMHIC)

NMHIC performs a partner role in that they will interface the larger providers such as Presbyterian.

LCF Research NMHIC CIO

All immunization providers across New Mexico

The NMSIIS interoperability project will impact all the providers as they attempt to comply with meaningful use and also as they try to share their data with NMSIIS.

Various N/A

2.2 PROJECT GOVERNANCE STRUCTURE2.2 PROJECT GOVERNANCE STRUCTURE

PAGE | 5


2.2.1 D2.2.1 DESCRIBEESCRIBE THETHE ORGANIZATIONALORGANIZATIONAL STRUCTURESTRUCTURE – O – ORGRG C CHARTHART

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

NNAMEAME GGROUPROUP RROLEOLE RRESPONSIBILITYESPONSIBILITY

Maggi Gallaher, MD,

MPH

NMDOH Acting PHD Division Director

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

PAGE | 6

Maggi Gallaher, MD, MPH

Executive Sponsor

Steering Committee

Business Process Team

Tim Elsbrock

IT Project Manager

NMHIC Project Manager

Project Team

IT Generalist

Kevin Bersell

Business Owner

IT Tester


Executive Project Sponsor

Steering Committee

Member

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

Kevin Bersell, NMSIIS Program Manager

NMDOH

Business Owner

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

Michael Snouffer,

Application Support

Bureau Chief

NMDOH 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

PAGE | 7


Champion the project

Jane Cotner NMDOH

Immunization Program Director

Steering Committee

Member

Provide PHD Bureau 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

TBD, External stakeholder TBD TBD

Provide Clinical Services perspective 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

Tim Elsbrock 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

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

As mentioned in risk and assumption sections above, this project relies heavily on the input from external organizations to help DOH meet the terms of the grant. It is the responsibility of the

PAGE | 8


NMSIIS program to engage the providers, on a regular and ongoing basis, so that they are brought along the interface development process that will result in an operable interface being developed. ITSD can only consult on the technical aspect of the effort, commonly agreed to activities within such a consultative engagement are as follows; requirements gathering, building of GAPS documentation, system configuration, system training, system testing, technical consultation with the providers and end –user support.

3.0 SCOPE3.0 SCOPE

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

NUMBERNUMBER DESCRIPTIONDESCRIPTION

BUSINESS OBJECTIVE #1

40% of all immunization administered statewide will be entered into the registry via Health Level 7 (HL7) interface at the end of the project.

BUSINESS OBJECTIVE #2

Reduce errors due by reducing manual and redundant date entry, and improve efficiency by automating immunization data entry and retrieval, with real time bidirectional interfaces between immunization provider EHR systems and the NMSIIS system.

3.1.2 T3.1.2 TECHNICALECHNICAL O OBJECTIVESBJECTIVES


TECHNICAL OBJECTIVE 1

Utilizing the HL7 messaging protocol, the NMSIIS interoperability project will interface with immunization providers to attain a one directional feed of doses administered into the NMSIIS registry, and by 2012 be able to send bidirectional message, so immunization providers can view, from within their EHR system, the immunization history of a client prior to administering additional immunizations. This will also assure that clients receive the recommended dose and schedule for each immunization.

TECHNICAL OBJECTIVE 2

Build fully automated bidirectional interfaces between NMSIIS and the pilot providers EHR systems

3.2 PROJECT EXCLUSIONS3.2 PROJECT EXCLUSIONS

PAGE | 9


The project is excluding immunization providers that are not designated as a pilot site. Other providers, may be included, but only if time and resources are available and only after all pilot sites are completed. These other providers are not part of the project scope.

The project is limited to immunization specific data.

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 Immunization providers will spend less time doing double data entry into NMSIIS

Quality Metrics 2 HL7 interfaces are working properly and electronic records reliably flow into NMSIIS

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 establishes 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

PAGE | 10


Execution and Control This phase implements the product the project was commissioned to deliver including all testing and go-live support.

Control of a project overlaps with all phases of a project and the key elements to control are: scope, schedule, and budget.

Scope under control, updated project schedule, updated budget, maintained risk management log, maintained issue log, status report, product of the project, acceptance

Close out This phase wraps up the project and shares any lessons learned and best practices to be applied to future projects.

Post implementation review and report, lessons learned, 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 Initial Project Plan4.1.1.1 Project CharterDescription – The initial project deliverable plan will contain the Project Charter. This deliverable may be revised during planning phase.

Deliverable Acceptance Criteria – Sign-off by Project Sponsor or Project DirectorStandards for Content and Format – Use of DoIT Project Charter templateQuality Review -.Peer review for grammar, spelling, risk and assumptionsKey project team members review for consensus

PAGE | 11


4.1.1.2 Project Management Plan

Description – 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 – Approval by Project Team and Steering CommitteeSign-off by Project Sponsor or Project Director

1.2 4Deliverable Approval Authority DesignationsComplete 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

PM-01 Project Charter Maggi Gallaher, MD, MPH

PM-02 Project Management Plan (PMP) Maggi Gallaher, MD, MPH

4.1.3 D4.1.3 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

The Project Sponsor will review and accept the project documents. She will sign off on the charter and project management plan.

4.2 PRODUCT LIFE CYCLE4.2 PRODUCT LIFE CYCLE

Phase Summary of Phase Key Deliverables

PAGE | 12


Message testing Testing of messaged from pilot sites.

Iterative process of insuring the messaged from provider met the incoming message specification. Final test will be certifying that the providers have cleared UAT. Repeat for all pilot sites.

Deployment Deployment of message flow into production

Shift from message testing to full production. Repeat for all pilot sites.

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

Update the Application Support Plan (ASP).

4.2.1 T4.2.1 TECHNICALECHNICAL S STRATEGYTRATEGY

The key technical strategy of this project is to have the immunization providers meet the NMSIIS message specifications as much as possible. ITSD does have some limited ability to map/alter codes from the provider EHR systems into the NMSIIS system.

The NMSIIS is a hosted system, so there is little hands-on technical need from a server/system maintenance perspective.

The bidirectional messaging aspect will be handled via a web services solution. The architecture of this solution is being defined as a best practice by the CDC across several states that have also received this grant. ITSD and NMSIIS plan to adopt this best practice architecture provided by the CDC.

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.

4.2.2.2 Testing

Description – Testing Plan 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

PAGE | 13


4.2.2.4 Training

Description – Training Plan Deliverable Acceptance Criteria – Adopted from existing NMSIIS training plan. 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.2.5 Deployment

Description – Message validation for each provider and data is being exchanged with NMSIIS

Deliverable Acceptance Criteria – Once messages from respective providers have cleared UAT and gained sign-off by Project TeamStandards 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.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

1 Testing Plan Project Director

2 UAT Completion Project Director

3 Training Plan Project Director

4 Message validation for each provider and data is being exchanged with NMSIIS

Project Director

4.2.4 D4.2.4 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

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 | 14


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.

The project will use an iterative methodology to implement the scope of this project. Each iteration will consist of the Task/Activity described in the below table. The iteration will be a single or grouping of providers. It is understood that all of the providers may not progress towards integration at the same speed.

IIDENTIFIERDENTIFIERWWORKORK P PACKAGEACKAGE DDESCRIPTIONESCRIPTION

DDEFINITIONEFINITION/ O/ OBJECTIVEBJECTIVEMMILESTONEILESTONE/ / DDELIVERABLEELIVERABLE

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 starts the message testing from pilot sites, builds the interfaces to the system.

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 TIMELINE

PAGE | 15


The 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

The project will adhere to the PCC Certification Gates described below under Task/Activity Name:

IIDENTIFIERDENTIFIER TTASKASK/ / AACTIVITYCTIVITY NNAMEAME

RRESOURCEESOURCE NNAMEAME

MMILESTONILESTONEE (Y/N) (Y/N)

EEFFORTFFORT//

DDURATIURATIONON

SSTARTTART FFINISHINISH DDEPENDENTEPENDENT TTASKASK

1.0 Initiation Phase

Project Director Project Team Steering Committee

Y 6 month 1/15/11 7/2011 Confirm Funding

2.0 Planning Phase Project

Director Project Team Steering Committee

Y3 month 7/2011 10/2011

Execute Vendor Contract Amendment

3.0 Implementation Phase

Project Director Project Team Steering Committee

Vendor Resources

Y10

months10/2011 8/2012

Completion of Planning Phase

PAGE | 16


IIDENTIFIERDENTIFIER TTASKASK/ / AACTIVITYCTIVITY NNAMEAME

RRESOURCEESOURCE NNAMEAME

MMILESTONILESTONEE (Y/N) (Y/N)

EEFFORTFFORT//

DDURATIURATIONON

SSTARTTART FFINISHINISH DDEPENDENTEPENDENT TTASKASK

4.0 Closeout Phase Project

Director Project Team Steering Committee

Vendor Resources

Y1 month 8/2012 9/2012

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

5.2. Budget By Major Deliverable or Type of expense –

BBUDGETUDGET

Comments: No Hardware costs are expected to be incurred since this project is an enhancement to the existing NMSIIS system, which is a hosted application. Expected costs for IT services are allocated to interface development and testing.

DescriptionFY11FY11 FY12 FY13 FY14 FY15

Staff - Internal

Project Manager, $27,500 $100,000 $17,800

Consulting Services

IT Services, IV&V, Contract System Tester, Contract IT

$0 $762,000 $111,500

PAGE | 17


Generalist,

Hardware None

Software Data Broker $39,000

TTOTALOTAL $27,500 $901,000 $129,300

5.4 PROJECT TEAM5.4 PROJECT TEAM5.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.

PAGE | 18

Kevin Bersell

Business OwnerBusiness Process

Team

Tim Elsbrock

IT Project Manager

NMHIC Project Manager

Project Team

IT Generalist IT Tester


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

Kevin Bersell Manages overall NMSIIS program including the HP contract and all data quality efforts, all outreach efforts, and all registry related task (such as WIR consortium representation)

Bobby Sanchez Coordinate all outreach act ivies. Single point of contact for providers as they engage with NMSIIS project and the this project.

IT Generalist Application developer. Lead technical resource that has the key responsibility of leading the technical discussions with the providers prior during and after implementation/interface efforts,

Tim Elsbrock, Project Manager

Contract and Procurements, DoIT Certification process, Overall project management to include scope and schedule adherence.

IT Tester Provide all application testing, script development and track all errors and insure all errors are rectified.

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.

PAGE | 19


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.

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 NMSIIS Interoperability 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 NMSIIS Interoperability 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 NMSIIS Interoperability 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 Process 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 Process 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.

PAGE | 20


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

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.

Scope changes are unlikely on this project due the tight constraints mentioned above. However, 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.

PAGE | 21


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 NMSIIS Interoperability 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 NMSIIS system and will resume their duties upon the successful implementation of the upgraded NMSIIS Interoperability Project

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.

6.5 C6.5 COMMUNICATIONOMMUNICATION P PLANLAN

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

PAGE | 22


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. These risk and issues will be monitored regularly and notes of changes to each will be kept as these items can be fluid.

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

PAGE | 23


6.6.1 B6.6.1 BASELINESASELINES

The Project Manager will meet with the Project Sponsor and 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).

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 | 24


NNOO.. QQUALITYUALITY S STANDARDTANDARD TTRACKINGRACKING T TOOLOOL OROR M MEASUREEASURE

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 | 25


6.7.2 P6.7.2 PROJECTROJECT ANDAND P PRODUCTRODUCT R REVIEWEVIEW AND ASSESSMENTS AND ASSESSMENTS

Review Type Quality Standard Tools Reviewer Reports

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

Monthly or as presented

Milestones Milestones are met by date; reported to Steering Committee

MS Project Project DirectorSteering Committee


Meeting Minutes, Issues Log, Risk Log

Documents are up-to-date and accurate

MS Word versions of documents



Configuration/ Requirements

Configuration and Requirements are understood by all project team members; approved by Project Director

Various software packages


Workflow Analysis

Testing Test results verified by Project Team testing resources

Various software packages

Project Team Test Plan and acceptance testing report

Training Training is understood by all project team members; approved by Project Director

Various software packages Project Director

Training Plan

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.

PAGE | 26


Areas of feedback When How Often

NMSIIS data improvement and provider adoption

Feedback from the NMSIIS and provider end-users

Quarterly

Quality of communications; Productive meetings

Feedback during the various meetings

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

Manages project tasks; Achieving project tasks

Feedback from Project Sponsor, Steering Committee, Project Director

Monthly

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

Message Testing, reporting of errors to providers Review by Project Director,

Project Manager, and IT Generalist

Messages meet NMSIIS inbound message specification

UAT finalizedProject Team Review; Project Director sign

Message are error free and ready to go into production

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.

PAGE | 27


6.8.1 V6.8.1 VERSIONERSION C CONTROLONTROL

Documents will be stored on the NMSIIS interoperability project library. 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.

6.8.2 P6.8.2 PROJECTROJECT R REPOSITORYEPOSITORY (P (PROJECTROJECT L LIBRARYIBRARY))

The NMSIIS Interoperability Project has a SharePoint site 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 NMSIIS interoperability Project will be accomplished using several contracts germane to the project. 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.

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 project’s project management consultant to tailored Project Close procedures to compliment the project’s objectives

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

PAGE | 28


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