New Mexico Department of Information Technology - NM DoIT



[pic]

PUBLIC EDUCATION DEPARTMENT (PED) – STATEWIDE FINANCIAL REPORTING PROJECT

PROJECT MANAGEMENT PLAN

EXECUTIVE SPONSOR – ADÁN DELGADO, DEPUTY SECRETARY, FINANCE & OPERATIONS

Business Owner – David Craig, School Budgets Bureau Director

Project Manager – Sally Trigg

Original Plan Date: December 6, 2020

Revision Date: December 10, 2020

Revision: 1.0

TABLE of CONTENTS

1.0 Project Overview 1

1.1 Executive Summary- Rationale for the Project 1

1.2 Funding and Sources 2

1.3 Constraints 2

1.4 Dependencies 2

1.5 Assumptions 2

1.6 Initial Project Risks Identified 2

2.0 Project Authority and Organizational Structure 3

2.1 Stakeholders 3

2.2 Project Governance Structure 4

2.2.1 Executive Steering Committee 5

2.2.2 Describe the role and members of the project steering committee 5

2.2.3 Organizational Boundaries, interfaces and responsibilities 6

2.3 Executive Reporting 6

3.0 Scope 7

3.1 Project Objectives 7

3.1.1 Business Objectives 7

3.1.2 Technical Objectives 7

3.2 Project Exclusions 7

3.3 Critical Success Factors 7

4.0 Project Deliverables and Methodology 8

4.1 Project Management Life Cycle 8

4.1.1 Project Management Deliverables 9

4.1.2 Deliverable Approval Authority Designations 14

4.1.3 Deliverable Acceptance Procedure 15

4.2 Product Lifecycle 15

4.2.1 Technical Strategy 15

4.2.2 Product Development Deliverables 15

4.2.3 Deliverable Approval Authority Designations 16

4.2.4 Deliverable Acceptance Procedure 16

5.0 Project Work 16

5.1 Work Breakdown Structure (WBS) 16

5.2 Schedule Allocation -Project Timeline 17

If Project and Product Deliverables changed since prior certification, please explain: The Planning phase has been expedited due to project timeline concerns. The changed dates reflect a need to get contract services and licensing in place sooner. Additionally, Training and Support services were not included previously. 17

Deliverable 18

Due Date 18

Project Phase 18

5.3 Project Budget 19

5.4 Project Team 19

5.4.1 Project Team Organizational Structure 19

5.4.2 Project Team Roles and Responsibilities 19

5.5 Staff Planning and Resource Acquisition 20

5.5.1 Project Staff 20

5.6 Project Logistics 20

5.6.1 Project Team Training 21

6.0 Project Management and Controls 21

6.1 Risk and Issue Management 21

6.1.1 Risk Management Strategy 21

6.1.2 Project Risk Identification 21

6.1.3 Project Risk Mitigation Approach 22

6.1.4 Risk Reporting and Escalation Strategy 22

6.1.5 Project Risk Tracking Approach 22

6.1.6 Issue Management 22

6.2 Independent Verification and Validation – IV&V (waiver to be sought) 23

6.3 Scope Management Plan 23

6.3.1 Change Control 23

6.4 Project Budget Management 24

6.4.1 Budget Tracking 24

6.5 Communication Plan 25

6.5.1 Communication Matrix 25

6.5.2 Status Meetings 27

6.5.3 Project Status Reports 27

6.6 Performance Measurement (Project Metrics) 27

6.6.1 Baselines 27

6.7 Quality Objectives and Control 27

6.7.1 Quality Standards 28

6.7.2 Project and Product Review and Assessments 28

6.7.3 Agency/Customer Satisfaction 29

6.7.4 Product Deliverable Acceptance Process 29

6.8 Configuration Management 30

6.8.1 Version Control 30

6.8.2 Project Repository (Project Library) 30

6.9 Procurement Management Plan 30

7. 0 Project Close 30

7.1 Lessons Learned 30

7.2 Administrative Close 31

7.3 Contract Close 31

7.4 Transition to Data Analytics Operational Support 31

7.5 PCC Presentation – Project Closure 31

Appendix A: Terms of Reference and Acronyms 31

Revision History

|Revision Number |Date |Comment |

|1.0 |12/23/2020 |Draft PMP |

| | | |

| | | |

| | | |

The project goal is to meet the requirements of 2020’s 54th Legislature in the State of New Mexico, SENATE BILL 96 (SB96) which appropriated to the Public Education Department three million dollars to implement, maintain and provide training for a Statewide Online Reporting System.

SB96 legislation identifies the following requirements for the Statewide Online Reporting System:

• Establishing a standard chart of accounts (COAs) across school districts and charter schools

• Annual reporting of financials using the standard COAs across all school districts and charter schools

• Facilitation by stakeholder of online comparisons of financial data across all school districts and charter schools

• Financial data shall include school administrative costs and staff personnel costs

• Financial data shall include budget and expenditure data across schools for at risk students, bi-lingual and multicultural education services, and support for special education students

• Revenue sources including local, state and federal funding

1.0 Project Overview

1.1 Executive Summary- Rationale for the Project

Critical project objectives for the success of this project includes:

• the definition of standard COAs

• modifications to the existing legacy financial system

• improvements in data collection from school districts and charter schools

• online publication of consolidated and detailed financial data

• ongoing training and technical support for the new Statewide Online Reporting System

The business needs this project addresses are:

• Inconsistent financial reporting across local education agencies (LEAs) impedes:

o Outcome-based funding decisions

o Investment comparisons by funding source

o Administrative cost comparisons across LEAs

o Budget allocations to support students identified as at-risk, bilingual, multicultural, and eligible to receive special education services

o Identifying actual personnel costs

• Lack of transparency for stakeholders which leads to:

o Uninformed decision making

o Inequities in available services

o Higher costs and inefficient spending

1.2 Funding and Sources

|Source |Amount |Associated restrictions |Approvers |

|Laws 2020, Chapter 71, Section 2|$3,000,000 | |54th Legislature in the State of |

| | | |New Mexico, SENATE BILL 96 (SB96) |

1.3 Constraints

|Number |Description |

|1 |SB96 Legislation language and time constraints on use of funds by FY23. |

1.4 Dependencies

• 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 approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.

• E-External dependencies are dependencies that involve a relationship between project activities and non-project activities such as purchasing/procurement

|Number |Description |Type M, D, E |

|1 |existing legacy Financial System – Operational Budget Management System (OBMS) |M |

1.5 Assumptions

|Number |Description |

|1 |Public access to school level financial information |

|2 |Student level data will be protected |

1.6 Initial Project Risks Identified

Internal PED staff capacity

|Staffing and skillsets are limited both on|Probability - HIGH |Impact - high |

|the IT and program side and could hinder | | |

|project timelines | | |

| |Mitigation Strategy – include program and IT staff in the project |

| |Contingency Plan - be prepared to hire contractors as needed |

Procurement Obstacles

|Delays in contract approvals and other |Probability - MEDIUM |Impact -high |

|procurements | | |

| |Mitigation Strategy – early inclusion of financial staff |

| |Contingency Plan - request timeline extensions |

DoIT Obstacles

|Delays in DoIT exception request approvals|Probability - LOW |Impact -high |

| |Mitigation Strategy – early submission of exceptions requests |

| |Contingency Plan - request timeline extensions |

Legacy Financial System Modification Delays

|Delays implementing required modifications|Probability - LOW |Impact -high |

|to the legacy financial system needed to | | |

|implement the new Standard COAs | | |

| |Mitigation Strategy – early engagement of PED Financial Business owner in required modifications|

| |Contingency Plan - request timeline extensions |

2.0 Project Authority and Organizational Structure

2.1 Stakeholders

|name |Stake in Project |Organization |Title |

|Ryan Stewart, Ed. L.D. |Agency Head |PED |Cabinet Secretary |

|Adan Delgado |Executive Sponsor/Executive Steering |PED |Deputy Secretary |

| |Committee (ESC) | | |

| |Member | | |

|Mary Montoya |Executive Steering Committee Member |PED |Chief Information |

| | | |Officer (CIO) |

|David Craig |Executive Steering Committee (ESC) |PED |Director of Schools |

| |Member, Business Owner | |Budget Bureau |

|Contract Project Manager PM |Project Management Office (PMO) |PED |Project Manager |

|School Districts and Charter schools |173 LEAs (school districts and charters|Local Educations Agencies (LEA) |LEA |

| |schools) provide school level financial| | |

| |data to the system | | |

|Public (parents, teachers, students) |Evaluation resources to address | | |

| |students’ needs | | |

|PED programs |Allocation of resources to address |State Education Agency (SEA) |SEA |

| |at-risk populations | | |

|Legislative Finance Committee (LFC) and |Public trust |New Mexico (NM) Legislative | |

|Legislative Educational Study Committee | |Committee | |

|(LESC) | | | |

|Regional Education Center (REC) |Partner to school districts and |NM Legislative Committee | |

| |Charters | | |

|Federal Public Education Agency |Evaluation of resources to address |Federal Education Agency (FEA) |FEA |

| |students’ needs | | |

2.2 Project Governance Structure

2.2.1 Executive Steering Committee

Organizational Chart

[pic]

2.2.2 Describe the role and members of the project steering committee

2.2.2.1 Steering Committee Chair Role

The Executive Sponsor operates as the Chair for the Project Steering Committee. As such, the Chair is point person for the project within the highest level of PED.

Responsibilities include:

• Champions the project;

• Considers potential changes facing the organization and assesses the organizational impact;

• Decides which changes will be instituted, communicates priorities and provides resources to ensure success;

• Responsible for creating an environment that enables changes to be made on time and within budget;

• Participates in planning sessions;

• Chairs the Steering Committee; and

• Ultimate project responsibility.

2.2.2.2 Steering Committee Member Role

The Steering Committee provides governance over the direction and support of the project. The responsibilities of the Steering Committee Members include:

• Attend and participate in meetings;

• Review and provide comment on presented documentation;

• Balance larger picture versus details of the project;

• Review project funding and expenditures;

• Champion the project; and

• Contribute to lessons learned.

2.2.3 Organizational Boundaries, interfaces and responsibilities

The key interfaces for stakeholders and PED programs impacted by the Statewide Financial Reporting Project will be through PED Divisions, PED Office of the CIO and IT Project Manager.

The methods of communications utilized on the project will include:

• Status Reports and Briefings;

• Standing Core Team or Executive Steering Committee Meetings;

• Ad-hoc meetings;

• Electronic mail;

• Distribution of Meeting Minutes;

• Video conferencing and

• Phone conversations.

2.3 Executive Reporting

A Communication Plan will be developed during the Planning Phase. That plan will include objectives, target audience, methods, frequency and single point of contact details. A copy of the plan is available in the PED IT PMO project repository.

Reporting for this project will be subject to current standards from the State of New Mexico’s (SONM) Department of Information Technology (DoIT); monthly reports will be submitted to DoIT. Monthly Dashboard reports will be generated according to New Mexico Public Education Department’s (PED) standards and guidelines. In addition, Monthly ESC meetings will be held to provide the ESC with a high-level update on project status and any issues.

3.0 Scope

3.1 Project Objectives

3.1.1 Business Objectives

|Number |Description |

|Business Objective 1 |From input from stakeholders define the scope for a statewide financial reporting system. |

|Business Objective 2 |The new system will be based on standard COAs. |

|Business Objective 3 |Reporting will be consistent from school, to LEA to PED. |

|Business Objective 4 |The new system will make transparent each LEA actual spending and report each of the major financial |

| |categories in the COA. |

3.1.2 Technical Objectives

|Number |Description |

|Technical Objective 1 |Establish a Business Intelligence and Data Analytics cloud-based platform as a cornerstone |

| |architectural component |

|TECHNICAL OBJECTIVE 2 |Establish secure architecture that accesses multiple data sources |

|TECHNICAL OBJECTIVE 3 |Ensure compliance with all Federal, State and other regulatory security standards (e.g. Payment |

| |Card Industry – Data Security Standard PCI-DSS, FERPA, PII, etc.) |

3.2 Project Exclusions

Detailed Project Exclusions to be determined during the Planning Phase.

3.3 Critical Success Factors

The following Quality Metrics 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 Metric 1 |The project is completed within approved budget. |

|Quality Metric 2 |The project is completed within the approved schedule. |

|QUALITY METRIC 3 |The system meets stated business objectives and requirements. |

4.0 Project Deliverables and Methodology

4.1 Project Management Life Cycle

|Phase |Summary of Phase |Key Deliverables |

|Initiation |Define the scope, schedule and budget for |Project Management Plan draft |

| |performance, including business benefits to be |Project Schedule draft |

| |achieved (measures of success). |Risk Assessment |

| |Conduct high level planning; including risk |Monthly DoIT Reports |

| |management and production cut over. |Project Certification Committee Certification |

| |Develop the strategy for delivering on the |Request (Plan) |

| |goals and objectives of the project, and all | |

| |key planning documents. | |

| |Identify key project team members and form | |

| |Project Team. | |

| |Conduct project kickoff meeting. | |

|Plan |Develop tactical plan for delivering on the |PCC Certification Request (Implementation) |

| |goals and objectives of the project and |Updated Risk Assessment |

| |finalize all key planning documents. |Finalized Project Management Plan |

| |Confirm scope with the business and leadership |Baselined Project Schedule |

| |Finalize vendor contracts (including IV&V, if |Monthly DoIT Reports |

| |applicable) |PCC Certification Request (Implementation) |

| | |Communications Plan |

|Implementation |Finalize requirements and develop Business |BRD |

| |Requirements Document (BRD) |Test Strategy and Plan |

| |Enable and configure Data Analytics |Test Results |

| |Conduct unit, systems and end to end testing |Training Plan |

| |Conduct Train the Trainer and End User Training|Trainer’s Trained |

| | |End User Training |

| | |Cutover Plan |

| | |Updated Risk Assessment |

| | |Monthly DoIT Reports |

|Closeout |Monitor production usage and provide |Lessons Learned Report |

| |operational support as required. |Monthly DoIT Reports |

| |Transition long term support to operational |Project Closeout Report |

| |groups |PCC Certification Request (Closeout) |

| |Close out financial and contractual | |

| |instruments, and archive project documents as | |

| |appropriate. | |

| |Conduct Lessons Learned analysis | |

| |Close project | |

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 Management Plan draft

|Description - This Project Management Plan is a formal |Deliverable Acceptance Criteria – Contains sufficient detail about the project to |

|document approved by the executive sponsor and the |convey a clear understanding of the project scope and objectives. Content should |

|Department and developed in the plan phase used to |cover at a minimum schedule, budget, risk, organization structure, project and |

|manage project execution, control, and project close. |product deliverables, communications, change management, governance, project |

| |controls, testing, training, production cutover, and closeout. |

| |Standards for Content and Format - Compliant with DoIT Template Standards and |

| |guidelines |

| |Quality Review - 1st Review: Project Manager, Deputy CIO |

4.1.1.2 Project Schedule draft

|Description - The Project Schedule is the key project |Deliverable Acceptance Criteria - All Project Tasks, Milestones, and Deliverables |

|management tool by which the PED Statewide Financial |detailed, with durations, predecessors, and resources entered. |

|Reporting Project will be managed. The Project Schedule | |

|contains all project key tasks, activities and | |

|milestones. Tasks and activities are defined with | |

|durations and deliverables, predecessor tasks, the | |

|deliverable associated with that task where one exists, | |

|and the resources necessary to complete the tasks. | |

|Once finalized and reviewed, the Project Schedule will | |

|be baselined, and reports will be generated based on the| |

|baseline and actual performance of the project team. | |

| |Standards for Content and Format - consistent with Best Practice Project Management |

| |Standards (PMBOK) and DoIT requirements |

| |Quality Review - 1st Review: Project Manager, PMO Manager, Deputy CIO |

| |2nd Level Review: ESC |

|4.1 |Quality Review - 1st Review: Project Manager, PMO Manager, Deputy CIO |

| |2nd Level Review: ESC |

4.1.1.3 Risk Assessment

|Description – The Risk Assessment documents risk |Deliverable Acceptance Criteria - Contains sufficient detail for each phase of the |

|evaluations performed by project leadership during the |project to convey clear due diligence review and assessment of project risks, |

|initiation of the project. The project team then updates|impacts, and mitigation strategies for all areas (i.e.; project organization, |

|the risk assessment at the end of each phase of the |requirements, planning, business, technology, change management, et cetera). |

|project, or more frequently as needed. Each risk | |

|assessment is called out in the project schedule and in | |

|the RAID (Risks, Actions, Issues and Decisions) folder | |

|in the project document repository. | |

| |Standards for Content and Format - Compliant with DoIT Template Standards and |

| |guidelines |

| |Quality Review - 1st Review: Project Manager, Deputy CIO |

| |2nd Level Review: ESC, IV&V Contractor. |

4.1.1.4 Communications Plan

|Description – The PED Statewide Financial Reporting |Deliverable Acceptance Criteria – Provides a detailed description of the |

|Project Communications Plan provides an approach for |communications strategy and plan, including audiences, types of information, media |

|communications and support for the PED Statewide |and venues to be used in managing communications, and a communication matrix. |

|Financial Reporting Project. | |

| |Standards for Content and Format – Follows accepted best practices and is compliant |

| |with DoIT Template Standards and Guidelines |

| |Quality Review - 1st Review: Project Manager, Deputy CIO |

4.1.1.5 Monthly DoIT Reports

|Description – Provides governance with project base |Deliverable Acceptance Criteria - All areas of the Project Status Report Form |

|information, monthly updates on the project schedule and|completed with sufficient levels of detail to convey complete understanding of the |

|budget status, and monthly updates on project milestone |status to governance. |

|completion. | |

| |Standards for Content and Format - Compliant with DoIT Standards |

| |Quality Review - 1st Review: Project Manager, Deputy CIO. |

| |2nd Level Review: DoIT EPMO |

4.1.1.6 PCC Certification Request (all phases)

|Description - The Request for Certification and Release |Deliverable Acceptance Criteria - All areas of the Request for Certification and |

|of Funds form is submitted when a project goes for any |Release of Funds Form completed with sufficient levels of detail to convey complete |

|of the certification phases. It deals with the financial|understanding of the effort to governance. |

|aspects of the project, as well as other topics that | |

|indicate the level of planning that has gone into the | |

|project. Many of the questions have been incorporated | |

|into the preparation of the project charter. | |

| |Standards for Content and Format - Completed to DoIT Standards |

| |Quality Review - 1st Review: Project Manager |

| |2nd Level Review: Deputy CIO |

4.1.1.7 Independent Verification and Validation (IV&V) Contract and Reports- TBD

4.1.1.8 Add Data Analytics related entries

4.1.1.9 Test Strategy and Plan

|Description - The Test Strategy and Plan will consist of|Deliverable Acceptance Criteria - Test Strategy documents the overall strategy for |

|unit, system, end to end process, and end user quality |testing the processes and modules being delivered by the project, and communicates |

|acceptance testing cycles, and it will include testing |the scope and phases of testing, the components that will tested, details any |

|related to work flows, configuration, data conversion, |dependencies between testing phases and other projects, and how the testing |

|interfaces, training materials and performance or |processes will be completed and managed. |

|response times. |The Test describes in detail the tactical methods by which the Test Strategy will |

| |be implemented. |

| |Standards for Content and Format - Project Management Best Practice and DoIT |

| |Standards |

| |Quality Review - 1st Review: Project Manager, PMO Manager, Deputy CIO, CIO |

4.1.1.10 Training Plan

|Description - The Training Plan will address methods and|Deliverable Acceptance Criteria – The Training Plan will describe the methods and |

|procedures for training trainers and conducting end user|procedures for delivering training to trainers and end users at a detailed level. |

|training. |The Training Plan will also delineate the course material that will be taught, |

| |describe the different courses and content, and detail the schedule for training. |

| |The Training Plan should also include a training matrix defining which staff will |

| |receive what training. |

| |Standards for Content and Format - Project Management Best Practice and DoIT |

| |Standards |

| |Quality Review - 1st Review: Project Manager, PMO Manager, Deputy CIO, CIO |

4.1.1.11 Production Cutover Plan

|Description - The Production Cutover Plan will document |Deliverable Acceptance Criteria - Conveys a clear understanding of the decision |

|the requirements for operational and technical |criteria and metrics by which production readiness will be evaluated, roles and |

|readiness, detail the cutover process, describe support |responsibilities of individuals providing support, and the procedure that will be |

|mechanisms and processes during the first four weeks |implemented in the unlikely event that a rollback must be implemented. |

|(warrantee period) of production use, and describe the | |

|process for rolling back in the unlikely event that the | |

|solution must be taken back out of production once the | |

|cutover has occurred. | |

| |Standards for Content and Format - Project Management Best Practice and DoIT |

| |standards |

| |Quality Review - 1st Review: Project Manager, Deputy CIO |

| |2nd Level Review: ESC |

4.1.1.12 Lessons Learned Report

|Description – A report detailing those elements of the |Deliverable Acceptance Criteria – Effectively captures and documents the lessons |

|project that could be improved upon, and those aspects |learned from the project from multiple perspectives, in a way that the lessons may |

|of the project that went very well, typically developed |be applied on future projects to advantage. |

|from the perspectives of leadership, team members, and | |

|from the customer. Designed to support continuous | |

|process improvement. | |

| |Standards for Content and Format - Project Management Best Practice and DoIT |

| |standards |

| |Quality Review - 1st Review: Project Manager, Deputy CIO |

| |2nd Level Review: ESC |

4.1.1.13 Project Closeout Report

|Description – A report that is used to request that the |Deliverable Acceptance Criteria - Production use achieved with satisfactory usage, |

|project be officially closed. |and warranty period has passed without significant events to justify extending the |

| |project team support; all project documentation filed and/or archived; lessons |

| |learned analysis completed; benefits realization in progress. |

| |Standards for Content and Format - Developed in accordance with Project Management |

| |Best Practices and to DoIT Standards |

| |Quality Review - 1st Review: Project Manager; Deputy CIO |

| |2nd Level Review: Executive Sponsor; DoIT; PCC |

4.1.1.5 Monthly PED Dashboard Reports

|Description – Provides governance with project base |Deliverable Acceptance Criteria - All areas of the Project Status Report Form |

|information, monthly updates on the project schedule and|completed with sufficient levels of detail to convey complete understanding of the |

|budget status, and monthly updates on project milestone |status to governance. |

|completion. | |

| |Standards for Content and Format - Compliant with DoIT Standards |

| |Quality Review - 1st Review: Project Manager, Deputy CIO. |

| |2nd Level Review: DoIT EPMO |

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 |

|PRJ-DEL-001 |Risk Assessment |Mary Montoya, CIO | |

|PRJ-DEL-002 |Communications Plan |Mary Montoya, CIO | |

|PRJ-DEL-003 |Project Management Plan (PMP) |Mary Montoya, CIO | |

|PRJ-DEL-004 |Project Schedule |ESC | |

|PRJ-DEL-005 |Implementation Cutover Plan |ESC | |

|PRJ-DEL-006 |Project Closeout Report |Mary Montoya, CIO | |

4.1.3 Deliverable Acceptance Procedure

Project deliverables will be developed collaboratively and iteratively by the lead project manager working with the balance of the project team and partner project managers from the legacy Financial System (OBMS) Vendor. Once a deliverable is deemed to be complete by the lead project manager and partner project managers, the deliverable will be submitted to the Deputy CIO for review and approval.

Issues identified in this Deliverable Acceptance Procedure will follow the Issues Escalation Process that is described in a subsequent section of this document.

Depending on the deliverable, it may be submitted to the SONM DOIT’s Enterprise Project Management Office (EPMO) or Project Certification Committee (PCC) for further review and approval.

4.2 Product Lifecycle

The project will be conducted in accordance with Project Management best practice and in compliance of SONM statutes and DoIT requirements.

4.2.1 Technical Strategy

• Detailed Strategy will be created during the Planning Phase.

Anticipated Project Outcomes (To Be Refined During Planning Phase):

4.2.2 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

|Description – |Deliverable Acceptance Criteria – |

| |Standards for Content and Format – |

| |Quality Review - 1st Review: 2nd Level Review: |

4.2.2.2

|Description – |Deliverable Acceptance Criteria - |

| |Standards for Content and Format – |

| |Quality Review - 1st Review: 2nd Level Review: |

4.2.2.3

|Description – |Deliverable Acceptance Criteria – |

| |Standards for Content and Format – |

| |Quality Review - 1st Review: 2nd Level Review: |

4.2.3 Deliverable Approval Authority Designations

|Deliverable Number |Deliverable |Approvers (Who can approve) |Date Approved |

|PROD-DEL-001 |Detailed Deliverables will be created during the | | |

| |Planning Phase. | | |

|PROD-DEL-002 | | | |

|PROD-DEL-003 | | | |

|PROD-DEL-004 | | | |

|PROD-DEL-005 | | | |

|PROD-DEL-006 | | | |

|PROD-DEL-007 | | | |

4.2.4 Deliverable Acceptance Procedure

Please refer to Section 4.1.3 of this Project Management Plan

5.0 Project Work

5.1 Work Breakdown Structure (WBS)

The following WBS is a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project.

|Identifier |Work Package Description |Definition/Objective |Milestone/Deliverable |

|1 |PED Statewide Financial Reporting | N/A |None |

|1.1 | Project Management |Manage Scope, Schedule, Budget Risk and |Project Scope Completed on schedule and within |

| | |Communications |budget |

| | | |Monthly DoIT Status Reports |

|1.2 | Initiation Phase |Finalize Project Charter, Complete Risk |Project Charter |

| | |Assessment, Draft PMP and Schedule, and |Initial Risk Assessment |

| | |develop Communications Plan |PMP draft |

| | | |Initial Project Schedule |

|1.3 | Planning Phase |Finalize PMP and baseline schedule, and |PMP |

| | |execute IV&V contract, if applicable, |Schedule Baselined |

| | | |Communications Plan |

| | | |IV&V Contract, if applicable |

|1.4 | Implementation Phase |Identify deployment issues, enable and |Statewide Financial Reporting Module(s) enabled |

| | |configure Data Analytics, configure and |and configured |

| | |integrate visualization tool, and conduct|Unit and End to End Testing Completed |

| | |unit and end to end testing | |

|1.5 | Deployment Phase |Conduct Train the Trainer and End User |Trainers Trained |

| | |Training; |End Users Trained |

| | | |Statewide Financial Reporting deployed |

|1.6 | Closeout Phase |Provide Operational support during |Transition to Production Support |

| | |warranty period, transition support to |Lessons Learned Report |

| | |operations, conduct lessons learned |Closeout Report |

| | |review and complete closeout activities | |

*The above items will be updated during the project planning phase.

5.2 Schedule Allocation -Project Timeline

The following project timeline is a high-level view of project activities with a focus on project milestones.

A detailed project schedule will be created during the Planning Phase.

|Project and Product Deliverables |

|If Project and Product Deliverables changed since prior certification, please explain: The Planning phase has been expedited due to |

|project timeline concerns. The changed dates reflect a need to get contract services and licensing in place sooner. Additionally, Training |

|and Support services were not included previously. |

|Deliverable |Due Date |Project Phase |

|PCC Certification for Project Initiation Approved |10/22/2020 |Initiation |

|Stakeholder Identification |11/30/2020 |Initiation  |

|Final Project Charter |12/7/2020 |Initiation |

|Draft Project Management Plan |12/10/2020 |Initiation |

|PCC Certification for Project Planning Approved |12/23/2020 |Initiation |

|Conduct focus groups to elaborate on stakeholder requirements |1/15/2021 |Planning |

|Refine Project Schedule |2/1/2021 |Planning |

|Define Scope of Work for modifications to the legacy financial system |2/1/2021 |Planning |

|Procure Business Intelligence and Data Analytics tool and hosting |2/1/2021 |Planning |

|platform | | |

|Identify minimal set of Use cases |2/28/2021 |Planning |

|Define data integration approach between the legacy financial system and |3/15/2021 |Planning |

|the cloud-based Business Intelligence and Data Analytics platform | | |

|Define integration between PED website and the cloud-based Business |3/15/2021 |Planning |

|Intelligence and Data Analytics platform | | |

|Hire internal staff to support the project |4/1/2021 |Planning |

|Define Data Governance and Data Privacy requirements |4/1/2021 |Planning |

|Final Project Management Plan |4/1/2021 |Planning |

|PCC Certification Implementation Approved |4/15/2021 |Planning |

|Begin Initial Reporting and Dashboards |5/1/2021 |Implementation |

|Chart of Account implementation completed |6/1/2021 |Implementation |

|Legacy financial system modifications completed |8/1/2021 |Implementation |

|Training Services defined and delivered |11/30/2021 |Implementation |

|Initial Reporting and dashboard implementation completed |12/31/2021 |Implementation |

|Reporting and dashboard enhancements and support |6/1/2023 |Implementation |

|Long-term support services defined |6/15/2023 |Implementation |

|Project Lesson Learned collected |6/15/2023 |Implementation |

|PCC Certification for Project Closeout |6/30/2023   |Closeout |

5.3 Project Budget

The following is a list of cost estimates applied to an activity in the project by assigning resources with associated rates or fees.

|Identifier |Work Package or Budget Category |Cost |

| |Contract Project Manager & Business Analyst Services (Initiation through Closeout) |$340,000.00 |

| |Planning Phase |$2,467,000.00 |

| |Implementation Phase |$193,000.00 |

| |Closeout Phase |$0 |

| |Total Project Budget |$3,000,000.00 |

5.4 Project Team

5.4.1 Project Team Organizational Structure

A detailed Project Team Organizational Team Structure will be created during the Planning Phase

5.4.2 Project Team Roles and Responsibilities

The following is a list of team members, their role, responsibilities and functional areas.

|Role |Responsibility |Name |Functional Area |

|Executive Sponsor |Strategic Guidance |Adán Delgado |Governance and Leadership |

|CIO |Strategic Guidance |Mary Montoya |Governance and Leadership |

|Schools Budget Bureau |Strategic Guidance |David Craig |Governance and Leadership |

|Director | | | |

|Deputy CIO |Strategic Guidance |Richard Trujillo |Governance and Leadership |

|PMO Manager |Strategic Guidance |To Be Determined (TBD) |Governance and Leadership |

|Project Manager |PED Statewide Financial Reporting Project |TBD |Project Management |

| |Manager | | |

|Business Intelligence Analyst| |TBD | |

| | | | |

|Web Solutions Developer | |TBD | |

5.5 Staff Planning and Resource Acquisition

Detailed Project Staff Planning and Resource Acquisition will be created during Panning Phase.

5.5.1 Project Staff

|Resource |Cost Estimate |Estimated Hours |

|Schedule |Schedule Variance (Schedule Value Index) |>= 1.0 |

|Budget |Budget Variance (Cost Value Index) |>= 1.0 |

|Quality |Key Project Documents Approved by Leadership |100% |

6.6.1 Baselines

|Project Area |Category |Measure |

|Project Schedule |Schedule |On or ahead |

|Project Budget |Budget |Under |

|Project Scope |Scope Control |0 Change Orders |

6.7 Quality Objectives and Control

The PED Statewide Financial Reporting project goal is to conduct a timely, cost effective implementation without modifying or customizing the software. These are the Quality Objectives by which the project will be judged.

Quality Control will be further demonstrated in the Test Strategy and Plan as well as the Training Plan.

6.7.1 Quality Standards

|No. |Quality Standard |Tracking Tool or Measure |

|1 |NM Taxation Administration Act |Compliance with the New Mexico Selected |

| | |Taxation and Revenue Laws and Regulations |

| | |(2018 Edition) |

|2 |Project Management Body of Knowledge (PMBOK), 6th Edition |Schedule, Scope, Budget, Communications, |

| | |Risks, Actions, and Issues Management and |

| | |Control conducted in accordance with best |

| | |practice as defined by PMBOK |

|3 |Information Technology standards defined within the Information Technology|PCC Presentations, Certifications and funding|

| |framework by DoIT |release |

| | |Monthly status reports to DoIT |

|4 |Federal Tax Information (FTI), and Personal Identifiable Information (PII)|Compliant with NMAC 2.60.8 |

| |best practice standards. |Compliant with Policies, Procedures and Best |

| | |Practices |

|5 |End User adoption and satisfaction |End user surveys |

| | |Issues and trouble reports submitted during |

| | |warranty period following production cutover |

6.7.2 Project and Product Review and Assessments

|Review Type |Quality Standard |Tools |Reviewer |Reports |

|Requirements |NM Statutes; Steering |MS-Visio, MS-Excel, MS-Word, |Deputy CIO; Business Owner;|BRD |

| |Group Policies |Fast Central Repository |PED Statewide Financial | |

| | | |Reporting Project ESC | |

|Plans |PMBOK |MS-Word, MS-Project |Deputy CIO; |PMP, Communications Plan, |

| |DoIT | |Business Owner |Training Plan, |

| | | | |Test Plan |

|Milestones |PMBOK |MS-Project |Deputy CIO; Business Owner;|Status Reports |

| |DoIT | |ESC |ESC Presentations |

|Testing |PMBOK |MS-Word |Deputy CIO; Business Owner;|Status Reports |

| |DoIT |MS-Excel |ESC |Test Strategy and Plan |

| | |NMT Environment | |Use Cases |

| | | | |Test Results |

6.7.3 Agency/Customer Satisfaction

Customer and Agency satisfaction will be assessed on an on-going basis by the PED Statewide Financial Reporting Project Manager and Team. Weekly (Stakeholder) and Monthly (DoIT) Status reports and ESC Meetings will be the primary mechanisms by which the PED Statewide Financial Reporting Project Team will communicate progress, goals and objectives, and call out issues and benefits.

Project reporting metrics will provide primary feedback on schedule and budget performance, and we will coordinate our efforts with initiatives wherever synergy and common interests exist.

The Project Manager will meet with the ESC monthly to ensure project performance is meeting expectations, and with others in leadership as needed to ensure customer and agency satisfaction,

6.7.4 Product Deliverable Acceptance Process

All products produced by the PED Statewide Financial Reporting Project will be reviewed by oversight groups and leadership.

Testing the Data Analytics modules and end to end processes will have several dimensions to ensure quality and consistency in all deliverables. Requirements will be documented in the Business Requirements Document (BRD) and formally signed off by the Business Owner. Requirements will in turn be mapped to test cases to ensure full coverage in the testing.

The Testing itself will be cumulative and iterative to ensure that there are no gaps in the testing coverage. Unit Testing will be followed by End to End Process Testing. End to End Process Testing will consist of running transactions through their entire life cycle (i.e., payment to distribution).

Following completion of End to End Process Testing, a final round of End User Acceptance Testing will be undertaken. Staff from various field offices receiving the technology will be engaged to process work using the PED Statewide Financial Reporting technology and provide feedback to the project team regarding the experience.

Prior to beginning production use of the PED Statewide Financial Reporting technology, an evaluation will be made regarding operational readiness in several areas, including training readiness, technical readiness, quality assurance testing readiness, and operational support readiness. The results of that evaluation will be presented to the ESC, which will make the final determination on approving the production cut-over.

6.8 Configuration Management

Detailed configuration management will be created during the Planning Phase.

.

6.8.1 Version Control

To be determined based on the outcome of the project planning phase.

6.8.2 Project Repository (Project Library)

The PED Statewide Financial Reporting Project repository will be maintained utilizing the PMO Shared Drive.

6.9 Procurement Management Plan

The PED Statewide Financial Reporting Project includes procurement of Project Management and Business Analyst services through TEKsystems, software modification services from RESPEC Vendor, Business Analyst support and Business Intelligence Analyst to be determined during planning phase.

All procurement has been or will be conducted in accordance with established standards and procedures promulgated by State Purchasing Division (SPD) and in accordance with DoIT guidelines.

7. 0 Project Close

Project Close consists of evaluating the project execution from a best-practice perspective, closing out administrative elements of the project, and contractual and financial aspects of the project as it relates to external vendors. A final element to the closeout relates to handing off ownership of the systems to the business, through transition to the Data Analytics Operations for on-going support. The final step in the Project Close is a presentation to DoIT’s PCC, which will review the closure request. Completing these activities is a mandatory step in the project life cycle.

7.1 Lessons Learned

Closure of the PED Statewide Financial Reporting Project will begin with a series of Lessons Learned Review working sessions. All project team members will be encouraged to participate and other stakeholders to be invited. The results of that review will be documented and included in the Project Closeout Report.

7.2 Administrative Close

Administrative activities complete the internal needs for managing the project, such as records archival, recording the last hours against the project, transitioning staff to other assignments. Administrative closure consists of verifying that objectives and deliverables were met and transitioning remaining relevant documentation to the appropriate agencies providing on-going support.

7.3 Contract Close

Contractual activities must meet the contractual needs, such as executing a procurement audit and formal acceptance of the project work products. Contract close is similar to the administrative close in that it involves product and process verification for contract close.

7.4 Transition to Data Analytics Operational Support

Closeout will also include formalizing the hand-over of support responsibilities to appropriate staff within PED, for end user training and technical support.

7.5 PCC Presentation – Project Closure

The Closeout Request and Presentation will be submitted to the PCC, and based on the approval of the PCC, the Project will be closed.

Appendix A: Terms of Reference and Acronyms

- A -

Acceptance 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]

Action Item – work that requires follow up. Typically has a single owner and a ‘need by’ or ‘due’ date. A/I’s are generally small relative to scheduled tasks, but discrete in terms of the deliverable. The other differentiating factor on A/I’s are that they normally have a bearing on risks and issues if not completed in a timely manner.

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.

- B -

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]

- C -

Change Management Log – The change management log lists the current status and project impact of each planned or enacted project change request. The log shows at a glance the current impact of change on the project. The Project Manager in a MS-Excel Worksheet format will maintain the change management log. The log will be updated when a proposed or approved PCR is received. The log will be reviewed at the weekly Leadership meeting and reported on in the Weekly Status report.

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]

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

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.

- D -

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.

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 in turn perform a planned task.

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.

- E -

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.

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

- F -

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

FCR – Fast Central Repository, the Fast Enterprises methodology and tool set utilized for managing GenTax and Tapestry deployments.

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.

- I -

Integrated Project Plan – A plan created by the project manager reflecting all approved projects and sub-projects.

IPS – Integrated Project Schedule; a master schedule created by the project manager reflecting all approved project activities of the main project and sub-projects.

Issue – an event or condition that has negative consequences for the project. Issues are current, recoverable and can be mitigated in some way. An issue differs from a risk in that a risk hasn't happened yet.

ITD – Information Technology Division, a division within the Taxation and Revenue Department

- L -

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.

- M -

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.

- N -

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

- O -

OLA – Operations Level Agreement

- P -

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

PMBOK – Project Management Body of Knowledge

PMI – Project Management Institute

Point of Sale (POS) System – a POS System is a combination of hardware and software utilized to process a sales transaction and payment for goods or services.

Procurement Planning – Determining what to procure and when.

Product Scope – The features and functions that characterize a product or service.

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

Project Change Request forms – A PCR (Project Change Request) is a request for change on the project. It has two parts, one for estimating the cost to investigate the PCR, the other to determine how much the PCR will cost to implement. All project changes require an approved PCR.

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 Leader (Technical) – The leader of a technical team for a specific set of tasks. Typically referred to as the Technical Lead, they have technical responsibility, and provide technical direction to the staff working on the tasks.

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.

Project Manager – The role with 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.

Program Management Office (PMO) – 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 Management Plan (PMP) – 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.

- Q -

QMP – Quality Management Plan

Quality – The degree to which a system, component, or process meets specified requirements. 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.

- R -

Risk – Possibility of suffering loss. An uncertain future event or condition that, if it occurs, will have a positive or negative effect on a project’s objectives. Although in theory risks can be positive, project management normally focuses on the adverse or negative risks.

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 mitigation seeks to reduce the probability and/ or impact of a risk to below an acceptable threshold.

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

- S -

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.

SOP – Standard Operating Procedure

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 – The Statement of Work (SOW) is the contractual agreement that defines the project objectives, expectations and scope. Each project member should be familiar with the SOW particularly as it relates to project scope and the definition of completion for each major deliverable.

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]

Subproject – A smaller portion of the overall project.

- T -

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). Please refer to activity for contrast.

Task Assignment Sheets – Where applicable, the project manager will provide a detailed outline of the specific steps required to complete an assigned task. The Task Assignment Sheet provides much greater detail and specificity than the project schedule. In some cases, a single project schedule task may be broken down into fifteen or more steps to complete. Where practical this Task Assignment Sheet will be developed in MS Word and distributed in hard copy prior to opening the new task. In addition, the project manager will hold a coaching session at the start of each task to review the task assignment.

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 – 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]

- W -

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

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download