executive sponsor – mark williams - new mexico … - acams/doh... · web viewproject management...

FAMILY HEALTH BUREAU – ACAMS

CASE MANAGEMENT APPLICATION SYSTEM

PROJECT MANAGEMENT PLAN (PMP)

EXECUTIVE SPONSOR – MARK WILLIAMS

BUSINESS OWNER - SUSAN CHACON

PROJECT MANAGER – GORDON MUTHIGI

ORIGINAL PLAN DATE: MAY 29, 2015REVISION DATE: 8/04/15

REVISION: 1.6

PROJECT MANAGEMENT PLAN FOR FHB-ACAMS

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..............................................................................................................11.2 FUNDING AND SOURCES.........................................................................................................................................................21.3 CONSTRAINTS......................................................................................................................................................................21.4 DEPENDENCIES.....................................................................................................................................................................21.5 ASSUMPTIONS.................................................................................................................................................................31.6 INITIAL PROJECT RISKS IDENTIFIED.........................................................................................................................................4

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE..........................................................................................6

2.1 STAKEHOLDERS....................................................................................................................................................................62.2 PROJECT GOVERNANCE STRUCTURE.........................................................................................................................................8

2.2.1 Describe the organizational structure – Org Chart...................................................................................................82.2.2 Describe the role and members of the project steering committee..........................................................................92.2.3 Organizational Boundaries, interfaces and responsibilities......................................................................................9

2.3 EXECUTIVE REPORTING..........................................................................................................................................................9

3.0 SCOPE....................................................................................................................................................................... 10

3.1 PROJECT OBJECTIVES..........................................................................................................................................................103.1.1 Business Objectives................................................................................................................................................103.1.2 Technical Objectives...............................................................................................................................................10

3.2 PROJECT EXCLUSIONS..........................................................................................................................................................103.2.1 Project Deliverables...............................................................................................................................................10

3.3 CRITICAL SUCCESS FACTORS.................................................................................................................................................10

4.0 PROJECT DELIVERABLES AND METHODOLOGY........................................................................................................... 12

4.1 PROJECT MANAGEMENT LIFE CYCLE......................................................................................................................................124.1.1 Project Management Deliverables.........................................................................................................................134.1.2 Deliverable Approval Authority Designations........................................................................................................174.1.3 Deliverable Acceptance Procedure.........................................................................................................................17

4.2 PRODUCT LIFE CYCLE.....................................................................................................................................................174.2.1 Technical Strategy..................................................................................................................................................184.2.2 Product and Product Development Deliverables....................................................................................................194.2.3 Deliverable Approval Authority Designations........................................................................................................214.2.4 Deliverable Acceptance Procedure.........................................................................................................................21

5.0 PROJECT WORK........................................................................................................................................................ 22

5.1 WORK BREAKDOWN STRUCTURE (WBS)................................................................................................................................225.2 SCHEDULE ALLOCATION -PROJECT TIMELINE............................................................................................................................225.3 PROJECT BUDGET...............................................................................................................................................................235.4 PROJECT TEAM..................................................................................................................................................................24

5.4.1 Project Team Organizational Structure..................................................................................................................245.4.2 Project Team Roles and Responsibilities................................................................................................................24

5.5 STAFF PLANNING AND RESOURCE ACQUISITION..............................................................................................................255.5.1 Project Staff...........................................................................................................................................................255.5.2 Non-Personnel resources.......................................................................................................................................26

REVISION: 1.6 i OF vi


5.6 PROJECT LOGISTICS.......................................................................................................................................................265.6.1 Project Team Training............................................................................................................................................26

6.0 PROJECT MANAGEMENT AND CONTROLS................................................................................................................. 26

6.1 RISK AND ISSUE MANAGEMENT.............................................................................................................................................266.1.1 Risk Management Strategy....................................................................................................................................266.1.2 Project Risk Identification......................................................................................................................................266.1.3 Project Risk Mitigation Approach...........................................................................................................................276.1.4 Risk Reporting and Escalation Strategy..................................................................................................................276.1.5 Project Risk Tracking Approach..............................................................................................................................286.1.6 ISSUE MANAGEMENT............................................................................................................................................28

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V.........................................................................................................286.3 SCOPE MANAGEMENT PLAN................................................................................................................................................28

6.3.1 Change Control......................................................................................................................................................296.4 PROJECT BUDGET MANAGEMENT..........................................................................................................................................30

6.4.1 Budget Tracking.....................................................................................................................................................306.5 COMMUNICATION PLAN......................................................................................................................................................30

6.5.1 Communication Matrix..........................................................................................................................................316.5.2 Status Meetings.....................................................................................................................................................316.5.2.1 Team Leads Meeting...........................................................................................................................................316.5.2.2 Status Meeting with FHB-ACAMS Team (weekly)...............................................................................................316.5.2.3 Steering Committee Meeting (Monthly)..............................................................................................................316.5.2.4 Executive Update Meeting (Monthly).................................................................................................................326.5.2.5 Project Kickoff Meeting.......................................................................................................................................326.5.2.6 Requirements & Design Sessions.........................................................................................................................326.5.2.7 Team Training Meeting.......................................................................................................................................326.5.2.8 DOH & Acro PM Meeting....................................................................................................................................336.5.2.9 External Vendor Team Meeting..........................................................................................................................336.5.2.10 Adhoc Meetings................................................................................................................................................336.5.3 Project Status Reports............................................................................................................................................34

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)...................................................................................................346.6.1 Baselines................................................................................................................................................................346.6.2 Metrics Library.......................................................................................................................................................34

6.7 QUALITY OBJECTIVES AND CONTROL............................................................................................................................346.7.1 QUALITY Standards................................................................................................................................................356.7.2 Project and Product Review and Assessments.......................................................................................................366.7.3 Agency/Customer Satisfaction...............................................................................................................................36

SSTANDARDS.......................................................................................................................................................................366.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS....................................................................................................37

6.8 CONFIGURATION MANAGEMENT..................................................................................................................................386.8.1 Version Control......................................................................................................................................................386.8.2 Project Repository (Project Library)........................................................................................................................38

6.9 PROCUREMENT MANAGEMENT PLAN...........................................................................................................................38

7. 0 PROJECT CLOSE........................................................................................................................................................ 39

7.1 Administrative Close.................................................................................................................................................397.2 Contract Close...........................................................................................................................................................39

ATTACHMENTS............................................................................................................................................................... 39

ATTACHMENT A: ACRONYMS, ABBREVIATIONS AND DEFINITIONS.......................................................................................................40DEFINITIONS........................................................................................................................................................................... 40

REVISION: 1.6 ii OF vi


REVISION HISTORY

REVISION NUMBER DATE COMMENT

1.0 May 29, 2015 Initial plan created

1.1 June 18, 2015 Updates to quality metrics

1.2 July 10, 2015 Added additional details

1.3 July 20, 2015 Updated including items approved in change requests 001 and 002

1.4 July 29, 2015 Incorporated Steering Committee approvals

1.5 July 30, 2015 Included change request process table

1.6 August 4, 2015 Updates to stakeholder table & timeline

REVISION: 1.6 iii OF vi


PREPARING THE PROJECT MANAGEMENT PLAN

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

ABOUT THIS DOCUMENT

PROJECT OVERSIGHT PROCESS MEMORANDUM – DOIT, JULY 2007

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

The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and documents approved scope, cost and schedule baselines.

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

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

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

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

REVISION: 1.6 iv OF vi


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

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT With more than 3,200 staff members and a budget of $550 million dollars, the Department

Of Health delivers essential public health and other services to frontier, rural and urban communities and 22 sovereign tribal nations. Our facilities serve as a safety net for people who require long term care, rehabilitation and behavioral health treatment. New Mexico Department of Health (NMDOH) programs work with providers to support people with disabilities and their families. It is also our role to ensure an effective and timely response to public health emergencies. These are among the many ways we serve the people of New Mexico.

The Public Health Division provides a coordinated system of community-based public health services focusing on disease prevention and health promotion in order to improve health status, reduce disparities, and ensure timely access to quality, culturally competent health care. It consists of seven bureaus and five regions: Director’s Office/Program Support, Pharmacy, Family Health, Infectious Disease, Chronic Disease Prevention and Control, and Health Systems Bureaus, and the Northeast, Northwest, Metro, Southeast and Southwest Regions.

The Children’s Medical Services (CMS ) program provides a combination of direct service, surveillance and prevention programs to the children and youth of New Mexico with special health care needs. The programs provides care coordination and payment for services for the prevention, diagnosis and treatment of chronic medical conditions in children under the age of 21 who meet certain medical and income guidelines. The program, administered by 60 social workers and five family liaisons, works in a statewide network of public health offices.

Newborn Genetic/Metabolic and Hearing Screening. The Newborn Genetic/Metabolic and Hearing Screening program works to assure that all children born in the state receive genetic and hearing screening. The Birth Defects Prevention and Surveillance System is managed by the Public Health Division Director’s Office and the Environmental Health Epidemiology Bureau of the Epidemiology and Response Division. There are approximately 29,000 births each year in New Mexico. Birth defects diagnosed prenatally through four years of age are reportable to the state. The CMS Program works in collaboration with these programs and is responsible for assuring follow up for infants who fail the hearing or genetic screening tests or are diagnosed with certain birth defects to assure that they are referred for appropriate medical and developmental services.

The Families FIRST (Families and Infants Receive Services and Training) program is a perinatal case management program that serves pregnant women and children up to age 3 that are Medicaid-eligible. This program has three major goals: 1) improve access to prenatal care, 2) improve pregnancy outcomes for Medicaid-eligible women, and 3) improve the health status

PAGE 1 OF 51


of their infants and children up to age three. The purpose of the Program is to assist Medicaid-eligible women and children to gain access to needed medical, social, educational and other services. Case management services may include coordination with providers of non-medical services such as nutritional programs or educational agencies when these services have been identified as necessary to foster positive pregnancy outcomes and promote healthier infants and children.

Currently, two (2) of the three (3) business areas (Families First and Newborn Genetic/Metabolic and Hearing Screening) have existing Software as a Service applications to track and report case management information. The Children’s Medical Services program is using an antiquated internal application to track case management information on their clients.

1.2 FUNDING AND SOURCESBudget and funding information is with ACRO’s project lead.

SOURCE AMOUNT ASSOCIATED RESTRICTIONS

APPROVERS

GAA

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

NUMBER DESCRIPTION

CON-001 Holidays and planned vacations of project team resources could impact the timeline. Project timelines will be developed to minimize the impact.

CON-002 Development team will be working remotely on Eastern Time Zone. Plan to mitigate this constraint by: Having the Acro project manager local to communicate & coordinate Schedule meetings in the mornings as much as possible Development team come on site for requirements gathering and design

sessions

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

PAGE 2 OF 51


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

DEP-001 Availability of skilled DOH resources to provide detailed requirements, review and approve in a timely manner.

M

DEP-002 Availability of hardware, software, environments (Test, UAT and Training) and facilities needed for development and implementation of the project.

M

DEP-003 Meeting the turnaround time by State Resources for review & approval of deliverables and making decisions.

M

DEP-004 Interoperability with Medicaid eligibility and reimbursement systems.

M,E

DEP-005 Clean data available from interface systems (INPHORM, ChallengerSoft, Oregon System and in-house access databases

M,E

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

NUMBER DESCRIPTION

ASMP-001 The system will be hosted using Microsoft Azure. Acro to set up Test, UAT, Training and PROD environments for the project as per the agreed timeline.

ASMP-002 DOH will provide details on existing systems, DB and interfaces.

ASMP-003 DOH will manage other vendors to provide the information & resources needed for this project as per the agreed timeline.

ASMP-004 Resources from the Public Health Division, DOH ITSD and associated contractors will be consistent, engaged and available for the duration of the project.

ASMP-005 ICD-10 compliant FHB-ACAMS system will be developed. It is assumed that the input data & interfaces from existing applications and vendor applications will be ICD-10 complaint.

PAGE 3 OF 51


NUMBER DESCRIPTION

ASMP-006 Acro will provide training to FHB-ACAMS project team and DOH Trainers as outlined in the plan. Training any other staff or field office personnel is out of scope for FHB-ACAMS project.

ASMP-007 DOH will develop a plan and manage education & communication to various departments, providers and other agencies

1.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: Stakeholders active participation

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

ProbabilityLOW

ImpactHIGH

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

Risk 2: ChallengerSoft resources availability

Description – Project will be at risk if ChallengerSoft resources are not available to provide database and data details, and ICD-10 compliant interfaces for conversion and migration of data to the new FHB-ACAMS Case Management System.

Probability - MEDIUM Impact - HIGH

Mitigation Strategy:1. Schedule regular meetings with the Vendor2. Engage the vendor resources early to get the input needed3. Escalate to vendor’s management teamContingency Plan:Vendors and existing system team to fix the problems to provide clean ICD-10 compliant date. This will have schedule and cost impacts to this project.

Risk 3: INPHORM database structure and details availabilityProbability - HIGH Impact - HIGH

PAGE 4 OF 51


Description - Project will be at risk if database structure and details are not available for conversion and migration of data to the new FHB-ACAMS Case Management System.

Mitigation Strategy: In the absence of any documentation:1. Gather as much as possible with DOH SME2. Explore if documentation can be obtained by reverse engineering

toolsContingency Plan: Extract skeleton data with minimum fields defined and manually cleanup to remove duplicates

Risk 4: HSD resources availability

Description – Project will be at risk if HSD resources are not available to provide information needed for FHB-ACAMS Case Management System in a timely manner.

Probability - LOW Impact - HIGH

Mitigation Strategy:1. Schedule regular meetings with HSD2. Engage the resources early to get the input needed3. Escalate to HSD management teamContingency Plan: None

Risk 5: Hardware environment availability

Description – Project will be at risk if test, QA, Training, Prod and DR environments are not set up as per the project timeline.


Mitigation Strategy:1. Early decision if DoIT is hosting2. Schedule regular meetings with DoIT and get commitment on

timelineContingency Plan:Acro to work with Microsoft Azure to develop design for external cloud hosting and get approval.Develop security plan and plan for testing thoroughly

Risk 6: ICD-10 Compliance data available for conversion

Description – Project assumption is that FHB-ACAMS system will have input data from the existing DBs is in ICD-10 format. Project is at risk if the data is not ICD-10.


Mitigation Strategy:1. DOH to ensure that the current systems are migrated to ICD-10

format before data is transferred to FHB-ACAMS2. Start conversion process early to clean up the dataContingency Plan:DOH will find a work around to pay claims and submit change request to FHB-ACAMS project with requirements

PAGE 5 OF 51


Risk 7: ICD-10 Changes to existing systems while data migrated

Description – Project will be at risk if there are changes made to existing systems while data is migrated to FHB-ACAMS.

Probability - HIGH Impact - HIGH

Mitigation Strategy:1. DOH to ensure that any changes made to other systems are

conveyed to FHB-ACAMS project team2. Evaluate the impact of the change requests and get approval from

FHB-ACAMS Change Control BoardContingency Plan:None

Risk 8: CMS, FF, NBH and NBG teams maintaining their own demographic information

Description – Data integrity will be at risk if a centralized data base is not maintained using NPI (National Provider Identifier)

Probability - HIGH Impact - HIGH

Mitigation Strategy:1. DOH to make a decision to use NPI and develop a plan for user

education and communication2. Develop program management process and designate a person or

group with authority to update3. Evaluate the impact of the changes and approve change request to

develop single data baseContingency Plan:Develop FHB-ACAMS system to maintain separate data bases for each sub-system

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE

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

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

NAME STAKE IN PROJECT ORGANIZATION

TITLE

Terry Reusser Steering Committee Member

DoH CIO

PAGE 6 OF 51


NAME STAKE IN PROJECT ORGANIZATION

TITLE

Paula Morgan Executive IT Stakeholder DoH Deputy CIO

Janis Gonzalez, MD Steering Committee Member

DoH CMS Medical Director

Gene Lujan DoH Project Manager DoH Chief, Project Management Bureau

Kshiteej Bhosale Program Manager, Single Point of Contact

ACRO Project Lead

Gordon Muthigi Project Manager ACRO Project Manager

RV Rao Acro Executive Sponsor ACRO Divisional President

Cathy Rocke Steering Committee Member

DoH Deputy Director of Programs, Public Health Division

Elaine Abhold Business Stakeholder DoH CMS Training and Development Specialist

Mark Williams Executive Sponsor DoH Director, Public Health Division

Maureen Burns Business Stakeholder DoH Families First Statewide Program Manager

Susan Chacon Business Stakeholder DoH CMS Statewide Program Manager

Susan Merrill Business Stakeholder DoH CMS Northeast Region Supervisor

Sandeep Patel IT Stakeholder DoH ITSD

Kim Price Business Stakeholder DoH PMO

Matt Bailey IV&V Project Manager Cognosante Project Manager

PAGE 7 OF 51


2.2 PROJECT GOVERNANCE STRUCTURE2.2.1 DESCRIBE THE ORGANIZATIONAL STRUCTURE – ORG CHART

PAGE 8 OF 51


2.2.2 DESCRIBE THE ROLE AND MEMBERS OF THE PROJECT STEERING COMMITTEE

This section will be updated during Planning Phase.

2.2.3 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES

The primary methods utilized will be the weekly Status Report/Briefing conference call, ad-hoc meetings as needed, electronic mail, and phone conversations. Interaction may occur directly between the technical components of all teams. However, overall task direction can only come from DoH Project Manager. Final decisions will be made at the Steering Committee level.

2.3 EXECUTIVE REPORTING

The project status report will be sent to Executive Sponsors, Business Owner, Steering Committee and other governing bodies in the second week of each month giving the high level status of previous month using the standard status reporting template.

The first report will be distributed in the second week of July and every month until project completion.

PAGE 9 OF 51


3.0 SCOPE

3.1 PROJECT OBJECTIVES3.1.1 BUSINESS OBJECTIVES

NUMBER DESCRIPTION

Bus. Objective 1 Improve health outcomes for the people of New Mexico.

Bus. Objective 2 Improve quality, accessibility, and utilization of health care services.

Bus. Objective 3 Ensure that technology supports timely, data-driven decisions, improve business operations, and improve public information and education.

3.1.2 TECHNICAL OBJECTIVES

Tech. Objective 1 To consolidate all case management functionality of the PHD Family Health bureau into a single modular application.

Tech. Objective 2 To eliminate the reliance of the Children’s medical Service program on antiquated and vulnerable technology.

3.2 PROJECT EXCLUSIONS3.2.1 PROJECT DELIVERABLES

Project deliverables are listed in the table 4.1. Any deliverables not listed in the table 4.1 are excluded from this project.

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

NUMBER DESCRIPTION

QUALITY METRICS 1 Configure an application that software system for Public Health Division, Family Health Bureau that consolidates the case management system.

QUALITY METRICS 2 Increase the efficiency of the case management system for all Family Health Bureau programs.

PAGE 10 OF 51


NUMBER DESCRIPTION

QUALITY METRICS 3 Decreased the duplication of paperwork for each program.

QUALITY METRICS 4 Maintain a single unique patient identifier.

QUALITY METRICS 5 Independent Verification and Validation will persist to maintain the health and welfare of the entire project.

QUALITY METRICS 6 Requirements and risks will be captured, documented and tracked throughout the project are met.

PAGE 11 OF 51


4.0 PROJECT DELIVERABLES AND METHODOLOGYThe project team will use the State of New Mexico Project Management Methodology and the deliverables will include the ones defined in the project proposal.

The following is a description of a Project Management Life Cycle based on the PMI (Project Management Institute’s PMBOK©.

4.1 PROJECT MANAGEMENT LIFE CYCLE

Phase Summary of Phase Key Deliverables

Initiating Initial steps and approvals

Executive Summary and Project Overview

On-site project kickoff

Initial Project Management Plan including

List of Stakeholders

Steering Committee

Project Team

Org Chart

Roles & Responsibilities

High level project timeline

Communication plan

Software Development Lifecycle (SDLC) description

Authorization to proceed with planning

Planning Planning documents in Updated Project Management Plan

PAGE 12 OF 51


the Requirements and Design phases

Critical success factors

Work Break down Structure (WBS)

Project Schedule

Controlling Managing the plans to develop the system to meet the project timelines

Performance/Status Reports

Requirements Management

Change Request Management

Risk Management

Issues Management

Quality Assurance Plan

Configuration Management Plan

Execution Documents during Development & testing phase

Test Plan including

Test Cases

Defect resolution metrics

Training Plan including

Train the Trainer

User Manuals

Conversion and Migration Plan

Release Plan

Data Migration Plan

Disaster Recovery Plan

Project deliverables completion

Closing Final sign-off and close out

Deliverables Acceptance

Lessons Learned

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 CharterDescription - The Project Charter for Certification sets the overall scope for the project, the governance structure, and

Deliverable Acceptance Criteria :Project certification

PAGE 13 OF 51


when signed is considered permission to proceed with the project. The Project Charter for Certification is used to provide the Project Certification Committee with adequate knowledge of the project and its planning to certify the initiation phase of the project

Standards for Content and Format -

DoIT formatQuality Review -.Review and approval by DOH Executive Sponsor, Business Owner, project manager and DoIT/PCC

4.1.1.2 Project Management PlanDescription - Project management plan is a formal document approved by the executive sponsor and the Department and developed in the plan phase used to manage project execution, control, and project close. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and documents approved scope, cost and schedule baselines. Project plan includes at least other plans for issue escalation, change control, communications, deliverable review and acceptance, staff acquisition, and risk management plan.

Deliverable Acceptance Criteria –

High level details included for each section

Standards for Content and Format:

As defined in DoIT template

Quality Review:

Review and approval by DOH project manager

4.1.1.3 Work Breakdown Structure (WBS)Description – List of individual work items that are to be completed in order to complete the project

Deliverable Acceptance Criteria -Detailed task for each of the sub-systems and functionsStandards for Content and Format -

PMBOK standardsQuality Review -Review by DOH project manager

4.1.1.4 Project ScheduleDescription - Tool used to indicate the planned dates, dependencies, and assigned resources for performing activities and for meeting milestones. The defacto standard is Microsoft Project


Detailed task list with dependencies for each of the sub-systems and functions

Standards for Content and Format –

DoIT or PMBOK standards

Quality Review –


PAGE 14 OF 51


4.1.1.5 Risk, Issues and Change ManagementDescription - Tool used to document project issues and risks that could impact the project schedule/cost either negatively or positively

Deliverable Acceptance Criteria - Updated documents are available for weekly review by

DOH PM High level issues/risks are presented for review in the

monthly steering committee meetingsStandards for Content and Format -

DoIT recommended templates or other formatsQuality Review -.Review and approval by DOH project manager

4.1.1.6 Test Plan

Description - Tool used to document the testing approach, specific test cases that will be executed to verify that the system is delivering as per the design


Test plan with documented changes to the design of the system for CMS, Families FIRST, Newborn Hearing systems and cloud hosting


DoIT recommended templates or other formats

Quality Review –


4.1.1.7 Training PlanDescription - Tool used to document what modules will be included for training, who will be trained and the time frame

Deliverable Acceptance Criteria –Separate detailed Training Plan & user documents for CMS, Families FIRST and Newborn Hearing systemsStandards for Content and Format -

DoIT recommended templates or other formatsQuality Review -.

Review by DOH project manager

4.1.1.8 Release Plan

Description - Tool used to document a plan for deploying predefined modules to production


Release plan with schedule of releases for deploying CMS, Families FIRST, Newborn Hearing systems and bug fixes



Quality Review –


PAGE 15 OF 51


4.1.1.9 Quality Plan

Description - Tool used to document the steps to be followed to ensure that all the plans are executed, deliverables are completed in a timely fashion as per the schedule


Quality plan with details including the quality metrics outlined in this document



Quality Review –


4.1.1.10 Configuration Management Plan

Description - Tool used to document the hardware/software configuration of the project and how the version controls will be managed


Define the process for managing configuration changes and version control



Quality Review –


4.1.1.11 Disaster Recovery Plan

Description - Tool used to document the steps that will be followed to make sure that the system will be operational in case of a disaster


Defines the process for disaster recovery, business continuity, back up and redundancy



Quality Review –


4.1.1.12 Migration Plan

Description - Tool used to document the steps that will be executed to migrate data from existing systems to new system as per defined scope


Define all the steps involved in migrating & testing of data from existing systems to the new system



PAGE 16 OF 51


Quality Review –


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 NUMBER

DELIVERABLE APPROVERS (WHO CAN APPROVE)

DATE APPROVED/ REVIEWED

PM-DEL-001 Project Charter Gene Lujan

PM-DEL-002 Project Management Plan (PMP) Gene Lujan

PM-DEL-003 Work Breakdown Structure (WBS) Gene Lujan

PM-DEL-004 Project Schedule Gene Lujan

PM-DEL-005 Risk, Issues and Change Management

Gene Lujan

PM-DEL-006 Test Plan Gene Lujan

PM-DEL-007 Training Plan Gene Lujan

PM-DEL-008 Release Plan Gene Lujan

PM-DEL-009 Quality Plan Gene Lujan

PM-DEL-010 Configuration Management Plan Gene Lujan

PM-DEL-011 Disaster Recovery Plan Gene Lujan

PM-DEL-012 Migration Plan Gene Lujan

4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE

All deliverables will be signed off by the approvers listed in the above table using the Deliverables Acceptance Template within 5 business days after the deliverable is submitted for approval or list any issues that need to be resolved. ACRO team will re-submit for acceptance after resolving the issues identified and the approvers will sign off within 2 business days. The deliverable is deemed to be accepted if the sign off is not received after 2 business days. Issues identified in this Deliverable Acceptance Procedure will follow the Issues Escalation Process that is defined in a later section.

4.2 PRODUCT LIFE CYCLE

PAGE 17 OF 51


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

Phase Summary of Phase Key Deliverables

Requirements Requirements definition Functional Requirements Document (FRD)

Requirements Traceability & Verification Matrix (RTVM)

Design Development of Architecture and System Design

Gap Analysis Report

Use Case document

System Design

Development Software development Code

Unit Test results

Testing Testing & Training Test cases

Test Results

User Training

UAT

Defect resolution

Deployment Promote code to Production

Deployment Plan

4.2.1 TECHNICAL STRATEGY

Key technical strategies for achieving success in this project:

Detailed requirements & technical designs are discussed in JAD (Joint Application Design) sessions, reviewed and signed-off by project team

Requirements traceability matrix is established and maintained until UAT sign-off

Test scenarios, test cases are created, executed and verified as per the traceability matrix

PAGE 18 OF 51


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 Functional Requirements Document (FRD)Description - Tool used to clearly define a function of the system consisting of a set of inputs, behavior and outputs the system is supposed to accomplish

Deliverable Acceptance Criteria -Complete list of requirements listing the changes needed in the system for CMS, Families FIRST, Newborn Hearing and cloud hostingStandards for Content and Format -

DoIT recommended templates or other formatsQuality Review -


4.2.2.2 Requirements Traceability & Verification Matrix

Description - Tool used to document all the requirements which will be used to track all Requirements through Design, Development, Testing, System Acceptance and to manage Requirement Changes


Complete list of all the requirements listing the changes needed in the system for CMS, Families FIRST, Newborn Hearing and cloud hosting in order to verify that the requirements have been coded, tested, verified to perform as per the design



Quality Review –


4.2.2.3 Use Case DocumentDescription - Tool used to document behavioral requirements describing all the cases where the system uses the functional requirements

Deliverable Acceptance Criteria -Complete list of all the behavioral requirements identifying the changes needed in the system for CMS, Families FIRST, Newborn Hearing and cloud hostingStandards for Content and Format -



PAGE 19 OF 51


4.2.2.4 System Design

Description - Tool used to document planning the development of information systems through understanding and specifying in detail what a system should do and how the components of the system should be implemented and work together to solve business problem


Design document depicting the changes that will be made



Quality Review –


4.2.2.5 Code

Description – Is a set of machine instructions to perform as defined in the use case


Source code to accomplish the function as per the design



Quality Review –


4.2.2.6 User ManualsDescription – Tool used to document step by step instructions to perform a function or an activity

Deliverable Acceptance Criteria -Document showing steps to be performed for each of the functionsStandards for Content and Format -



4.2.2.7 Deployment Plan

Description - Tool used to document all the activities/steps to be performed in sequence to set up the production environment


Document depicting steps to be performed for setting up production environment



Quality Review –


PAGE 20 OF 51


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 NUMBER

DELIVERABLE APPROVERS (WHO CAN APPROVE)

DATE APPROVED/ REVIEWED

PRD-DEL-001 Functional Requirements Document (FRD) Gene Lujan

PRD-DEL-002 Requirements Traceability & Verification Matrix

Gene Lujan

PRD-DEL-003 Use Case Document Gene Lujan

PRD-DEL-004 System Design Gene Lujan

PRD-DEL-005 Code Gene Lujan

PRD-DEL-006 User Manuals Gene Lujan

PRD-DEL-007 Deployment Plan Gene Lujan

4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE

All deliverables will be signed off by the approvers listed in the above table using the Deliverables Acceptance Template within 5 business days after the deliverable is submitted for approval or list any issues that need to be resolved. ACRO team will re-submit for acceptance after resolving the issues identified and the approvers will sign off within 2 business days. The deliverable is deemed to be accepted if the sign off is not received after 2 business days. Issues identified in this Deliverable Acceptance Procedure will follow the Issues Escalation Process that is defined in a later section.

PAGE 21 OF 51


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, see attachment for more detailed WBS.

Identifier Work Package Description Definition/Objective Milestone/Deliverable

FRD Functional Requirements Define the project requirements

System Design Technical design document showing all the modules that will developed for the project

Document showing the changes that will be made to accomplish the business objectives

Test Plan Plan listing test scenarios and test cases that will be executed

Objective is to verify that the design & changes made meet the requirements defined

Deployment Plan Step by step instructions to be executed to deploy after user sign-off is completed

Steps to be executed to create production environment for the application

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

Summary-level Gantt chart is listed below. Project schedule with additional high level tasks will be shared with DoH project manager after completion of Plan Phase.

PAGE 22 OF 51


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 406/5 6/12 6/19 6/26 7/3 7/10 7/17 7/24 7/31 8/7 8/14 8/21 8/28 9/4 9/11 9/18 9/25 10/2 10/9 10/16 10/23 10/30 11/6 11/13 11/20 11/27 12/4 12/11 12/18 12/25 1/1 1/8 1/15 1/22 1/29 2/5 2/12 2/19 2/26 3/4

Task NameFHB-CMS - PROPOSED PROJECT PLAN

Contract signing & Project KickoffREQUIREMENTS PHASE Requirement Gathering

Requirements VerificationProject Plan Creation and BaselineFunctional and System Spec Finalization

DESIGN PHASE System and database Design System ArchitectureFunctional and Technical DesignDatabase Design / Conversion

DEVELOPMENT PHASE Development and documentation (including Pilot) Application Development and SetupSystem/Application IntegrationData Conversion and MigrationUser and Training Documentation Unit Testing

TEST PHASE TestingUser TrainingSystem, Performance and Load TestingUser Acceptance Testing

DEPLOYMENT Begin staged Environment Setup deploymentConfiguration

GO LIVE Go Live

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

The details are available with ACRO project Lead

Phase / Activity Associated Deliverables Estimated Budget

Umbrella Tasks

Phase 1Project Preparation & Planning

Project Kick-offInitial Project Management Plan

PAGE 23 OF 51


Phase / Activity Associated Deliverables Estimated Budget

Phase 2Planning

Functional RequirementsUpdated Project Management Plan

Phase 3Execution

Application DesignData Migration PlanDisaster Recovery PlanTest PlanUATTrainingRelease 1 Application DeploymentDisaster Recovery Deployment

Phase 4Project Closing

Deliverable Acceptance

TOTALS

5.4 PROJECT TEAM5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE

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

5.4.2 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 Lead Single Point of Contact Kshiteej Bhosale Management

Project Manager Project Management Gordon Muthigi Project Management

PAGE 24 OF 51


ROLE RESPONSIBILITY NAME FUNCTIONAL AREA

Requirements Manager

Requirements, Business Analysis & Training

Vijayta Sharma Requirements Management

Technical Lead Technical Architect/Scrum Master

Alok Tyagi Technical Implementation

Team Lead Team Lead Navin Kumar Technical Implementation

Team Lead Technology Lead Pawan Kumar Technical Implementation

Project Engineer Application Development and Configuration

Sanjay Kumar Technical Implementation


Girish Barman Technical Implementation


Prateek Bhardwaj Technical Implementation

Web Designer Designing the website and Web pages

Parveen Kaushik Technical Implementation

QA Lead Quality Assurance Shashank Chaturvedi Technical Implementation

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

5.5.1 PROJECT STAFF

Not Applicable for this engagement.

5.5.2 NON-PERSONNEL RESOURCES

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

PAGE 25 OF 51


ResourceCost Estimate

Estimated units/hours Availability Source Work Product/Deliverable

N/A

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

5.6.1 PROJECT TEAM TRAINING

Not Applicable to this engagement.

6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENTPMBOK©:

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

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

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

6.1.1 RISK MANAGEMENT STRATEGY

A separate risk management plan will be provide with detailed explanation on the strategy for how risks are identified, analyzed/ quantified, mitigated, reported, escalated and tracked.

6.1.2 PROJECT RISK IDENTIFICATION

Please refer to risk management plan.

PAGE 26 OF 51


6.1.3 PROJECT RISK MITIGATION APPROACH

6.1.4 RISK REPORTING AND ESCALATION STRATEGY

Key risks are presented at the weekly status meetings and monthly executive status reports. DoIT Risk and Issue Log Template and calculation will be used to determine the risk level as described below:

Probability Levels: Certain, Expected, Likely, Possible, Unlikely

Impact Levels: Very High, High, Medium, Low, Very Low

The following table suggests the values at which the risks should be tracked, reported and escalated:

Minimum risk - Acceptable

Some risks - Monitor at PM/Team Level

High risks - Active monitoring with ongoing Contingency/Mitigation activity

Show stoppers - Active participation with steering committee to mitigate

PAGE 27 OF 51


6.1.5 PROJECT RISK TRACKING APPROACH

All risks are tracked weekly using the risk log and stored on SharePoint. Key risks are presented at the weekly status meetings and monthly executive status reports.

6.1.6 ISSUE MANAGEMENT

6.1.6.1 Internal Issue Escalation and Resolution ProcessThis internal process is provided for issues that involve project resources, processes, procedures, or methodology that should be resolved within the Division that is responsible for managing the project without affecting the overall project schedule, cost, or quality. This process should be used for improving project processes as the project is executed and where the implementation of such improvements should not be postponed to Lessons Learned during Project Close.

Internal issues are resolved at project team level. The issue is assigned to the responsible person with a target date. It is escalated to DOH project Manager or Acro project manager as appropriate. The next level of escalation is to executive management.

6.1.6.2 External Issue Escalation and Resolution ProcessThe external process is provided for issues that involve project resources, processes, procedures, or methodology that cannot be resolved within the Division that is responsible for managing the project without affecting the overall project schedule, cost, or quality.

External issues are reported to DOH project Manager to be resolved seeking the help of executive team as needed.

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

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

PAGE 28 OF 51


6.3.1 CHANGE CONTROL

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.

Change Control Board

State Contract Administrator

Impact Analysis,

Effort, Cost

Change Requests

Department of Health (DoH) Executive

Sponsor

Director Purchasing DoH

Approved Change Request

Recommendation

Appr

oved

Ch

ange

Re

ques

t

Addendum to ContractAcro

6.3.1.2 Change Request Process

NORMAL CR

URGENT CR

ACRO OUTPUT DoH ACTION AND RESPONSIBILITY

Initial Analysis (No Cost)

5 business days

24 hours Estimated cost and duration of detailed analysis

Review Initial Analysis and approve proceeding with Detailed Analysis

Detailed Analysis (Cost and Schedule estimate based on Initial Analysis)

TBD – Based on initial analysis

TBD – Based on initial analysis

Detailed Estimate: Cost and Schedule impact of CR on the overall project, if any

Review Detailed Analysis and approve Change Request estimate for implementation

Change Request Implementation (Upon CR approval by DoH)

As per detailed estimate

As per detailed estimate

Implementation of the CR as per the scope of the Change Request

Review the implementation and approve the changes as per the approved Change Request.

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

PAGE 29 OF 51


ELAINE ABHOLD DOH CMS TRAINING AND DEVELOPMENT SPECIALIST

MAUREEN BURNS DOH FAMILIES FIRST STATEWIDE PROGRAM MANAGER

SUSAN CHACON DOH CMS STATEWIDE PROGRAM MANAGER

GENE LUJAN DOH PROJECT MANAGER

KSHITEEJ BHOSALE ACRO PROJECT LEAD

GORDON MUTHIGI ACRO PROJECT MANAGER

6.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 BUDGET TRACKING This is a fixed cost project. At the completion of each milestone, billing and payment will occur as per the agreed timeline in SOW.

6.5 COMMUNICATION PLANCommunication planning involves determining the information and communication needs of the stakeholders, executive sponsors, project team and others as needed. The communication plan needs to address who needs what information, when they will need it, how it will be given to them, and by whom. The complexity of the project may require a separate communication plan; however a high level summary of that plan will need to be included here and a reference made to the appropriate Appendix.

6.5.1 COMMUNICATION MATRIX

6.5.2 STATUS MEETINGS

6.5.2.1 TEAM LEADS MEETING

Description: A daily Acro meeting with team leads to review progress and any outstanding issues

Objective: To resolve issues and update team on the project status

Format: Conference call

Participants: Leads from Acro

PAGE 30 OF 51


Frequency: Daily

Duration: 15 - 30 minutes

Owner: Acro PM

6.5.2.2 STATUS MEETING WITH FHB-ACAMS TEAM (WEEKLY)

Description: Review project status, action items, and any change requests

Objective: Resolve any issues and risks and follow up on action items


Participants: Project Team

Frequency: Weekly

Duration: 1 to 2 hours

Owner: DOH PM/Acro PM

6.5.2.3 STEERING COMMITTEE MEETING (MONTHLY)

Description: A reporting session for the steering committee at key points in the project

Objective: To confirm direction, cultivate sponsorship, report on status, findings and issues

Format: Formal presentation to the committee and approvals.

Participants: Project Managers and Project Executive

Frequency: As needed

Duration: 2 hours

Owner: DOH PM

6.5.2.4 EXECUTIVE UPDATE MEETING (MONTHLY)

Description: A high level report on key points in the project based on latest Steering Committee Meeting

Objective: To confirm direction, cultivate sponsorship, report on status, findings and issues

Format: Discussion of FHB-ACAMS issues

Participants: Project Managers, Project Executive, and Senior Leadership from DOH and Acro

Frequency: Monthly

Duration: 30 minutes.


PAGE 31 OF 51


6.5.2.5 PROJECT KICKOFF MEETING

Description: Formal launch of the project

Objective: To convey the project mission, executive summary, high level timeline

Format: Face to Face meeting

Participants: Project stakeholders

Frequency: At the beginning of the project

Duration: 3 hours


6.5.2.6 REQUIREMENTS & DESIGN SESSIONS

Description: Requirements gathering & design JAD sessions

Objective: To define and finalize requirements and designs

Format: Face to Face meeting

Participants: Project SMEs from DOH and Acro and Vendors (as needed)

Frequency: All day sessions - 2 weeks in June and 2 weeks in July, 2015

Duration: 3 hours session for each sub-system

Owner: Acro PM

6.5.2.7 TEAM TRAINING MEETING

Description: Formal classroom style team training

Objective: Educate DOH team on FHB-ACAMS project


Participants: DOH Trainers, SMEs and other team members

Frequency: At the end of the project prior to deployment

Duration: 4 hours

Owner: Acro Training Manager

6.5.2.8 DOH & ACRO PM MEETING

Description: Review status, action items, issues, risks and changes



Participants: DOH PM, Acro PM & Project Lead

PAGE 32 OF 51


Frequency: Weekly

Duration: 1 hour

Owner: Acro PM

6.5.2.9 EXTERNAL VENDOR TEAM MEETING

Description: Review Interface requirements, issues, action items, and timelines



Participants: DOH PM, Acro PM & Project Lead, Vendor PMs

Frequency: Weekly

Duration: 1 hour

Owner: DOH PM

6.5.2.10 ADHOC MEETINGS

Description: Adhoc meetings as needed

Objective: Resolve issues, action items and risks


Participants: DOH PM, Acro PM & Project Lead, other team members as needed

Frequency: As needed

Duration: 1 hour


6.5.3 PROJECT STATUS REPORTS

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.

6.6.1 BASELINES

PAGE 33 OF 51


Project Area Category Measure

Schedule and Progress Milestone Performance • Milestone DatesWork Unit Progress • Component Status

• Requirement Status• Test Case Status• Problem Report Status• Reviews Completed• Change Request Status

Product Quality Defects • Problem Reports• Defect Density• Defect Severity

Complexity • ComplexityRework • Rework Size

• Rework Effort

6.6.2 METRICS 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. If a separate Quality Plan is used, include a high level summary in this document and refer to the appropriate appendix.

Following are the quality objectives of the project that will be applied throughout the project.

Deliverables support improved project management proficiency at DoIT

Deliverables meet the requirements of DoIT leaders and project managers

Deliverables align with industry best practices for project management and Web delivery

Deliverables are easy to use

Project practices conform to recommended project management standards

6.7.1 QUALITY STANDARDS

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 34 OF 51


No. Quality Standard Tracking Tool or Measure

1 Project phase is completed by the established finish date. • Project Schedule• Project Status

2 Project is completed within budget. • Project Status• Control Change

Requests3 Quarterly project reviews show contractors deliver

requirements specified in the contract by due dates.• SOW• Project Status• Final Customer

Acceptance4 Project issues are resolved and documented within 10

calendar days of identification or extensions are justified.• Issues Tracking

5 Project will be completed based on the original project scope and approved scope changes.

• Project Charter• Project Plan• Control Change

Request6 Project defects are completed by due dates • Defect Management

Plan• Project Schedule

7 Deliverables are reviewed and signed-off by due dates • Project Schedule• Project Status• Issues Tracking•

PAGE 35 OF 51


6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTS Review Type Quality Standard Tools Reviewer ReportsRequirements Defined

completely in detail

Trackable

Microsoft excel

Project team Functional Requirements

Document (FRD)

Requirements Traceability & Verification Matrix (RTVM)

Plans Project deliverables listed in sections 4.1.1 and 4.2 of this plan

Microsoft Word, ExcelProject schedule

Project team

Predefined Templates

MilestonesProject milestones

Project Schedule

DOH PM Project Status

Testing Defects identifiedDefects remediated completely

Test management Tool

DOH SMEs, Acro Team

Defect Reports

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. This feedback will be used to take corrective actions to improve the performance for the success of the project and the professional growth of the project team members.

We will use the following template (used by some of the State of New Mexico agencies):

SSTANDARDSNot

Applicable

0

StronglyDisagree

1

Disagree

2

SomewhatAgree

3

Agree

4

StronglyAgree

5

The level of business or agency knowledge of FHB-ACAMS meets your expectations.

FHB-ACAMS performs in a professional and cooperative manner.

The level of communications by FHB-ACAMS, both written and oral, meet your expectations.

PAGE 36 OF 51


FHB-ACAMS project team works well with you and your staff.

FHB-ACAMS project management team is accessible when you need them.

FHB-ACAMS provides adequate information and training resulting in effective knowledge transfer.

FHB-ACAMS completes project tasks within the agreed upon schedule.

The level of technical or business expertise of FHB-ACAMS meets your expectations.

You are receiving full value from the FHB-ACAMS project management team.

The overall service provided by FHB-ACAMS is fully meeting your expectations.

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS How 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.

PAGE 37 OF 51


Deliverable Final Approval Process Customer Acceptance Criteria

Functional Requirements Document (FRD)

Electronic Document and Paper Sign-off on the document

Requirements Traceability & Verification Matrix

Electronic Document and Paper E-mail confirmation

Use Case Document Electronic Document and Paper E-mail confirmation

System Design Electronic Document and Paper E-mail confirmation

Code Electronic E-mail confirmation

User Manuals Electronic Document and Paper E-mail confirmation

Deployment Plan Electronic Document and Paper E-mail confirmation

Deliverables Acceptance Sign-off on the document

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

Microsoft SharePoint versions are backed up at regular intervals. The documents will have version numbers each time an update is made.

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

Microsoft SharePoint will be set up for storing all the project related documents and access provided to Project Team.

6.9 PROCUREMENT MANAGEMENT PLAN Projects 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.

PAGE 38 OF 51


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

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

7.2 CONTRACT CLOSE

Contract close is similar to administrative close in that it involves product and process verification for contract close.

ATTACHMENTSAttachments are included for additional information, but are not formally considered part of the Project Plan for approvals and change management purposes. Examples

Acronyms, abbreviations and definitions

Technical glossary of IT terms

Project Work breakdown schedule

PAGE 39 OF 51


ATTACHMENT A: ACRONYMS, ABBREVIATIONS AND DEFINITIONSPMI Project Management Institute.

PMBOK Project Management Body of Knowledge

PMO Program Management Office

PMP Project Management Plan

WBS Work Breakdown Structure

DEFINITIONSAcceptance Criteria

The criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE-STD-610]

Acceptance Testing

Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. [IEE-STD-610]

Assumptions

Planning factors that, for planning purposes, will be considered true, real, or certain. Assumptions generally involve a degree of risk. They may be documented here, or converted to formal risks.

Baseline

A specification or product that has been formally reviewed and agreed upon that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. [IEEE-STD-610]

Commitment

A pact that is freely assumed, visible, and expected to be kept by all parties.

Configuration Management (CM)

A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IEEE-STD-610]

Configuration Management Library System

The tools and procedures to access the contents of the software baseline library.

Constraints

Factors that will (or do) limit the project management team’s options. Contract provisions will generally be considered constraints.

PAGE 40 OF 51


Contingency Planning

The development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur.

Crashing

Taking action to decrease the total duration after analyzing a number of alternatives to determine how to get the maximum duration compression for the least cost.

Critical Path

The series of activities that determines the duration of the project. The critical path usually defined as those activities with float less than or equal to specified value often zero. It is the longest path through the project.

Dependencies, Discretionary

Dependencies defined by the project management team. They should be used with care and usually revolve around current Best Practices in a particular application area. They are sometimes referred to as soft logic, preferred logic, or preferential logic. This may also encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.

Dependencies, Mandatory

Dependencies that are inherent to the work being done. In some cases, they are referred to as hard logic.

Dependency Item

A product, action, piece of information, etc., that must be provided by one individual or group to a second individual or group so they can perform a planned task.

Deliverable

Any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a project or part of a project that is subject to approval by the project sponsor or customer.

Duration

The number of work periods (not including holidays or other nonworking periods) required to complete an activity or other project element.

Duration Compression

Shortening the project schedule without reducing the project scope. Often increases the project cost.

End User

The individual or group who will use the system for its intended operational use when it is deployed in its environment.

Effort

The number of labor units required to complete an activity or other project element. Usually expressed as staff hours, staff days, or staff weeks.

PAGE 41 OF 51


Fast Tracking

Compressing the project schedule by overlapping activities that would normally be done in sequence, such as design and construction.

Float

The amount of time that an activity may be delayed from its early start without delaying the project finished date.

Formal Review

A formal meeting at which a product is presented to the end user, customer, or other interested parties for comment and approval. It can also be a review of the management and technical activities and of the progress of the project.

Integrated Project Plan

A plan created by the project manager reflecting all approved projects and sub-projects.

Lessons Learned

The learning gained from the process of performing the project. Lessons learned may be identified at any point during the execution of the project.

Method

A reasonably complete set of rules and criteria that establish a precise and repeatable way of performing a task and arriving at a desired result.

Methodology

A collection of methods, procedures, and standards that defines an integrated synthesis of engineering approaches to the development of a product.

Milestone

A scheduled event for which some individual is accountable and that is used to measure progress.

Non-technical Requirements

Agreements, conditions, and/or contractual terms that affect and determine the management activities of an architectural and software project.

Performance Reporting

Collecting and disseminating performance information. This includes status reporting measurement, and forecasting.

Procurement Planning

Determining what to procure and when.

Product Scope

The features and functions that characterize a product or service.

Project Leader (Technical)

PAGE 42 OF 51


The leader of a technical team for a specific task, who has technical responsibility and provides technical direction to the staff working on the task.

Project Management

The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project Management is also responsible for the oversight of the development and delivery of the architecture and software project.

Program

A group of related projects managed in a coordinated way. Programs include an element of ongoing work.

Program Management Office

An organizational entity responsible for management and oversight of the organization’s projects. As a specific reference in this document, the Office of the Chief Information Officer.

Project Manager

The role with total business responsibility for an entire project. The individual who directs, controls, administers, and regulates a project. The project manager is the individual ultimately responsible to the customer.

Project Charter

A document issued by senior management that formally authorizes the existence of a project. It provides the project manager with the authority to apply organizational resources to project activities.

Project Management Plan

A formal, approved document used to guide both project execution and project control. 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. The Project Management Plan (PMP) is a project plan.

Project Schedule

A tool used to indicate the planned dates, dependencies, and assigned resources for performing activities and for meeting milestones. Software products such as ABT’s Workbench and Microsoft Project are tools used to develop project schedules.

Project Scope

The work that must be done to deliver a product with the specified features and functions.

Project Sponsor

The individual that provides the primary sponsorship for an approved project. This individual will play a key role in securing funding, negotiating for resources, facilitating resolution of critical organizational issues, and approving key project deliverables.

Quality

The degree to which a system, component, or process meets specified requirements.

PAGE 43 OF 51


The degree to which a system, component, or process meets customer or user needs or expectations. [IEEE-STD-610]

Quality Management

The process of monitoring specific project results to determine if they comply with relevant standards and identifying ways to eliminate causes of product non-compliance.

Risk

Possibility of suffering loss.

Risk Management

An approach to problem analysis, which weighs risk in a situation by using risk probabilities to give a more accurate understanding of, the risks involved. Risk Management includes risk identification, analysis, prioritization, and control.

Risk Management Plan

The collection of plans that describes the Risk Management activities to be performed on a project.

Risk Management

Risk mitigation seeks to reduce the probability and/ or impact of a risk to below an acceptable threshold.

Scope Change

Any change to the project scope. A scope change almost always requires an adjustment to the project cost or schedule.

Software Life Cycle

The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The Software Life Cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation, and checkout phase, operation and maintenance phase, and, sometimes, retirement phase.

Stakeholder

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.

Standard

Mandatory requirements employed and enforced to prescribe a disciplined uniform approach to software development

Statement of Work

A description of all the work required completing a project, which is provided by the customer.

System Requirements

A condition or capability that must be met or possessed by a system component to satisfy a condition or capability needed by a user to solve a problem. [IEEE-STD-610]

PAGE 44 OF 51


Subproject

A smaller portion of the overall project.

Task

A sequence of instructions treated as a basic unit of work. [IEEE-STD-610]

A well-defined unit of work in the software process that provides management with a visible checkpoint into the status of the project. Tasks have readiness criteria (preconditions) and completion criteria (post conditions). (see activity for contrast.)

Team

A collection of people, often drawn from diverse but related groups, assigned to perform a well-defined function for an organization or a project. Team members may be part-time participants of the team and have other primary responsibilities.

Technical Requirements

Those requirements that describe what the software must do and its operational constraints. Examples of technical requirements include functional, performance, interface, and quality requirements.

Traceability

The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another. [IEEE-STD-610]

Work Breakdown Structure

A deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work.

PAGE 45 OF 51