1.0 Project Overview - NM Web view-Requirements management (including definition and managing requirements traceability matrix) ... -Word and MS Project Reports. Monthly-Project sponsor

SPECIAL EDUCATION MAINTENANCE OF EFFORT TECHNICAL SOLUTION

PROJECT MANAGEMENT PLAN (PMP)

EXECUTIVE SPONSOR –SECRETARY DESIGNATE CHRISTOPHER RUSZKOWSKI

BUSINESS OWNER – DENISE KOSCIELNIAK

PROJECT MANAGER – KATHRYN CLEARY

ORIGINAL PLAN DATE: JUNE FOURTEENTH, TWO THOUSAND AND SEVENTEEN

REVISION 2.0

1.0 Project Overview 5

1.1 Executive Summary- rationale for the Project 5

1.2 funding and sources 2

1.3 constraints 3

1.4 dependencies 3

1.5 ASSUMPTIONS 3

1.6 Initial Project Risks Identified 4

2.0 Project Authority and Organizational Structure 4

2.1 Stakeholders 4

2.2 Project Governance Structure 6

2.2.1 Org Chart 6

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

2.2.3 Organizational Boundaries, interfaces and responsibilities 7

2.3 Executive Reporting 7

3.0 Scope 9

3.1 Project Objectives 9

3.1.1 Business Objectives 9

3.1.2 Technical Objectives 9

3.2 Project exclusions 9

3.3 Critical Success Factors 9

4.0 Project Deliverables and methodology 10

4.1 Project Management Life Cycle 10

4.1.1 Project Management Deliverables 11

4.1.1.1 [Project Management] 11

4.1.1.2 [MOE System User Adoption Plan (to be implemented in Deliverable 4.2.2.7)] 11

4.1.1.3 [Project Closure] 12

4.1.2 Deliverable Approval Authority Designations 12

4.1.3 Deliverable Acceptance Procedure 12

4.2 PRODUCT LIFE CYCLE 13

4.2.1 Technical Strategy 14ii

4.2.2 Product and Product Development Deliverables 15

4.2.2.1 [Solution Design Refinements (Preliminary)] 15

4.2.2.2 [Technical Development, Custom Reporting and Testing] 15

4.2.2.3 [Solution Design Refinements (Final)] 15

4.2.2.4 [System Deployment and Testing] 16

4.2.2.5 [System Security Testing] 16

4.2.2.6 [Administrator/Operator/End-User System Training Manual] 16

4.2.2.7 [MOE System User Adoption Plan Implementation] 17

4.2.2.8 [SEA and LEA Implementation Support] 17

4.2.2.9 [Operating Budget Management System (OBMS) Report Delivery and Software Development Support] 17

4.2.3 Deliverable Approval Authority Designations 18

4.2.4 Deliverable Acceptance Procedure 18

5.0 Project Work 18

5.1 Work Breakdown Structure (WBS) 18

5.2 Schedule allocation -Project Timeline 20

5.3 Project Budget 22

5.4 Project Team 23

5.4.1 Project Team Organizational Structure 23

5.4.2 Project Team Roles and Responsibilities 23

5.5 Staff Planning And Resource Acquisition 25

5.5.1 Project Staff 25

5.5.2 Non-Personnel resources 27

5.6 PROJECT LOGISTICS 27

5.6.1 Project Team Training 27

6.0 Project Management and Controls 27

6.1 Risk and issue Management 27

6.1.1 Risk Management Strategy 27

6.1.2 Project Risk Identification 28

6.1.3 Project Risk Mitigation Approach 28

6.1.4 Risk Reporting and Escalation Strategy 28

6.1.5 Project Risk Tracking Approach 28

iii

6.1.6 ISSUE MANAGEMENT 28

6.1.6.1 Internal Issue Escalation and Resolution Process 28

6.1.6.2 External Issue Escalation and Resolution Process 28

6.2 Independent Verification And Validation - IV&V 28

6.3 Scope Management Plan 29

6.3.1 Change Control 29

6.3.1.1 Change Control Process 29

6.3.1.2 Change Control Board (CCB) 30

6.4 Project Budget Management 30

6.4.1 Budget Tracking 30

6.5 Communication Plan 30

6.5.1 Communication Matrix 30

6.5.2 Status Meetings 31

6.5.3 Project Status Reports 31

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS) 31

6.6.1 Baselines 31

6.6.2 Metrics Library 31

6.7 QUALITY OBJECTIVES AND CONTROL 32

6.7.1 quality Standards 32

6.7.2 Project and Product Review and Assessments 32

6.7.3 Agency/Customer Satisfaction 32

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS 34

6.8 CONFIGURATION MANAGEMENT 34

6.8.1 Version Control 34

6.8.2 Project Repository (Project Library) 34

6.9 PROCUREMENT MANAGEMENT PLAN 34

7. 0 Project Close 34

7.1 Administrative Close 34

7.2 Contract Close 35

Attachments 35

Attachment: Project Timeline 36

iv

REVISION HISTORY

REVISION NUMBER DATE COMMENT

1.0 July 18, 2017 Original

2.0 September 11, 2017 Revision, brought into alignment with SOW dated 8/24/17.

1.0 PROJECT OVERVIEW

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT

v

The New Mexico Public Education Department (NMPED, PED) Special Education Program Office is required to submit annual Maintenance of Effort (MOE) reports to the US Department of Education regarding program implementation data. The Office of Special Education Programs’ (OSEP’s) review (2016) of New Mexico’s Individuals with Disabilities Education Act (IDEA) Part B MOE reduction and Coordinated Early Intervening Services (CEIS) resulted in a number of findings in the Local Education Agency (LEA) MOE/CEIS data submissions. As a result of not meeting federal requirements this past year, LEAs are at risk of losing federal funding for MOE.

As a result of highly cumbersome internal processes for gathering needed data and the inadequate data systems that are relied upon to provide decision-making information, NMPED is seeking a comprehensive solution that will enable the state system to reliably and efficiently conduct the federal reporting requirements related to Special Education Maintenance of Effort Reporting assist LEAs in meeting MOE expenditure requirements.

This PMP represents Phase II of a two-phase plan. Phase I of this work included:1. Engagement with PED and LEA stakeholders to map out all processes and data use for

MOE2. Requirements gathering for user interfaces3. Gathering of business, technical and data validation requirements4. Initial solution design for the real-time solution to be built as part of Phase II

Phase II will include the refinements to the solution design, building and testing the solution, conducting security testing, documentation, training and change management/user adoption for a real-time, integrated, open-source solution that leverages the benefits of Operating Budget Management System (OBMS), while integrating and automating data collection, integration and reporting to solve NMPED Federal reporting requirements.

1.2 FUNDING AND SOURCES

SOURCE AMOUNT ASSOCIATED RESTRICTIONS

APPROVERS

IDEA –B Federal Fund, Individuals with Disabilities Education Act

$800,000.00 none John Kraman

IDEA –B Federal Fund, Individuals with Disabilities Education Act

$1,100,000.00 none John Kraman

vi

1.3 CONSTRAINTS

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

NUMBER DESCRIPTION

1 Project is on an aggressive timeline, as work needs to be completed by 6/30/18.

2 Resources are limited as Special Education Bureau (SEB) Program Staff can only devote 10% of their time to the project.

1.4 DEPENDENCIES

NUMBER DESCRIPTION TYPE M,D,E

1 The Implementation of the MOE System User Adoption Plan cannot be executed until MOE Tool is in production and has passed initial testing.

M

1.5 ASSUMPTIONS

NUMBER DESCRIPTION

1 PED will identify and maintain the virtual space(s) for storage of LEA- and PED-specific training materials so that users may access videos and documentation on their own.

2 The SEB Staff will commit to the project in order to become System SMEs and expert users.

3 Changes to scope, features, schedule, or functionality will go through formal change control process.

7

1.6 INITIAL PROJECT RISKS IDENTIFIED

[Risk 1 Scope Changes]

Description -Requirements definitions drift or scope enlargement based on newly discovered requirements during implementation

Probability : LIKELY Impact: MEDIUM

Mitigation StrategyUse requirements management tools to identify scope changes early. Ensure agreements are revisited during project coordination meetings. Implement and follow a formal change control process for requested changes.

Contingency PlanIf scope change is determined to be beneficial but is too burdensome to implement in current development cycle, stage for future development cycle.

[Risk 2 Systems Integration]

Description -Systems integration difficulties

Probability: Possible Impact HIGH

Mitigation StrategyDevelop alternative data integration frameworks and methodologies available to cope with unexpected challenges in data integration.Contingency PlanAs the system is attempting to reconcile data from multiple sources, determine if the integration is based on a particular system that may be reconciled through the use of the existing process.

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE

2.1 STAKEHOLDERS

NAME STAKE IN PROJECT

ORGANIZATION TITLE

Christopher Ruszkowski Sponsor PED Cabinet Secretary

John Kraman Project Director PED IT Chief Information Officer PED

Executive Team Stakeholders PED Representatives from the senior PED Leadership

Advisory Committee Stakeholders Special Education Bureau (SEB), Districts and State

Representatives from the SEB program management, District and

8

Charters State Charter Representatives/SMEs

Philip Heimes Project Executive Contractor EASOL – Chief Executive Officer

Sonya Lopes Project Manager Contractor EASOL Project Manager

Stephen Midgley Technical Lead Contractor EASOL Technical Lead

Tim Bickerton Product Manager Contract EASOL Product Manager

Patrick Cook Account Manager Contractor UPD, Consulting – Partner. Account Manager

Ann Willemssen Process Project Manager

Contractor UPD, Consulting Process Project Manager

9

2.2 PROJECT GOVERNANCE STRUCTURE

2.2.1 ORG CHART

2.2.2 DESCRIBE THE ROLE AND MEMBERS OF THE PROJECT STEERING COMMITTEE

ROLE RESPONSIBILITY

Executive Sponsor Provide strategic direction and policy approvals where required. The Project Sponsor will champion the project within the organization and ensure the overall success of the project.

Project Director Provide high level project oversight, vision, and direction. Determine and commit appropriate resources. Resolve issues and problems. Provides strategic direction to Program Manager. Provides oversight for the Project Manager, the IT contract, and other IT support provided to the MOE Project.

Project Executive Provide high level project oversight, vision, and direction. Determine and commit appropriate resources. Resolve issues and problems. Provides strategic direction to the development team.

10

Program Staff

Program Manager

LEA Users Group

Stakeholders CommitteeIV & V

Contractors and IT Staff

IT Project Managers

John Kraman, Chief Information Officer

Christopher Ruszkowski, PED Cabinet SecretaryExecutive Sponsor

Project Director

Project Management

Internal Support

External Support

Program Manager Provides oversight for the MOE Project; ensures all program timelines are adhered to. Works with the IT project manager, Special Education Staff and external support (Content Area Experts, Stakeholders Committee, and the LEA Users Group) concerning the SOW and project deliverables.

IT Project Managers Provides oversight of all reporting; provides project management certification, planning, scheduling, assessment, and reporting documentation in collaboration with the PED Chief Information Officer (CIO), the IT support team, the Special Education Program Manager, and external support (Content Area Experts, Stakeholders Committee, LEA Users Group and the IV & V contractor).

Project Staff The project staff will design, build, test and deploy product.Stakeholders Committee Will meet regularly with IT Project Manager, Program Manager and Project staff to

support, guide and inform the work of the project. Their involvement is essential to ensuring that user requirements will be satisfied by the end product.

IV & V The IV & V contractor will evaluate the work or products of a particular phase to determine if the requirements of the phase have been fulfilled.

LEA Users Group Highly motivated and competent stakeholders that will test and pilot the new MOE System and related processes.

2.2.3 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES

The technical work required to complete the MOE System will be completed by EASOL who will interact with PED IT, SEB and the LEA Advisory Group. This includes requirements gathering, gathering input from internal and external stakeholders, conceptual and technical design and coding work, server configuration, system testing, troubleshooting, and deployment of the system. This also includes technical manuals and materials associated with the project. The testing and system release as well as UAT will be completed by UPD, Consulting in consultation with PED IT, SEB, LEA Advisory Group and EASOL. All work associated with planning, designing, building, and implementing and deploying the system throughout all phases whether conducted by EASOL or UPD will be managed at the highest level by the office of the CIO.

2.3 EXECUTIVE REPORTING

All documentation for the MOE Project will reside in a project document library created on the SharePoint System that connects to the Team Foundation Server (TFS) site.

Deliverable/ Communication

Recipient Delivery Method Frequency Responsible Party

Project Status NMPED Written Monthly Project Manager

DoIT Monthly Project Report

DoIT Email Monthly CIO

Executive Team Reports Executive team Face-to-face Monthly CIO

IV&V Reports DoIT, executive sponsor, steering committee

Email Monthly IV&V vendor

11

Weekly Project Status Project team members/project director

Email/Face-to-face/conference call

Weekly Project team members

Advisory Forum Meeting Advisory forum members, executive sponsor

Face-to-face Bi-Monthly Project team Members/IT project manager/program manager

Special Communication As needed As needed As needed As needed

As part of 6.5 (Communication Plan), executives will be kept abreast of project status, issues or concerns via the following touch points.

Type Objective of Communication

Frequency Audience Owner Deliverable

Project Team Meetings

Review status of the project with the team.

Weekly -Project team-Steering committee-PMO-CIO

Project Manager -Agenda-Meeting minutes-Project schedule

Steering Committee Meetings

To inform and guide the work of the project

Bi-monthly -Leadership team-Executive team-CIO

Project Manager or CIO

-Agenda-Meeting minutes-Project schedule

Bi-Monthly Project Status Meetings

Report on the status of the project to management.

Bi-monthly -PMO Project Manager or CIO

-Slide updates-Project schedule

Project Status Reports

Report the status of the project including activities, progress, costs and issues.

Monthly -Project sponsor-Project teamstakeholders-PMO


-Project status report-Project schedule

12

3.0 SCOPE

3.1 PROJECT OBJECTIVES

3.1.1 BUSINESS OBJECTIVES

NUMBER DESCRIPTION

Bus. Objective 1 Eliminate Office of Special Education Programs (OSEP) MOE findings

Bus. Objective 2 Improve the accuracy and timeliness of data required for MOE

Bus. Objective 3 Decrease the amount of time spent by the SEB to conduct the MOE analysis for all LEAs and State Charters

3.1.2 TECHNICAL OBJECTIVES

NUMBER DESCRIPTION

Tech. Objective 1 Ensure technical solution allows for the seamless integration of data from three sources/systems.

Tech. Objective 2 Allow for an extract, transform, load (ETL) of data from local financial and student information systems.

3.2 PROJECT EXCLUSIONS

While this project seeks to ensure the seamless transfer of data across relevant LEA and PED systems, the financial data related to MOE will continue to be entered via SHARE Financial User Interface.

Also not included in the scope of this project are: ongoing help desk and/or service support, maintenance and support or hardware/software upgrades.

3.3 CRITICAL SUCCESS FACTORS

NUMBER DESCRIPTION

QUALITY METRICS 1 PERCENTAGE OF RELEVANT PED STAFF THAT ACCESS THE TOOL INITIALLY (UPON TOOL RELEASE) AND MONTHLY.

QUALITY METRICS 2 PERCENTAGE OF LEAS THAT ACCESS THE TOOL INITIALLY (UPON TOOL RELEASE) AND MONTHLY.

QUALITY METRICS 3 DATA WITHIN OPERATING BUDGET AND MANAGEMENT SYSTEM (OBMS) IS ACCURATE

QUALITY METRICS 4 PED AND LEA STAFF KNOW HOW TO USE THE TOOL TO INPUT RELEVANT DATA

13

QUALITY METRIC 5 PERFORMANCE TO SCHEDULE

QUALITY METRIC 6 PERFORMANCE TO BUDGET

QUALITY METRIC 7 QUALITY OF DELIVERABLES

4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE

Phase Summary of Phase Key Deliverables

Initiating Project Charter approved

Authorization to proceed with planning

Project Charter

Project Scope

Business Requirements Business Case

Assumptions

Constraints

Planning Approved Project Plan Project Plan

Critical success factors

Work Breakdown Structures

Project Schedule

Planning Develop and implement a change management and user adoption plan to include:

1. Roll out plan and management2. Communication plan and

management

MOE System User Adoption Plan

Controlling Design completed, tested and modified iteratively until system requirements are met.

Pilot of system will provide additional system performance metrics that could lead to deployment or product changes.

Performance/status reports

Corrective action

Measurement metrics

Plan change requests

Product change requests

Risk management

Issue management

Execution Early adopter training strategy

In person “training” and discussion sessions with adopters

Training videos

MOE System User Adoption Plan implementation

14

Vetted written user guides that are understandable to non-technical users

Execution Project deliverables completed Actual efforts

Project deliverables completion

Closing Deliverable or product acceptance Deliverable or product acceptance

Lessons learned

4.1.1 PROJECT MANAGEMENT DELIVERABLES

4.1.1.1 [Project Management]Description -Execute project management tasks as appropriate, including but not limited to:-Project planning-Integration management-Scope management-Schedule management-Cost management-Quality management-Resource management-Communications management-Risk management-Procurement management-Stakeholder Management-Pre-implementation and implementation-Close-out-Requirements management (including definition and managing requirements traceability matrix)

Deliverable Acceptance Criteria -Completion of written documents corresponding to project management tasks, as described in section 4.2, Product Life Cycle Deliverables.Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Documents will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance when the work is complete to their satisfaction.

4.1.1.2 [MOE System User Adoption Plan (to be implemented in Deliverable 4.2.2.7)]

Description -Development of a change management/user adoption plan to roll out the MOE system to SEA and LEAs.

Deliverable Acceptance Criteria -Completion of written documents corresponding to user adoption and change management and completion of system user adoption plan, as described in section 4.2, Product Life Cycle Deliverables.Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Completed written documents and completed final MOE system user adoption plan will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance when the work is complete to their satisfaction.

15

4.1.1.3 [Project Closure]Description -Transfer to client of all assets, files, video footage, diagrams, schematics and data model visualizations created outside of the DoIT infrastructure in which the system was developed.

Deliverable Acceptance Criteria -Successful delivery of assets, files, video footage, diagrams, schematics and data model visualizations to client and completion of written project close out report, as described in section 4.2, Product Life Cycle Deliverables.Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Assets, files, video footage, diagrams, schematics and data model visualizations and written project close out report will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance when the work is complete to their satisfaction.

4.1.2 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS

DELIVERABLE NUMBER

DELIVERABLE APPROVERS (WHO CAN APPROVE)

DATE APPROVED

All deliverables All deliverables John Kraman

4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE

Formal written acceptance will be required for key deliverables in this project.

16

4.2 PRODUCT LIFE CYCLE 4.2. Product Life Cycle Deliverables

Phase Summary of Phase Key Deliverables

Initiation Kick off, request for funds, and initial solution design

Project Charter

Plan Ongoing refinements of solution design based on client input and feedback, changes in Special Education requirements and leveraging of technology to align to other IT transformation initiatives, change management

Special Education MOE process maps

Use cases for SEA and LEAs

Needs assessments for SEA and LEAs

Business requirements documentation

Data validation rule documentation

User interface/user experience requirements

Technical requirements documentation

Data maps and extensions to Ed-Fi data model

Technical solution design and architecture documents

Project management plan

Risk registry

IV & V reports

Monthly progress reports

System user adoption plan

Design Hardware, software and network architecture design and configuration, test design

Systems configuration documentation

System implementation plan

System testing framework documentation (automated and manual)

Hardware, software and network design/configuration documentation

System maintenance plan

Solution design reports (preliminary and final)

Design Project consultation (system, process, technical expertise) for OBMS-related design of solution

OBMS reports: MOE Budget, MOE Expenditures, MOE Expenditures Burn Rate, MOE BARs by EA, MOE RfR by EA

Build System software development Instructions for working with the system’s source code

17

Instructions for setting up the developing environment

Instructions for building the application’s executables

Coding standards documentation

Build Security audit and code review, analysis and remediation

Security testing and verification results report

Remediation documentation

Recommendations for improvement

Documentation of security-related code, architecture or configuration changes

Build System staging and production deployment System deployment and testing plan

Systems deployment report

Build process and deployment procedures documentation

Data assurance/backup, business continuity, disaster recovery documentation

Build Acceptance testing and verification Acceptance testing definitions

Acceptance testing results

Testing and verification results report

Deploy Training and change management System training manual

Training videos

User adoption summary

Deploy SEA and LEA technical support Implementation report (issues encountered, issues resolved, success of user adoption strategies)

Project Closure Transfer of all assets, systems and procedures necessary for supporting ongoing operations

Project close out report

4.2.1 TECHNICAL STRATEGY

The project will leverage three existing systems that contain data vital to the project. It will create a federated data store that can be accessed through a user interface that provides reports and dashboards.

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

18

requirements of the project.

4.2.2.1 [Solution Design Refinements (Preliminary)]Description -Initial refinements to solution design based on client input and feedback, deeper understanding of requirements gathered in Phase 1, changes in Special Education requirements and leveraging of technology to align to other IT transformation initiatives.

Deliverable Acceptance Criteria -Completion of revisions to written documents corresponding to solution design and completion of preliminary solution design report, as described in section 4.2, Product Life Cycle Deliverables.Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Completed revisions to written documents and completed preliminary solution design report will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance when the work is complete to their satisfaction.

4.2.2.2 [Technical Development, Custom Reporting and Testing]Description -Implement the MOE system using the .NET Platform and Microsoft SQL Server deployed in Windows, including the following components:-Tracking historical MOE data-Fetching data from OBMS and STARS-Uploading spreadsheets and processing their data-Validating data-Performing calculations on stored data-Visualizing data-Creating custom reports for data-Exporting data for use in the MOE Calculator-Designing and implementing user workflow, user experience and user interface-Implementing source control and change management infrastructure

Deliverable Acceptance Criteria -Completion of written documents corresponding to software development and completion of testing and verifications results report, as described in section 4.2, Product Life Cycle Deliverables.

Passes performance tests and data validation tests.

Passes unit and integration tests.

Passes user acceptance tests (UAT).Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Completed written documents and completed testing and verification results report will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance when the work is complete to their satisfaction.

4.2.2.3 [Solution Design Refinements (Final)]Description -Final refinements to solution design based on client input and feedback, deeper understanding of requirements gathered in Phase 1, changes in Special Education requirements and leveraging of technology to align to other IT transformation initiatives.

Deliverable Acceptance Criteria -Completion of revisions to written documents corresponding to solution design and completion of final solution design report, as described in section 4.2, Product Life Cycle Deliverables.Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Completed revisions to written documents and completed final solution design report will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance

19

when the work is complete to their satisfaction.

4.2.2.4 [System Deployment and Testing]Description -Implementation of hardware and network architecture configuration for staging and production servers, implementation of deployment infrastructure, deployment of software releases, execution of manual and automated system tests, establishing procedures for data assurance and backup, business continuity and disaster recovery.

Deliverable Acceptance Criteria -Completion of written documents corresponding to system deployment and testing and completion of deployment and testing verification and results reports, as described in section 4.2, Product Life Cycle Deliverables.Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Completed written documents and completed deployment and testing verification and results reports will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance when the work is complete to their satisfaction.

4.2.2.5 [System Security Testing]Description -Testing of network and firewall penetration, security and penetration testing, testing of application code for vulnerabilities and execution of automated security scans.

Deliverable Acceptance Criteria -Completion of written documents corresponding to system security testing and completion of system testing and verification results report, as described in section 4.2, Product Life Cycle Deliverables.Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Completed written documents and completed security testing and verification results report will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance when the work is complete to their satisfaction.

4.2.2.6 [Administrator/Operator/End-User System Training Manual]Description -Production of a training document for system administrators, operators and end-users.

Deliverable Acceptance Criteria -Completion of written system training manual, as described in section 4.2, Product Life Cycle Deliverables.Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Completed system training manual will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance when the work is complete to their satisfaction.

4.2.2.7 [MOE System User Adoption Plan Implementation]Description -Implementation of user adoption/change management plan described in 4.1.1.2.

Deliverable Acceptance Criteria -Completion of system training videos and written user adoption summary, as described in section 4.2, Product Life Cycle

20

Deliverables.Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Completed system training videos and completed written user adoption summary will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance when the work is complete to their satisfaction.

4.2.2.8 [SEA and LEA Implementation Support]Description -Providing of support to SEA and LEAs in the form of:-Fielding questions, concerns and enhancement requests-Partnering with personnel to troubleshoot and resolve technical issues-Making and deploy code changes as necessary to resolve technical issues-Meeting periodically to review and prioritize issues-Escalating issues (as necessary) to facilitate resolution-Facilitating collection of end-user feedback

Deliverable Acceptance Criteria -Completion of written implementation report, as described in section 4.2, Product Life Cycle Deliverables.Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Completed written implementation report will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance when the work is complete to their satisfaction.

4.2.2.9 [Operating Budget Management System (OBMS) Report Delivery and Software Development Support]

Description -Delivery of 5 reports in OBMS needed for MOE Phase II and meeting regularly with EASOL provide system, process and technical expertise in completion of deliverables 4.2.2.1, 4.2.2.2, 4.2.2.3, 4.2.2.6.

Deliverable Acceptance Criteria -Completion of OMBS reports and completion of written documents corresponding to deliverables 4.2.2.1, 4.2.2.2, 4.2.2.3, 4.2.2.6, as described in section 4.2, Product Life Cycle Deliverables.Standards for Content and Format -EASOL will abide by any format standards set by PED provided at the start of the project. At minimum, EASOL will provide written documentation in digital format.Quality Review -Completed OBMS reports and written documents corresponding to deliverables 4.2.2.1, 4.2.2.2, 4.2.2.3, 4.2.2.6 will be reviewed by the PED CIO and PED Special Education leadership, who will provide written acceptance when the work is complete to their satisfaction.

4.2.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS

DELIVERABLE NUMBER

DELIVERABLE APPROVERS (WHO CAN APPROVE)

DATE APPROVED

All deliverables All deliverables John Kraman21

4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE

Contractors will send digital documentation of deliverable to approver via email and approval authority will provide written acceptance to the Contractor via response to email for the completion of all deliverables.

5.0 PROJECT WORK

5.1 WORK BREAKDOWN STRUCTURE (WBS)

1.1 Initiation 1.1.1 Evaluation & Recommendations1.1.2 Develop Project Charter1.1.3 Deliverable: Submit Project Charter1.1.4 Project Sponsor Reviews Project Charter1.1.5 Project Charter Signed/Approved1.1.6 Project Charter Reviewed/Approved by PCC

1.2 Planning 1.2.1 Create Preliminary Scope Statement1.2.2 Develop Project Plan

1.2.3 Submit Project Plan and Request for Certification and Release of Funds Form

1.2.4 Milestone: Project Plan Approval from PCC1.2.5 Determine Project Team1.2.6 Project Engagement, Use Cases and Process Maps1.2.7 User Interface Requirements Gathering1.2.8 Data Validation Rule Gathering1.2.9 Technical Needs Assessment and user Interface Requirements Gathering1.2.10 Data Mapping and Dashboard Design1.2.11 Bridge Support for Data Processing1.2.12 OBMS Data Mapping

1.3 Execution 1.3.1 Project Kickoff Meeting1.3.2 Verify and Validate User Requirements1.3.3 Ongoing Solution Design Refinements

1.3.4 Design System (s)1.3.5 Deploy System (s)1.3.6 Testing Phase1.3.7 User Training1.3.8 Deploy1.3.9 User Adoption Plan Implementation

22

1.4 Control 1.4.1 Project Management1.4.2 Project Status Meetings1.4.3 Risk Management1.4.4 Update Project Management Plan1.4.5 User Acceptance Testing (UAT)1.4.6 Operational Acceptance Testing (OAT)1.4.7 System Documentation1.4.8 System Training Documentation1.4.9 User Adoption Plan

1.5 Closeout 1.5.1 Gain Formal Acceptance1.5.2 Document Lessons Learned1.5.3 Update Files/Records1.5.4 Complete Project Closeout documents

1.5.5 Present Closeout to PCC 1.5.6 Archive Files/Documents

5.2 SCHEDULE ALLOCATION -PROJECT TIMELINEIdentifier Task/Activity Name Resource

NameMilestone (Y/N)

Effort/ Duration

Start Finish Dependent Task

23

Phase 2Deliverable 1

Project Management N 10 months

Sept Jun


Solution Design Refinements (Preliminary)

Y 2 months Sept Oct


Technical Development, Custom Reporting and Testing

Y 7 months Sept Mar Solution Design Refinements (Preliminary)


Solution Design Refinements (Final)

Y 1 month Mar Mar


System Deployment and Testing (EASOL)

Y 3 months Jan Mar Technical Development, Custom Reporting and Testing


System Security Testing (EASOL)

Y 2 months Mar Apr Technical Development, Custom Reporting and Testing


Administrator/Operator/End-User System Training Manual (EASOL)



LEA Implementation Support (EASOL)



Operating Budget Management System (OBMS) Report Delivery and Software Development Support (RESPEC)

Y 2 months May Jun System Deployment and Testing

Phase 2Deliverable 10(OPTIONAL)

MOE System User Adoption Plan (to be implemented in Optional Deliverable 12) (UPD)

Y


SEA Implementation Support (EASOL)

Y


MOE System User Adoption Implementation (UPD)

Y


Project Closure(EASOL)

24

(OPTIONAL)


Operating Budget Management System (OBMS) Report Implementation Documentation (RESPEC)

5.3 PROJECT BUDGET

Identifier Work Package or Budget Category CostPhase 1 Deliverable 1

Project PED Engagement, Use Cases and Process Maps (UPD) $81,319.27

Phase 1 Deliverable 2

LEA Engagement, Use Cases and Process Maps (UPD) $43,973.44


User Interface Requirements Gathering (UPD) $167,284.09


Data Validation Rule Gathering (UPD) $47,440.71


Technical Needs Assessment and user Interface Requirements Gathering (EASOL) $59,773.06


Data Mapping and Dashboard Design (EASOL) $82,094.06


Bridge Support for Data Processing (EASOL) $69,753.12


Systems Requirements Gathering (RESPEC) $5,365.63


OBMS Data Mapping (RESPEC) $10,731.25


Provide Bridge Support for Data Processing (RESPEC) $16,096.88

Phase 2 Deliverable 1 Project Management (EASOL) $70,000.00

Phase 2 Deliverable 2 Solution Design Refinements (Preliminary) (EASOL) $32,859.33

Phase 2 Deliverable 3 Technical Development, Custom Reporting and Testing (EASOL) $500,000.00

Phase 2 Deliverable 4 Solution Design Refinements (Final) (EASOL) $16,429.67

Phase 2 Deliverable 5 System Deployment and Testing (EASOL) $70,000.00

Phase 2 Deliverable 6 System Security Testing (EASOL) $50,000.00

Phase 2 Deliverable 7 Administrator/Operator/End-User System Training Manual (EASOL) $60,000.00

Phase 2 Deliverable 8 LEA Implementation Support (EASOL) $182,750.00

Phase 2 Deliverable Operating Budget Management System (OBMS) Report Delivery and Software $49,101.95

25

9 Development Support (RESPEC)

Phase 2 Deliverable 10 (OPTIONAL)

MOE System User Adoption Plan (to be implemented in Optional Deliverable 12) (UPD) $51,600.00


SEA Implementation Support (EASOL) $17,200.00


MOE System User Adoption Implementation (UPD) $74,175.00


Project Closure (EASOL) $15,050.00

Phase 2 Deliverable14 (OPTIONAL)

Operating Budget Management System (OBMS) Report Implementation Documentation $7,901.25

IV&V Independent Verification and Validation $64,987.51

5.4 PROJECT TEAM

5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE

5.4.2 PROJECT TEAM ROLES AND RESPONSIBILITIES

ROLE RESPONSIBILITY NAME FUNCTIONAL AREA

UPD Account ExecutiveManage the New Mexico PED Account

Patrick Cook User adoption/change management

UPD Project Manager Manage the User Adoption to work to ensure it is on time, on budget,

Ann Willemssen User adoption/change

26

Patrick Cook Project Executive

UPD

Philip HeimesProject Executive

EASOL

Special Education

Bureau Program Manager

Ann Williamson Project Manager

Sonya LopesProject Manager

John KramanCIO

and of high quality management

EASOL Lead Manage client relationship and communication for New Mexico PED Account

Philip Heimes All

EASOL Project Executive

Product Management team Sonya Lopes All

EASOL Project Coordinator

Product Management team Angela Martin All

EASOL Technical Product Manager

Product Management team Tim Bickerton Technical implementation

EASOL Technical Developer

Member of Engineering team Anderson Cardoso Technical implementation


Member of Engineering team TBD Technical implementation


Member of Engineering team TBD Technical implementation

EASOL Technical Architect

Provide leadership on design and development of technical solution

Romulo Saksida Technical implementation

EASOL Executive Oversight

Provide project oversight to ensure alignment to other NM projects

Stephen Midgley Accountability

EASOL Technical Oversight

Provide technical development oversight

Jim Wrubel Technical implementation

EASOL Testing Engineer

Design and implement system testing

TBD Testing/QA

EASOL LEA Support Engineer

SEA/LEA technical support liaison TBD SEA/LEA implementation support

EASOL Technical Documentation

Document and produce technical and training documentation

Derek Carlson Documentation/acceptance testing

EASOL IT/DevOps Engineer

Design and develop infrastructure TBD Technical implementation

5.5 STAFF PLANNING AND RESOURCE ACQUISITION

5.5.1 PROJECT STAFF

ResourceCost Estimate

Estimated Hours Availability Skill Set Work Product/Deliverable

EASOL Lead $37,459 150 PT Technical project management

Technical deliverables

EASOL Project Executive $50,099 200 PT Technical project management

Management and technical deliverables

27

EASOL Project Coordinator

$49,460 300 PT Technical project management


EASOL Technical Product Manager

$99,962 800 FTE Technical project management


EASOL Technical Developer (x3)

$508,424 4133 FTE S/W Engineering, architecture, and testing


EASOL Technical Architect

$55,311 369 PT S/W architecture and technical management


EASOL Executive Oversight


Project management deliverables

EASOL Technical Oversight



EASOL Testing Engineer $54,993 500 FTE S/W testing Technical deliverables

EASOL LEA Support Engineer

$51,920 371 FTE S/W user supportTechnical deliverables

EASOL Technical Documentation

$30,728 279 PT Technical writing

Technical documentation deliverables

EASOL IT/DevOps Engineer

$43,444 362 PT IT infrastructure Technical deliverables

UPD Account Executive $4,680 21 PT Project Management


UPD Project Manager $23,400 142 PT Project Management


UPD Senior Consultant $40,950 282 PT User Adoption Strategies, Camtasia, Writing for diverse technical abilities

MOE System User Adoption Plan

MOE System User Adoption Plan Implementation

UPD Consultant $40,950 303 PT User adoption MOE System User Adoption

28

strategies, Camtasia, Writing for diverse technical abilities

Plan

MOE System User Adoption Plan Implementation

29

5.5.2 NON-PERSONNEL RESOURCES

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

ResourceCost Estimate

Estimated units/hours Availability Source Work Product/Deliverable

Development server infrastructure

0 (State provided)

4 units Entire project PED Development, testing, and source control

Staging and production server infrastructure

0 (State provided)

2 units Deployment and acceptance testing

PED deployment

Database services 0 (State provided)

3 units Entire project PED data based deliverables of the project

SharePoint Already purchased

2080 hours Available now Microsoft Project Management

Team Foundation Server Already purchased

2080 hours Available now Microsoft Development, deployment, testing, and source control

5.6 PROJECT LOGISTICSThe vendor/consulting lead works in the PED IT office daily. All vendor teams who work remotely interact and communication on a daily basis with the vendor lead and project executive who communicate with the project owner (John Kraman) and project manager (Kathryn Cleary) on a daily basis to ensure timely ongoing communication. The consultant team schedules are flexible to meet the project’s needs.

5.6.1 PROJECT TEAM TRAINING

Project team members are not in need of training.

6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT

6.1.1 RISK MANAGEMENT STRATEGY

The Project Plan will be entered into Microsoft Project and monitored weekly for issues/risks. The work entered into Team Foundation Server will also align to the risk matrix. The following table will be used to rate the issue/risk. The weekly project report will include the risk identification schema as shown below.

30

6.1.2 PROJECT RISK IDENTIFICATION

Risk Description Impact Levels:VeryHigh High Medium Low

VeryLow

Probability Levels: 1 2 3 4 5Certain

1Expected

2Likely

3Possible

4Unlikely

5

Initial identified project risks are outlined in 1.6 of this document.

6.1.3 PROJECT RISK MITIGATION APPROACH

Daily stand-ups will identify risk early. They will be a key part of sprint planning, bi-weekly project meetings, and project communication plans.

6.1.4 RISK REPORTING AND ESCALATION STRATEGY

Risks will be identified by staff close to the work, logged and prioritized in a risk registry, owned by the Project Manager. Risk will be escalated as necessary to John Kraman, CIO and Philip Heimes (EASOL) for further direction.

6.1.5 PROJECT RISK TRACKING APPROACH

Risks will be a part of the project documentation in Microsoft Project, TFS and the SharePoint Project Site.

6.1.6 ISSUE MANAGEMENT

6.1.6.1 Internal Issue Escalation and Resolution Process

Internal Issues will be identified, logged, monitored and resolved using the same techniques described above in 6.1.3.

6.1.6.2 External Issue Escalation and Resolution Process

External Issues will be identified by the LEA Advisory Committee and logged, monitored and resolved. The stakeholders meeting and the communication artifacts for these meetings will document the external issues.

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V31

PED selected Burger, Carroll & Associates, Inc. to provide IV &V for this project. A contract has been created in the amount of $64,987.51 inclusive of GRT.

6.3 SCOPE MANAGEMENT PLAN

The scope baseline is finalized and will be managed. Any requested changes to the scope will be requested via the change management process. The Change Management approach consists of three areas:● Ensure changes are within scope and are beneficial to the project● Determine how the change will be implemented● Manage the change as it is implementedBy using this approach methodology, the Project Team will prevent unnecessary change from occurring and focus its resources only on beneficial changes within the project scope.

6.3.1 CHANGE CONTROL

6.3.1.1 Change Control ProcessThe Change Control Process for the MOE Project will follow the organizational standard change process for all projects. Types of changes include:● Scheduling Changes: changes which will impact the approved project schedule. ● Budget Changes: changes which will impact the approved project budget. ● Scope Changes: changes which impact the project’s scope and may also impact budget and

schedule. They may be the result of unforeseen requirements which were not initially planned for. These changes may require revision to WBS, project scope statement, and other project documentation as necessary.

The project manager has overall responsibility for executing the change management process for each change request.

1. Identify the need for a change (Stakeholders) – Change requestor will submit a completed change request form to the project manager.

2. Log change in the change request register (Project Manager) in SharePoint Team Site– The project manager will keep a log of all submitted change requests throughout the project’s lifecycle.

3. Evaluate the change (Project Manager, Team, and Requestor) – The project manager will conduct a preliminary analysis on the impact of the change to risk, cost, schedule, and scope and seek clarification from team members and the change requestor.

4. Submit change request to Change Control Board (CCB) (Project Manager) – The project manager will submit the change request, as well as the preliminary analysis, to the CCB for review.

5. Obtain Decision on change request (CCB) – The CCB will discuss the proposed change and decide whether or not it will be approved based on all submitted information.

6. Implement change (Project Manager) – If a change is approved by the CCB, the project manager will update and re-baseline project documentation as necessary.

32

6.3.1.2 Change Control Board (CCB)Change Control: Any proposed changes in project requirements must be carefully considered before approval and implementation. Such changes are likely to impact project scope, time, and/or cost, perhaps significantly. Any proposed changes to project requirements will be reviewed by the CCB. The role of the CCB is to determine the impact of the proposed change on the project, seek clarification on proposed change, and ensure any approved changes are added to the Project Plan and subsidiary documents such as the Work Breakdown Schedule. The project sponsor, who also sits on the CCB, is responsible for approving any changes in project scope, time, or cost and is an integral part of the change review and approval process.

6.4 PROJECT BUDGET MANAGEMENT

6.4.1 BUDGET TRACKING

The budget will be tracked within project management tools employed by this project. Expenditures and estimates will be included in monthly reports to DoIT.

6.5 COMMUNICATION PLAN

6.5.1 COMMUNICATION MATRIX

Type Objective of Communication

Medium Frequency Audience Owner Deliverable Format

Kickoff Meeting

Introduce the project team and the project. Review project objectives and management approach.

-Face-to-face Once -Project sponsor-Project teamstakeholders

Project Manager

-Agenda-Meeting minutes

Soft copy archived on project SharePoint site and project web site

Project Team Meetings

Review status of the project with the team.

-Face-to-face-Conference call Weekly -Project team

steering committee-PMO-CIO

Project Manager



Steering Committee Meetings

To inform and guide the work of the project.

-Face-to-face-Conference call Bi-Monthly -Leadership team

-Executive team-CIO




Technical Design Meetings

Discuss and develop technical design solutions for the project.

-Face-to-face As Needed -Project technical staff Technical

Lead

-Agenda-Meeting minutes


Bi-Monthly Report on the status of -Face-to-face-Conference call Bi-Monthly -PMO Project -Slide updates

-Project scheduleSoft copy archived on 33

Project Status Meetings

the project to management.

Manager or CIO

project SharePoint site and project web site

Project Status Reports

Report the status of the project including activities, progress, costs and issues.

-Word and MS Project Reports Monthly -Project sponsor

-Project teamstakeholders-PMO


-Project status report-Project schedule


6.5.2 STATUS MEETINGS

Please refer to the Communication Matrix

6.5.3 PROJECT STATUS REPORTS

Please refer to the Communication Matrix

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)6.6.1 BASELINES

Project Area Category Measure

Implementation cost Return on Investment Net Benefits/Costs X 100

Implementation cost Productivity “Productivity Ratio” output produced per unit of input

Implementation cost Cost of QualityCost of Quality/Actual Cost

Implementation time Schedule PerformanceThe Schedule Performance Index is the ratio of total original authorized duration versus total final project duration.

Implementation quality Customer SatisfactionScale of 1-100Customer satisfaction means that customer expectations are met. This metric includes conformance to requirements as well as fitness for use.

Implementation quality Requirements PerformanceA requirements performance index can measure the degree to which project results meet requirements.

Implementation quality Alignment to Strategic Business GoalsLikert scale from 1-5 to rate the statement: Projects are aligned with the business’s strategic objectives.

6.6.2 METRICS LIBRARY Metrics will be included in SharePoint MOE Team Site.

34

6.7 QUALITY OBJECTIVES AND CONTROL6.7.1 QUALITY STANDARDS

No. Quality Standard Tracking Tool or Measure

1 OSEP MOE Compliant OSEP2 System Interoperability Data Validation Reports3 Project phase is completed by the established finish date. Project Schedule

Project Status4 Project is completed within budget. Project Charter

Project Status5 Project attains a 90% or greater rating for customer satisfaction. User stories, requirements

documents, user acceptance testing, and surveys

6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTSReview Type Quality Standard Tools Reviewer ReportsRequirements Accepted and

approved by executive team, project sponsor, and program manager.

SharePoint and TFS John Kraman Team Foundation Server (TFS) Reports

Plans Accepted and approved by executive team, project sponsor, and program manager

SharePoint and TFS John Kraman SharePoint

Milestones Completed by anticipated deadline

SharePoint and TFS John Kraman and PCCTFS Sprint ReportsDoIT monthly project reports

Testing Meet user requirements

TFS Users (LEA Advisory Committee and SEB)

TFS Test reports

6.7.3 AGENCY/CUSTOMER SATISFACTION

Areas of Feedback When How Often

Agency awareness At the monthly PED Executive Team Meeting, once every quarter starting in July.

Quarterly

Quality of communications At the monthly LEA Stakeholders meeting/conference call and Once a month during the bi-weekly team meeting.

Monthly

Manages project tasks Once a month during the bi-weekly team meeting.

Monthly

35

Productive Meetings At the monthly LEA Stakeholders meeting/conference call and Once a month during the bi-weekly team meeting.

Monthly

36

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS

Deliverable Final Approval Process Customer Acceptance CriteriaAll project deliverables Written acceptance by John

Kraman and Special Education Bureau Chief.

Varies by deliverable but could include OAT and UAT, functional and performance requirements, customer satisfaction, alignment to strategic objectives, and return on investment.

6.8 CONFIGURATION MANAGEMENTProject information, artifacts and deliverables - such as requirements documents, project plans, timelines, testing plans, agendas, meeting notes, status reports - will be housed on the SharePoint Team site, owned by the Project Manager. SharePoint automatically versions documents through its embedded version control system. All team members will be driven to the SharePoint site in order to ascertain project status and obtain the most current versions of all project inputs.

6.8.1 VERSION CONTROL

We will follow standard project management practice with regards to version control of code and documents. The use of Team Foundation Server (TFS) 2015 will serve as a code repository as well as a resource and time management tool. With TFS 2015 the project will create a linked SharePoint Project Site allowing for a document library, communication forum, wiki, calendar, and task management system.

6.8.2 PROJECT REPOSITORY (PROJECT LIBRARY)The project repository is SharePoint. All documents related to the project will be made available to project stakeholders based on their role and level.

6.9 PROCUREMENT MANAGEMENT PLANIn the procurement of the vendors to deliver the scope of work, PED has followed the State of New Mexico procurement processes.

7. 0 PROJECT CLOSE7.1 ADMINISTRATIVE CLOSE

Throughout the project as phases are completed the project team will complete administrative closure activities such as, lessons learned, impact and implications of phase, and transition to operations.

37

7.2 CONTRACT CLOSE

PED will complete all administrative activities prior to the contract’s close in order to complete and report to the PCC in accordance with their policy and process.

ATTACHMENTS● Project timeline

38

ATTACHMENT: PROJECT TIMELINE

Deliverables and Tasks Sept2017

Oct2017

Nov2017

Dec 2017

Jan2018

Feb2018

Mar2018

Apr2018

May 2018

June2018

Project Management - Managing project planning, requirements, deliverables, acceptance, testing, training, transition to operations

OBMS software development support

Design Phase:

Solution design refinements:-Detailed review of Phase I deliverables-Incorporate refinements to technical requirements and design

Build Phase:

Establish and maintain ETL to support user data submission

Establish and maintain ETL to support source data integration

Establish and maintain ETL job status reporting and exception real-time alerting

Implement custom reporting and output interfaces

Implement data validation rules engine and exception reporting interfaces

Implement user workflow design, user experience design and user interface

Implement source control and change management infrastructure

39

Test Phase:

Test data development test harness implementation

Test and validate data imports and exports from data sources

Test performance of data transfer and user loads

Test security and penetration

Test data assurance, application, backup and recovery strategies

Deployment Phase:

Hardware and network architecture configuration, production and staging deployment

LEA implementation support

System training manual

40