share software selection - e… · web view23/07/2008 · project management plan. executive...

EDUCATION USER INTERFACEPROJECT MANAGEMENT PLAN

Executive SponsorsPublic Education DepartmentProject Director – Robert Piro

Original Plan Date: July 25, 2007Revision Date:

Revision:

Education User Interface (EdUI) Project Management Plan

TABLETABLE OFOF CONTENTSCONTENTS

About this DocumentAbout this Document............................................................................................................................................................................................................ iiiiiiRevision HistoryRevision History.......................................................................................................................................................................................................................... iviv1.01.0 Project OverviewProject Overview...................................................................................................................................................................................................... 551.11.1 IINTRODUCTIONNTRODUCTION..............................................................................................................................................................................................................................................551.21.2 CCURRENTURRENT S STATETATE......................................................................................................................................................................................................................................551.31.3 FFUTUREUTURE S STATETATE............................................................................................................................................................................................................................................551.41.4 NNEEDEED........................................................................................................................................................................................................................................................................66

2.02.0 EdUI ScopeEdUI Scope........................................................................................................................................................................................................................ 662.12.1 PPROJECTROJECT J JUSTIFICATIONUSTIFICATION................................................................................................................................................................................................................662.22.2 PPROJECTROJECT O OBJECTIVESBJECTIVES......................................................................................................................................................................................................................882.32.3 DDELIVERABLESELIVERABLES............................................................................................................................................................................................................................................882.42.4 WWORKORK B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE (WBS) (WBS)..........................................................................................................................................................1313

3.03.0 EdUI StrategyEdUI Strategy.............................................................................................................................................................................................................. 14143.13.1 PPROJECTROJECT M MANAGEMENTANAGEMENT L LIFEIFE C CYCLEYCLE......................................................................................................................................................................14143.23.2 CCRITICALRITICAL S SUCCESSUCCESS F FACTORSACTORS............................................................................................................................................................................................14143.33.3 PPROJECTROJECT L LOGISTICSOGISTICS........................................................................................................................................................................................................................15153.43.4 PPROJECTROJECT P PRODUCTRODUCT L LIFEIFE C CYCLEYCLE....................................................................................................................................................................................15153.53.5 TTECHNICALECHNICAL S STRATEGYTRATEGY..................................................................................................................................................................................................................1515

4.04.0 Project OrganizationProject Organization...................................................................................................................................................................................... 16164.14.1 4.1 S4.1 STAKEHOLDERSTAKEHOLDERS..........................................................................................................................................................................................................................16164.24.2 CCUSTOMERSUSTOMERS................................................................................................................................................................................................................................................16164.34.3 PPROJECTROJECT T TEAMEAM......................................................................................................................................................................................................................................17174.44.4 PPROJECTROJECT G GOVERNANCEOVERNANCE P PLANLAN..........................................................................................................................................................................................2020

5.05.0 Project Management and ControlsProject Management and Controls........................................................................................................................................21215.15.1 SSTAFFINGTAFFING P PLANNINGLANNING ANDAND A ACQUISITIONCQUISITION................................................................................................................................................................21215.25.2 AASSUMPTIONSSSUMPTIONS..........................................................................................................................................................................................................................................21215.35.3 CCONSTRAINTSONSTRAINTS............................................................................................................................................................................................................................................22225.45.4 DDEPENDENCIESEPENDENCIES........................................................................................................................................................................................................................................22225.55.5 RRISKISK M MANAGEMENTANAGEMENT..........................................................................................................................................................................................................................23235.65.6 IINDEPENDENTNDEPENDENT VALIDATIONVALIDATION ANDAND V VERIFICATIONERIFICATION (IV&V) (IV&V)......................................................................................................................25255.75.7 SSCOPECOPE M MANAGEMENTANAGEMENT P PLANLAN................................................................................................................................................................................................27275.85.8 IISSUESSUE M MANAGEMENTANAGEMENT........................................................................................................................................................................................................................27275.95.9 PPROCUREMENTROCUREMENT M MANAGEMENTANAGEMENT P PLANLAN........................................................................................................................................................................3030

Initial Release i July 25, 2008

Education User Interface (EdUI) Project Management Plan5.105.10 CCHANGEHANGE C CONTROLONTROL............................................................................................................................................................................................................................30305.115.11 PPROJECTROJECT T TIMELINEIMELINE............................................................................................................................................................................................................................32325.125.12 PPROJECTROJECT B BUDGETUDGET..............................................................................................................................................................................................................................33335.135.13 CCOMMUNICATIONSOMMUNICATIONS..............................................................................................................................................................................................................................33335.145.14 MMEASURINGEASURING ANDAND E EVALUATINGVALUATING P PERFORMANCEERFORMANCE..........................................................................................................................................36365.155.15 CCORRECTIVEORRECTIVE A ACTIONCTION P PLANLAN....................................................................................................................................................................................................36365.165.16 QQUALITYUALITY O OBJECTIVESBJECTIVES ANDAND C CONTROLONTROL......................................................................................................................................................................38385.175.17 CCONFIGURATIONONFIGURATION M MANAGEMENTANAGEMENT........................................................................................................................................................................................3939

6.06.0 Project CloseProject Close.............................................................................................................................................................................................................. 39396.16.1 AADMINISTRATIVEDMINISTRATIVE C CLOSELOSE............................................................................................................................................................................................................39396.26.2 FFINANCIALINANCIAL C CLOSURELOSURE......................................................................................................................................................................................................................42426.36.3 CCELEBRATIONELEBRATION OFOF S SUCCESSUCCESS..................................................................................................................................................................................................44446.46.4 PPROJECTROJECT C CLOSELOSE--OUTOUT C CHECKLISTHECKLIST................................................................................................................................................................................4545

7.07.0 GlossaryGlossary.............................................................................................................................................................................................................................. 45457.17.1 AACRONYMSCRONYMS ANDAND A ABBREVIATIONSBBREVIATIONS..................................................................................................................................................................................45457.27.2 DDEFINITIONSEFINITIONS................................................................................................................................................................................................................................................4646

8.08.0 AppendixAppendix............................................................................................................................................................................................................................ 5050AAPPENDIXPPENDIX 8.1 D 8.1 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE F FORMORM........................................................................................................................................................5151AAPPENDIXPPENDIX 8.2 P 8.2 PROJECTROJECT S SCHEDULECHEDULE..................................................................................................................................................................................................5353AAPPENDIXPPENDIX 8.3 C 8.3 CHANGEHANGE R REQUESTEQUEST F FORMORM....................................................................................................................................................................................5454AAPPENDIXPPENDIX 8.4 P 8.4 PROJECTROJECT C CLOSELOSE--OUTOUT C CHECKLISTHECKLIST............................................................................................................................................................5555

Initial Release ii July 25, 2008


AABOUTBOUT THISTHIS D DOCUMENTOCUMENT

The New Mexico Office of the Chief Information Officer has elected to align its program management development efforts with the Project Management Institute (PMI). The PMI is symbolized by a sum of knowledge within the project management profession known as the Project Management Body of Knowledge (PMBOK). The body of knowledge includes best practices and standards that are generally accepted. The need to align with an established institution is to gain a common approach to project management. That is not to assume that the described approach herein should be uniformly applied across all projects. The described practices and standards are applicable to most projects most of the time, and there is widespread consensus about their value and usefulness.

This document provides a guideline to initiate, plan, execute, control, and close a project. The approach, concepts, tools, and terminology used within this document are in accordance with the Project Management Institute and the Project Management Body of Knowledge.

Initial Release iii July 25, 2008


RREVISIONEVISION H HISTORYISTORY

Revision Number Date Comment

July 25, 2007 Initial Release

Initial Release iv July 25, 2008


1.01.0 PPROJECTROJECT O OVERVIEWVERVIEW

1.11.1 IINTRODUCTIONNTRODUCTIONNMPED was charged to develop clear, concise, consistent guidelines, procedures, and protocols for the collection, verification, analysis, dissemination, and communication of all data collected, and used by the agency as well as that related data and information requested by outside entities. Following the CCSSO/DSAC recommendations, NMPED selected an e-Scholar based data warehouse and Cognos based decision support tool set. Following the evaluation and selection of the e-Scholar/Cognos based solution, an operational prototype of STARS was developed, reviewed and approved to validate the concept of the STARS design. Following the acceptance of the operational prototype, NMPED further developed the STARS design through a district based pilot program. 11 districts, representing the vast array of districts within New Mexico, volunteered to participate in the STARS Pilot Program. On May 30, 2006, the STARS team, with agreement with the participating pilot districts determined that the objectives of the Pilot phase were successfully completed. Of the 11 districts, 10 were able to complete the activities and objectives of the pilot. Pilot activities have progressed so well, that several districts, both pilot and non-pilot, have elected to commence the implementation activities of the project.

STARS development and roll-out is complete in SY2007. For SY2007 and SY2008 districts submitted their data for 40th, 80th, 12/1, 120th and EOY via STARS. All student and staff reporting comes directly from STARS data utilizing STARS Decision Support Tools. AYP was reported through STARS, School Budget utilized STARS to compute their 40th day Growth calculation for SEG. School Budget utilized STARS to calculate the SY2008 budget projects from 80th and 120th data. Educator Quality calculated and report Highly Qualified Teacher utilizing STARS. Federally required data has been submitted to EdFacts utilizing the STARS Eden Functionality. Special Education’s performance indicators are being calculated and reported utilizing STARS.

In short, STARS is fully operational. After only 24 months, from concept through implementation, to collecting a full year of Student, Staff, and Financial data, New Mexico Public Education Department has been recognized as having one of the nation’s leading accountability data systems.

1.21.2 CCURRENTURRENT S STATETATEAfter a successful implementation of Phases 1 and 2, the New Mexico Public Education Department (NMPED) is prepared to move to Phase 3 of its STARS Project Plan. The emphasis of this project is focus on interfaces and support at the LEA level. This project will extend STARS to allow access to disaggregated educational data to District and School decision makers. This project will finalize the development and implementation of the NMPED Education User Interface (EdUI). EdUI will implement a data management environment that provides: 1.) the end user with quality information (reports and data), 2.) Build the framework for PED support staffs the ability to be responsive without the need to create one-of-a-kind applications and reports, and 3) Provide 7 X 24 system availability and scalability to meet future demands.

With the implementation of STARS, the demand for timely and current information (versus data) has become a reality. This new capability has stretched the PED IT Infrastructure and Services to the limits of its capacity. The need for immediate information has moved PED from a traditional ‘batch/legacy’ set of systems into the ‘on demand’ environment. PED now has the task to be responsive to the dynamic needs of the agency and to the needs of 900+ schools (and districts). This creates more demand on PED systems compared to the current support of 89 school districts. To support the Education Reform Strategy, PED requires better data quality and improved access to the information this data represents. Also, the increasing requirement to associate funding to specific programs and their outcomes requires that PED institute processes and procedures that will allow New Mexico to get a better handle on expenditures.

With last year’s appropriations NMPED was able to develop the proof of concept for the NMPED Education User Interface to provide PED and districts with the tools to communicate, collaborate, and mange content and data across the state.

1.31.3 FFUTUREUTURE S STATETATENMPED has successfully deployed the STARS data warehouse. The collection, validation and reporting model is the first major step towards being able to utilize data both at the state and district levels. The roll out

Initial Release 5 July 25, 2008


of the NMPED Education User Interface will allow access to key users to make quality decisions through the use of information. Key customer needs that will be addressed in EdUI of this project are outlined below.

EdUI will feature a powerful and actionable means with which to examine present and apply data. EdUI will enable easier compliance with district and school reporting through enhanced tools and

processes for reporting and decision making. EdUI will further train key stakeholders on effective ad-hoc reporting and data query techniques. EdUI will position the State to include Pre-K and post secondary student data into STARS EdUI will enable districts to make standards-aligned benchmark testing an integral part of the data

warehouse. EdUI will provide a framework to integrate curriculum and instruction and diagnostic data from

ongoing assessments to help curriculum and instruction leaders, as well as teachers, influence student performance

Widespread adoption, along with consistent use of “best practices,” is the critical key to tapping the true power of STARS. EdUI will develop the framework to incorporate end-to-end professional development services to facilitate these objectives.

EdUI will provide the framework to apply to tools to create a “connected learning community” - an engaged and flourishing community across all PED stakeholders.

EdUI will offer a powerful collaboration and communications solution.

Fulfilling these needs will help meet the guidelines of the State of New Mexico’s IT architectural plan and infrastructure plan while following the Framework for Enterprise Architecture. With improved data and information systems, PED is positioned to be able to supply the information and agility required for prompt, informed decision making. As PED continues to provide a leadership role by providing ‘decision making information’ to accomplish its strategy to improve the quality of education and to close the ‘achievement gap’, the legacy PED IT environment requires a reduction of complexity of our electronic systems (consolidate data bases, improve response time, create a simple & secure sign on process, manage financial data better, and provide high customer response to enhance customer service and improve satisfaction) to provide the 7x24 services needed.

1.41.4 NNEEDEEDWith the availability of a District’s Student, Staff, and Financial data all resident in one system and readily accessible, districts have an unprecedented ability to access and utilize the data to enhance student and staff performance. Many districts, however, do not have the capability to effectively access and utilize the data. With this project PED will develop the tools necessary to provide additional support to such districts and allow them same opportunity to improve student performance through use of data, than larger urban districts.

2.02.0 EEDDUI SUI SCOPECOPE

2.12.1 PPROJECTROJECT J JUSTIFICATIONUSTIFICATIONAs detailed in previous Project Plans, the justification of STARS was to adhere to federal requirements. To meet these requirements the New Mexico legislature appropriated State funds to develop, pilot, and implement STARS. Phase 0 executed the design, procure, and prototype activities of the project. Due to the results of the procurement activities, the selected solution will allow us to implement not only Phase 1, but most of Phase 2 also. Results of the Pilot program, allowed STARS to implement the proposed solution. STARS has now completed

The main objective for this project is to provide district’s users with an easy-to-use interface to access disaggregated student information which can be utilized to improve instruction and student achievement. EdUI will develop the framework and deliverer mechanism for a comprehensive web-based program interface that enables users to create reports, manage curriculum, administer benchmark assessments, track teacher professional development, manage district website content and provide access to individual student performance data. The system functionality will be supported solely by the STARS data warehouse and will be uniformly configured to support all districts.

EdUI further develops the agency’s goals and objectives as defined in the initial STARS Project Plan where New Mexico recognizes the need to develop a system that:



Meets requirements of Federal and State Law Addresses Concerns/Directives of the Legislature Capitalizes/Builds on existing and future technologies Ensures cost effectiveness and accountability Emphasizes student performance Ensures the validity, reliability, and reportability of respective data sets Presents information in a meaningful way to clients, and Is easy to use

STARS Phase Three was targeted to emphasize interfaces and support at the school level. Disaggregated data compared within the district would provide information that improves teaching and learning through the identification and support of highly qualified teachers, identifies best practices across school types and student needs, promotes individualized instruction, and allows for site based decision making. At the end of Phase Three, it was anticipated that principals and teachers would have comparative state district, and school data to identify best practices to assist with student instruction and site management. Unfortunately Phase 3 was not fully funded. The funding for FY2009 was reduced from the $7,300,000 to $1,200,000. Therefore the design, functionality, and roll-out strategies designed during the EdUI Proof of Concept development have been revise to fit the reduced funding. The following table discusses the revised strategies:

Primary Strategy Requested Funding Existing Funding Impact to State

EdUI Content District relevant data, including Instructional Management data including Short Cycle Assessments, curriculum, other district relevant data

Existing STARS Data Data will not be available to be delivered to teacher desktop

Development Design, programming, testing, and training led and primarily executed via contractors

Design, programming, testing, and training primarily executed by PED staff utilizing contractors only in a staff augmentation and coaching role.

Reduced expertise in specific portal skills increase timeline.

Roll-out Vertical development including all districts rolls and responsibility, i.e. all responsibility within a district.

Horizontal development including tasks for assigned rolls, i.e. Data Coordinator, PED Programs.

Data access limited to specific rolls.

This project will divide the funds appropriated into three major components:

2.1.12.1.1 MMAINTENANCEAINTENANCE, L, LICENSEICENSE, , ANDAND H HOSTINGOSTING C CONTRACTINGONTRACTING

During the FY2008 Appropriation Cycle NMPED requested operational budget to fund the annual maintenance, license, and hosting fees for STARS. These funds were transferred from capital to operations. The fees associated with this transfer are approximately $900,000. Although these funds do not require certification, the contract vehicle that allows for the billing of these fees expires in December of 2009. NMPED requires a new contract vehicle for the procurement of these line items. It is NMPED’s intent to include a new procurement activity within the scope of this project to allow continuation of operations after the December 2009 date.

2.1.22.1.2 EEDUCATIONALDUCATIONAL I INTERFACENTERFACE

A majority of the FY2008 appropriation will be used to provide support to further develop the tools, reports and training necessary to assist users to fully optimize their use of STARS. Support will include:

Further development of the Statewide Education User Interface to provide PED and districts with the tools to communicate, collaborate, and mange content and data across the state.



Develop and implement the EdUI security and user provisioning. As STARS data is accessible by more and more users, access control will be a major component of the NMPED security strategy. EdUI security and user provisioning will develop and implement a plan to mange the access to confidential student, staff and financial data.

Also in the FY2009 Appropriation Cycle NMPED will transfer two of the four term employees that were designated in HB2 for STARS development into a NMPED operational support position. A portion of the appropriation will be used to fund the remaining two term position as internal project support.

2.1.32.1.3 EENHANCEDNHANCED D DATAATA C COLLECTIONOLLECTION ANDAND R REPORTINGEPORTING

The remaining portion of the appropriation will be used to provide support to further develop the tools, reports and training necessary to assist users to fully optimize their use of STARS. Support will include:

Improved data quality tools and processes The automation of manual data review and approval processes, such s the Case Load Waiver

Report. The development of cross year comparison data review reports and processes

Training will continue to include specific district level training related to how to better access and evaluate the existing aggregated and disaggregated data now available to the districts. Users now have direct access to the student, teacher, financial, and facility data necessary to better evaluate the student progress. Training is required to assist district and school personnel to access and interpret the available data.

2.22.2 PPROJECTROJECT O OBJECTIVESBJECTIVES

2.2.12.2.1 BBUSINESSUSINESS O OBJECTIVESBJECTIVES

The goals and objectives of the EdUI Project are: Provide a user friendly portal environment that key users can utilize to access STARS data. Develop new tools, routines, and training to enhance support of individual districts and charter

schools through the 40th, 80th, 120th, and end of year submission of district specific data into STARS. Develop new tools to improve the data quality of districts submissions without adding increased

burden to district level off effort. Improve and increase the method of delivery for STARS training to all user groups Include portal functionality that enables all users to take advantage of streamlined processes,

collaboration and knowledge sharing

2.2.22.2.2 TTECHNICALECHNICAL O OBJECTIVESBJECTIVES

Utilize existing IT assets Modify the existing EdUI Proof of Concept to reflect the change to the original development and

roll-out strategy Establish a development environment to positions NMPED to be able to further develop and

maintain EdUI into the future. Implement the EdUI Security and User Provisioning Model Establish an integrated platform for all applications throughout the state of New Mexico Provide a standardized user experience and look and feel Supply Integrate security and enable user groups to be managed through one, centralized,

Identity management system Provide one central point of access (i.e. http://www.nmped.gov)

2.32.3 DDELIVERABLESELIVERABLES

2.3.12.3.1 PPROJECTROJECT M MANAGEMENTANAGEMENT D DELIVERABLESELIVERABLES

2.3.1.1 EDUI PD001 – EDUI PROJECT CHARTER


http://www.nmped.gov/


Description – The Project Charter for Certification sets the overall scope for the project, the governance structure, and when signed, is considered permission to proceed with the project. The Certification is used to provide the Project Certification Committee with adequate knowledge of the project and its planning to certify the project initiation.

Deliverable Acceptance Criteria – This document will be considered acceptable when it has met the approvals of the NMPED’s Project Director.

Standards for Content and Format – All electronic documents will be created in either Adobe PDF or one of the Microsoft Office products (Word, Excel, PowerPoint, Visio, Project, or Access).

Quality Review – This plan is to be reviewed and maintained by NMPED’s Project Manager, and the consulting partner’s Project Executive.

2.3.1.2 EDUI PD002 – EDUI PROJECT PLAN

Description – This document will serve as the initial Project Plan for the project. After release this project plan will serve to monitor the status of project progress.


Standards for Content and Format – All electronic documents in the Project Plan will be created in either Adobe PDF or one of the Microsoft Office products (Word, Excel, PowerPoint, Visio, Project, or Access).

Quality Review – This plan is to be reviewed and maintained by NMPED’s Project Manager, and the consulting partner’s Project Executive. In addition, the IV&V Contractor will have review responsibilities.

2.3.1.3 EDUI PD003 – IV&V CONTRACT & REPORTS

Description – IV&V provides assessment reporting at pre-defined checkpoints. The Department requires all projects subject to oversight to engage an independent verification and validation contractor unless waived by the Department.



Quality Review – This plan is to be reviewed and maintained by NMPED’s Project Manager, and the consulting partner’s Project Executive.

2.3.1.4 EDUI PD004 – EDUI PROJECT SCHEDULE

Description – A tool used to indicate the planned dates, dependencies, and assigned resources for performing activities and for meeting milestones.


Standards for Content and Format – All electronic documents in the Project Schedule will be created in Microsoft Project.

Quality Review – This plan is to be reviewed and maintained by NMPED’s Project Manager, and the consulting partner’s Project Executive. In addition, the IV&V Contractor will have review responsibilities.



2.3.1.5 EDUI PD005 – EDUI MONTHLY PROJECT STATUS REPORTS

Description – PED will provide project status reports that require Department oversight. The lead agency project manager shall submit an agency approved project status report on a monthly basis to the Department.



Quality Review – Project Status Reports are to be reviewed and maintained by NMPED’s Project Manager. In addition, the IV&V Contractor will have review responsibilities.

2.3.22.3.2 PPRODUCTRODUCT D DELIVERABLESELIVERABLES

2.3.2.1 EDUI PD006 – MAINTENANCE, LICENSING, AND HOSTING CONTRACT EXTENSION

Description – Upon completion of the negotiated Contract, a new contract vehicle must be executed to allow the continued operations of STARS beyond December 2009.

Deliverable Acceptance Criteria – The new contract vehicle will be considered acceptable when it has met the approvals of the NMPED’s CIO, the selected offer’s consulting partner’s Project Director, the Project’s executives (sponsors) and the Office of the Chief Information Officer (DoIT)


2.3.2.2 EDUI PD007 – STATEWIDE EDUCATION USER INTERFACE (EDUI) DATA COORDINATOR COMPONENT

Description – The EdUI utilizes Microsoft SharePoint Portal technology to allow users to access STARS related data in a secure user friendly environment

Deliverable Acceptance Criteria – This component of the EdUI will be considered accepted when the NMPED EdUI and STARS team validate that all aspects of the Functional and Technical Specifications have been addressed, the EdUI has been tested, the appropriate users trained, and all acceptance criteria has been met.

Standards for Content and Format – The EdUI will be developed utilizing Microsoft SharePoint technology and related work products in the appropriate Microsoft Office products.

Quality Review – The periodic QA and IV&V reviews will monitor the quality of associated deliverables.

2.3.2.3 EDUI PD008 – STATEWIDE EDUCATION USER INTERFACE (EDUI) NMPED WEB COMPONENT


Deliverable Acceptance Criteria – This component of the EdUI will be considered accepted when the NMPED EdUI and NMPED Web Team has validated that all aspects of the Functional and Technical Specifications have been addressed, the EdUI has been tested, the appropriate users trained, and all acceptance criteria has been met.





2.3.2.4 EDUI PD009 – STATEWIDE EDUCATION USER INTERFACE (EDUI) PROGRAM COMPONENT


Deliverable Acceptance Criteria – This component of the EdUI will be considered accepted when the NMPED EdUI, NMPED STARS, and respective Program Teams have validated that all aspects of the Functional and Technical Specifications have been addressed, the EdUI has been tested, the appropriate users trained, and all acceptance criteria has been met.



2.3.2.5 EDUI PD010 – EDUI SECURITY AND PROVISIONING MODEL

Description – The EdUI Security and Provisioning Model will develop and roll-out the required security framework necessary to secure access of the EdUI relative functionality

Deliverable Acceptance Criteria – This component of the EdUI will be considered accepted when the NMPED EdUI and STARS teams, as well as NMPED’s CIO’s office have validated that all aspects of the Functional and Technical Specifications have been addressed, the EdUI has been tested, the appropriate users trained, and all acceptance criteria has been met.

Standards for Content and Format – The EdUI Security and Provision Model will be developed utilizing Microsoft SharePoint technology and related work products in the appropriate Microsoft Office products.

Quality Review – The periodic QA and IV&V reviews will monitor the quality of the pilot and associated deliverables.

2.3.32.3.3 DDELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

DDELIVERABLEELIVERABLE NNUMBERUMBER DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO

CANCAN APPROVEAPPROVE))DDATEATE AAPPROVEDPPROVED

EdUI – PD001 EdUI Project CharterProject SponsorDoIT

EdUI – PD002 EdUI Project PlanProject SponsorDoIT

EdUI – PD003 IV&V Contract & ReportsProject SponsorKey Stakeholders

EdUI – PD004 EdUI Project ScheduleProject SponsorKey Stakeholders

EdUI – PD005 EdUI Monthly Project Status Reports

Project SponsorKey Stakeholders

EdUI – PD006 Maintenance, Licensing, and Hosting Contract Extension

Project SponsorDoIT



DDELIVERABLEELIVERABLE NNUMBERUMBER DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO

CANCAN APPROVEAPPROVE))DDATEATE AAPPROVEDPPROVED

EdUI – PD007 EdUI Data Coordinator Component


EdUI – PD008 EdUI NMPED Web Component


EdUI – PD009 EdUI Program Component Project SponsorKey Stakeholders

EdUI – PD010 EdUI Security and Provisioning Model


2.3.42.3.4 DDELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

This section describes the procedures implemented to support the specification, preparation, and approval of Deliverables throughout the course of the Project.

There are three major steps to this process:

Step 1: Deliverable Specification

Step 2: Deliverable Preparation

Step 3: Deliverable Submission and Approval

Each of these steps is described in greater detail below:

STEP 1: DELIVERABLE SPECIFICATION

The Deliverable Specification is prepared by the Work Team responsible for completing the Deliverable and is usually the first task accomplished before commencing work on the Deliverable itself. The Specification takes the form of a memo from the Work Team to the Project Manager. Once completed, the Deliverable Specification is forwarded to the Project Manager for review, comment, and approval. The approved Specification then serves as the Team’s “road map” for preparing the Deliverable.

The Deliverable Specification contains four major sections: Identification. Provides key details about the Deliverable including its title, Deliverable number,

projected delivery date, lead individuals, estimated size, and number of copies needed. Description. Summarizes the Deliverable’s purpose, scope, and content. Includes a draft table

of contents outlining the high-level organization of the sections contained in the Deliverable. Acceptance Criteria. Defines the standard by which the NMPED should review this Deliverable

for approval. Deliverables meeting the acceptance criteria must be approved; those not meeting the acceptance criteria will be reworked until they do.

Approval to Proceed. Provides a space for the NMPED Project Manager to approve the Deliverable Specification. This approval authorizes the Work Team to initiate work on the Deliverable as described in the Specification.

A sample Deliverable Specification appears in Section 8.1.

SSTEPTEP 2: D 2: DELIVERABLEELIVERABLE P PREPARATIONREPARATION

Two sub-steps are involved in Deliverable Preparation—interim deliverable reviews and structured walk-through.

INTERIM DELIVERABLE REVIEWS

As segments of each Deliverable are completed, the creator will submit interim, logical subsets of the larger Deliverable to the NM PED for review, when appropriate. The interim Deliverable review, involving inspection of only a portion of the final Deliverable, is designed to earn the NMPED’s preliminary approval prior to formal submission of the final Deliverable.



By identifying potential defects early in the development process, each Work Team can take corrective action and save time and resources.

STRUCTURED WALK-THROUGH

In the structured walk-through, the creator will conduct a narrated review of the Deliverable as it turns the document over to the Project Manager for detailed review and approval. This is designed to provide an orientation to the Deliverable, which will facilitate the final review. Any aspects of the Deliverable requiring further clarification should be discussed at this time.

SSTEPTEP 3: D 3: DELIVERABLEELIVERABLE S SUBMISSIONUBMISSION ANDAND A APPROVALPPROVAL All Project Deliverables will be submitted to the NMPED Project Manager for review and formal approval when completed. With the Deliverable, a Deliverable Acceptance Form will also be submitted to serve as the mechanism for tracking approval.

The Deliverable Specification will guide the NMPED to determine whether the Deliverable is complete, accurate, and acceptable.

The NMPED Project Manager will issue the NMPED’s approval in writing for Deliverables that meet the acceptance criteria by returning the completed Deliverable Acceptance Form to the creator. If a Deliverable is unacceptable, the NMPED Project Manager will meet with the creator to discuss the reasons for rejection and to set in motion the rework process.

The NMPED Project Manager will have ten (10) business days to complete the review of the deliverable.

REWORK

If the Deliverable does not meet the acceptance criteria defined in the Contract or Deliverable Specification, the NMPED will prepare a list of deficiencies for the creator to address. The creator will then meet with the NMPED Project Manager to clarify these deficiencies. The creator will then integrate the NMPED’s comments into the document, resolve the Deliverable, and submit the document once again for approval. Changes to the original Deliverable will be documented and cross-referenced to the cited deficiencies.

The NMPED Project Manager will then indicate the NMPED’s acceptance in writing or will arrange a meeting with the creator to discuss further changes.

2.42.4 WWORKORK B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE (WBS) (WBS)Reference the EDUI Project Schedule for dependencies, durations, resources and further details. The EDUI Project Schedule can be found in Appendix 8.2. The following table summarizes the project’s major milestones and deliverables.

Major Milestones Work Product/Deliverable

Baseline Due Date

Actual Deliverable

Date

Status

Initiate Project

Project Management PlanJuly, 2008

Developer Training August, 2008

Specification Review

Functional Specification

Technical Specification

September, 2008

Coordinator Component Development

EdUI Coordinator ComponentJanuary, 2009

Framework Component Development April, 2009



EdUI Framework Component

Program Content Component Development

EdUI Program Content ComponentMay, 2009

System Testing June, 2009

User Training June, 2009

Final Acceptance June, 2009

Project Close-out

Project Close-out CertificationJuly, 2009

3.03.0 EEDDUI SUI STRATEGYTRATEGY

3.13.1 PPROJECTROJECT M MANAGEMENTANAGEMENT L LIFEIFE C CYCLEYCLEThe EdUI Project Management team will execute a consistent project management method that has been adopted by the DoIT Program Management Office. This approach will ensure success on the EdUI Project and serve as a framework for future projects within NMPED. This method will be organized against the Project Management Institute’s Project Management Book of Knowledge five process areas (see diagram below) and supported by the DoIT Program Management Office.

THE FIVE PROCESS AREAS DESCRIBED BY PMBOK

The project management methodology will include tasks, roles, tools/templates, as well as tailoring guidelines to customize the method for different project types. Through the evolution and maturity of the State of New Mexico project management practices, a single, complete description of project management will be realized.

The EdUI project management methodology will be a component of the larger State of New Mexico PMO Methodology.

3.23.2 CCRITICALRITICAL S SUCCESSUCCESS F FACTORSACTORSThe following Success Factors have been identified as critical in order for the EdUI to be successful:

Team members need to be empowered in order to make:o Technical Decisions.o Creative Decisions.


Controlling Processes

Closing Processes

Executing Processes

Planning Processes

Initiating Processes


Knowledge Transfer must be an integral part of the project so that NMPED and district staff is capable of supporting and maintaining EdUI.

A data management and governance process must be enforced by NMPED in support of the EdUI Project.

The EdUI Project must continue to support other NMPED initiatives dependent upon available financial, human resources.

NMPED will need to update the policies and procedures required to support EdUI. This includes defining organizational roles and responsibilities.

3.33.3 PPROJECTROJECT L LOGISTICSOGISTICSIn general it is expected that when any project team members are engaged at State of New Mexico, or PED facilities, that the project team members will be provided adequate facilities and resources including the following:

A desk, cubical, or office space and furniture that staff can use for project activities. A telephone that includes internal and external lines. A network connection. Building access authorization for the facilities that project team members will need to enter. Appropriate notification to the Customer or Vendor will be given and their approval sought

when activities will be conducted at their site.

3.43.4 PPROJECTROJECT P PRODUCTRODUCT L LIFEIFE C CYCLEYCLEThe Education User Interface is structured to allow NMPED to deploy the components an education portal using the Microsoft SharePoint Portal application to the project schedule. The project structure consists of three phases - Planning, Design/Build/Test, and Launch. Each of the phases is outlined below:1. The Planning Phase will initiate the project and encompass all of the following:

a. Project initiation activitiesb. Review existing POC documentation, including specifications, As-Is Assessment, and

Roadmaps and update the documents to reflect the needs of the identified users and user groups.

c. Review current state of NMPED infrastructure to assess NMPED’s capability to support the hardware and software for the EdUI.

2. The Design, Build and Test Phase will encompass the following: a. Finalize the Specifications and design documentation necessary to ensure development is

done correctly and each of the portal elements is addressing the users’ needsb. Development activities that include EdUI configuration, installation and some customization of

the portal productc. User testing and validation of the EdUI. The development team will reach out to end users to

validate, and test, the EdUI in an effort to ensure that the end product addresses the needs documented in the functional specifications.

d. Formal approvals and reviews of the EdUI. After each development component, the component and the entire EdUI will be reviewed by project sponsors for quality assurance. A final review will be performed before launch of the EdUI.

3. The Launch Phase will encompass the following: a. Deploy EdUIb. Train End Users on use, administration, and maintenance of the EdUI c. Post launch activities that include knowledge transfer and communications activities

4. Foundation Activities that span the life of the POC project: a. Project management activitiesb. To assist PED post launch of the EdUI, a EdUI Roadmap will be created to outline tasks,

activities, milestones and deliverables necessary to move forward with future enhancements to the EdUI.

3.53.5 TTECHNICALECHNICAL S STRATEGYTRATEGY



The proposed development meets the technical objectives of NMPED. It is NMPED’s intent to house and support the development environment with the confines of the NMPED data center. The system administration personnel (platform administration) will be located at NMPED. During development, the production technical requirements will be developed and the location of the production environment will be determined. To reduce network traffic, the present strategy is to locate the application software, system administration, and security administration as close to the data source as possible.

EDUI is not being developed on a proprietary operating platform and network. EDUI is utilizing existing State of New Mexico assets, standards and guidelines, including those that reside at the district level. EDUI’ technical objective to utilize existing assets will include, but not limited to, utilization of the existing State communications network; optimizing use of existing software capabilities; and, adherance to existing development, database and LDAP standards;

4.04.0 PPROJECTROJECT O ORGANIZATIONRGANIZATION

4.14.1 4.1 S4.1 STAKEHOLDERSTAKEHOLDERS

NAMENAME SSTAKETAKE ININ P PROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE

Veronica Garcia Sponsor NMPED Secretary

Robert Piro Project Director NMPED Asst. Secretary / CIO

Austin Buff Project Manager NMPED IT Director

Catherine Cross-Maple User/Oversight NMPED Deputy Secretary

Sheila Hyde User/Oversight NMPED Asst. Secretary

Jim Ball User NMPED Acting Asst. Secretary

Elizabeth Gutierrez Observer HED P-20 Policy Advisor

Peter Winograd User OEA Director OEA

Mike Baca Observer DoIT DoIT Consultant

Superintendent’s Advisor Committee User Local Education

Agencies

4.24.2 CCUSTOMERSUSTOMERSAll above stakeholders are also project customers. Other potential customers include:

Constituents of the State of New Mexico. Local superintendents and their staffs. New Mexico School administrators and teachers. External federal, state, and local government agencies. Office of the Governor. Legislative Finance Committee (LFC). Legislative Education Study Committee (LESC). Office of Education Accountability (OEA). The Public Education Department (PED).



4.34.3 PPROJECTROJECT T TEAMEAM

4.3.14.3.1 PPROJECTROJECT T TEAMEAM O ORGANIZATIONALRGANIZATIONAL B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE

The State’s EDUI Project Team will consist of the following EdUI Project roles: the Project Sponsors, the Executive Committee, the Project Director, Team Leads, Subject Matter Experts (SME), the Project Administrator, external Consultants, and other outside support.

4.3.24.3.2 PPROJECTROJECT T TEAMEAM R ROLESOLES ANDAND R RESPONSIBILITIESESPONSIBILITIES

Conducting a system improvement project, like the EDUI Project, is a major undertaking requiring many levels of organizational involvement.

The State’s Project Sponsor (PS)Roles and Responsibilities

The State’s Project Sponsor’s role is to provide project oversight, vision/direction, resource commitments, issue resolution, strategic direction and policy approvals, where required. The Project Sponsors will champion the project within the organization, and work to bring overall success to the project.

Specific responsibilities include the following: Provide strategic guidance. Provide financial support by authorizing expenditures relative to the project. Promote cultural change within the State. Provide approval for ancillary funding, if required. Monitor periodic status of the project to ensure success. Approve changes to the project, and provide whatever additional funds those changes

require.



Time Commitment - five (5) to ten (10) hours a month for the duration of the project

EDUI Project Executive Steering Committee (EC)Roles and Responsibilities

The Executive Steering Committee is a representation from key stakeholders. Their role is to provide overall project direction, make key project decisions, grant final approval of business policies, and accept and approve project objectives in strategic plan. Responsibilities include:

Provide overall direction to the project. Monitor (periodically) the direction of the project. Coordinate the utilization and proactive participation of the State’s resources. Provide organizational guidance of strategic process and organizational changes. Notify project management of operational changes that may strategically alter project

objectives. Provide proactive participation. Resolve conflict over policy or objectives. Selection and support of Project Team members. Ensure that all major issues of significant risk and impact are resolved promptly and

efficiently. Approve new or revised policies, as required.

Time Commitment - five (5) to ten (10) hours a month for the duration of the project.

EDUI Project DirectorRoles and Responsibilities

The Project Director is a member of the Executive Steering Committee. His/her role will be to advise the Executive Steering Committee and to execute the directives of the Executive Steering Committee. Responsibilities will include:

Providing organizational guidance and approval of strategic process and organizational changes.

Work with Project Manager to resolve issues relating to organizational change, including changes in “culture”, current practices, policy, etc.

Monitor periodic status of the project to ensure success.

Time Commitment - eight (8) hours a week in the Implementation Phase; will grow, as sponsorship is required in future phases.

EDUI Project Manager Roles and Responsibilities

The Project Manager’s role is to provide leadership and management necessary to achieve the project’s success. The Project Manager’s primary responsible will be for hands-on project leadership and to direct team activities. Specific responsibilities include:

Monitor the direction of the project. Over-all project management of project plan and budget. Provide day-to-day direction to the project. Coordinate the utilization and proactive participation of the State and outside resources. Ensure that all major issues of significant risk and impact are resolved promptly and

efficiently. Communicate results of the work to Executive Steering Committee. Ensure resources availability for project commitments.



Resolve resources conflicts which impact the timing and quality of the project. Coordinate all State project resources (ensure that team members are appropriate for

roles). Provide status reporting to the Executive Steering Committee. Work with team members relative to completing project activities. Identify, track and resolve project related activities. Ensure major issues are elevated to the Executive Steering Committee. Verify solutions are consistent with functional requirements.

Time Commitment - Full time for length of project.

Content Advisors Content Advisors are resources whose primary responsibility to assist Project management in the identification and evaluation of process impact to NMPED operations. They are responsible for the identification of industry best practices and core processes. Content Advisors will report to the Project Director, Project Manager, and indirectly to the steering committee.

Time Commitment - up to 24 hours a week in the Implementation Phase.

EdUI Development TeamRoles and Responsibility

The EdUI Development Team are the lead programmers on the project. They are responsible for the developing and integrating the functional and technical specifications into the cross-functional EdUI. They will report to the Project Manager and are responsible for the coordination of the over-all management of the project activities. The EdUI Development Team was selected based on their programming expertise and experience wit Microsoft SharePoint. These team members will have:

A solid understanding of the business and processes in their department and will be considered an EXPERT in their field of understanding.

Possess excellent communication skills and the ability to capture and analyze data. Possess superior technical skills to expedite application development. Ability to use analytical and problem-solving skills to respond to change and institute

change in the organization. Team-building and team player skills to complete tasks and deliverables with a high level

of coordination and communication.

Specific responsibilities include: Review and revise the POC functional and technical specification into the cross-

functional EdUI. Evaluation and selection of enabling technology to support new business processes. Provide status reporting to Project Manager. Work with Subject Matter Experts relative to completing project activities. Identify, track and resolve process related activities and issues. Ensure irresolvable major issues are elevated to the Project Manager. Work with the Project Manager to resolve issues relating to process redesign, functional

requirements, and organizational change. Verify newly designed business systems are consistent with functional requirements.

Time Commitment - 80% to 100% for the duration of the project.

Subject Matter Experts Roles and Responsibilities



The State’s Subject Matter Experts role will be to provide cross-organizational support to the Project’s EdUI Development Team in support of their organizational functionality. These activities will include workshops, interviews and data gathering based on assignment. Specific responsibilities include:

Execute the day-to-day project tasks, including content workshops, process flow documentation, test script development and execution.

Provide cross-organizational input to the EdUI Development Team. Define and document issues that arise during the project. Assist in the development of users procedures. Evaluate and modify master data prior to conversion. Identify, document, and implement required policy changes. Report time spent on project activities in a timely and accurate manner. Identify issues and report them to the project managers. Assist in the development of other project deliverables.

Time Commitment - During the design and procurement stages of the project, it is expected that these individuals will spend 30% to 60% of their time executing project tasks.

External ConsultantsExternal Consultants supporting the project are chartered to provide recommendations and direction for the execution of day-to-day activities. They are responsible for methodology, industry, and process oriented expertise. Specific responsibilities include:

Facilitate the day-to-day project tasks, including process workshops, process flow documentation, requirement definition workshops, test script development, vendor demonstration and selection.

Participate in the completion of project activities through design, selection, pilot and package training sessions.

Facilitate in the identification, documentation, and resolution of issues that arise during the project.

Assist in the development of user procedures. Facilitate the identification, documentation, and implementation of required policy

changes. Report time spent on project activities in a timely and accurate manner. Identify issues and report them to the project Managers. Assist in the development of other project deliverables. Assist in the development of detailed project plans and their timely execution. Assist in resolving technical and business application issues.

Time Commitment - As required.

OOTHERTHER O OUTSIDEUTSIDE S SUPPORTUPPORT

During the project, it will be necessary to call in additional outside support to deal with specific issues or problems. Specifically, it is anticipated that the software and hardware vendors required to support the new business systems at the State, will be required. Specific responsibilities will include:

Assist in resolving technical and business application issues. Provide recommendations on modification, interface, and conversion issues.

Time Commitment - As required.

4.44.4 PPROJECTROJECT G GOVERNANCEOVERNANCE P PLANLAN



The NMPED has organized the EDUI Executive Steering Committee to provide senior management responsible for policy decisions during the subsequent implementation of the ensuing solution. The State has assigned a Project Manager who is knowledgeable of performance accountability data systems and will rely on other team members. The State’s Project Manager will resolve issues in a timely manner to support the project schedule.

The project EdUI Development Team will be required to make decisions within a reasonable period of time. The State will provide knowledgeable user personnel (subject matter experts) who can participate in the project and assist in reviewing work produced and in facilitating the search for information an requirements. The State will assign the Team Leads and Subject Matter Experts, employees knowledgeable with the NMPED’s business processes, operations, and technology for the duration of the project, and make additional subject matter experts available as needed.

5.05.0 PPROJECTROJECT M MANAGEMENTANAGEMENT ANDAND C CONTROLSONTROLSUsing effective controls throughout the Project helps assure overall Project quality and performance. Controls lead to a well-defined and well-documented Project. Perhaps most important, these controls enable the PMO to track, address, and resolve issues before they become major hindrances to the Project’s success.

Effective controls allow Project risks to be identified, alternatives to be developed, and follow-through actions to be achieved. Close monitoring and controlling of schedules and resources allows Work Teams to accommodate discrepancies as early as possible. Through ongoing communication among Work Teams, the Project Management Office is kept aware of Project status, problem areas, and priorities. Constant communication also promotes consensus on objectives and priorities.

Project control relies on having information readily available to identify potential problem areas. It also determines the proper corrective action, so that any gap between the projected status and the actual status can be closed. Corrective actions may include adjusting resource usage, changing the approach to specific activities, and replanning tasks. These actions help to assure that schedules are met, resources are optimally used, quality is maintained, and productivity standards are achieved.

5.15.1 SSTAFFINGTAFFING P PLANNINGLANNING ANDAND A ACQUISITIONCQUISITIONThe project staffing plan presently encompasses only the individuals to accomplish the selection of a software product, hardware, platforms, integration services, communication services, and IV&V services.

5.1.15.1.1 CCOREORE T TEAMEAM A ASSIGNMENTSSSIGNMENTS

5.25.2 AASSUMPTIONSSSUMPTIONS



NNUMBERUMBER TTITLEITLE DDESCRIPTIONESCRIPTION

EdUI – AS1 Project buy-in Pilot District participation and buy-in.

EDUI – AS2 Availability Project team members will have adequate time for project planning activities.

EDUI – AS3 Decision Making

Project management will make decisions in a timely manner to support the project schedule.

EDUI – AS4 Collaboration.Individuals with different data needs and perspectives will work together to design an overall plan for improving the management of data and information for NMPED.

EDUI – AS5Team

Participation.

Project Team members will be assigned and allowed to spend the proper amount of their time to complete tasks within a reasonable timeframe.

EDUI – AS6 Staffing

The development of the EdUI will require staff with the proper skills in order to perform this successfully. Internal and external staff will be assigned and/or hired assigned.

EDUI – AS7Scope of Project

The scope of this project will initially be limited to the STARS data that is either collected from external entities (i.e. Districts and charter schools) or reported externally from the department or otherwise needed for NMPED operations.

5.35.3 CCONSTRAINTSONSTRAINTS

NumberNumber DescriptionDescription

EdUI – C01 Decisions not made in timely manner.

EdUI – C02 Funding at $1.65M.

EdUI – C03 Staff participation.

EdUI – C04 Qualified staffing to perform project tasks.

5.45.4 DDEPENDENCIESEPENDENCIES

5.4.15.4.1 MMANDATORYANDATORY D DEPENDENCIESEPENDENCIES (I (IMPOSEDMPOSED BYBY O OTHERSTHERS))

NumberNumber DescriptionDescription

EdUI – MD01 Periodic PCC reviews.

EdUI – MD02 Periodic IV&V reviews.

EdUI – MD03 Periodic Funding Requests.

5.4.25.4.2 DDISCRETIONARYISCRETIONARY D DEPENDENCIESEPENDENCIES (I (IMPOSEDMPOSED ONON S SELFELF))

NNUMBERUMBER DDESCRIPTIONESCRIPTION

EdUI – DD01 NMPED Staff to lead and execute project activities

EdUI – DD02 First Component brought live, by January 2009.



5.4.35.4.3 EEXTERNALXTERNAL D DEPENDENCIESEPENDENCIES

NNUMBERUMBER DDESCRIPTIONESCRIPTION

EdUI – ED01 Users participate and buy in to the objectives of the EdUI project.EdUI – ED02 External resources are capable and willing to support the project strategy

of knowledge transfer.

5.55.5 RRISKISK M MANAGEMENTANAGEMENTRisk management is a project/program management tool to assess and mitigate events that might adversely impact EdUI, thereby increasing the likelihood of success. Risks must be well understood, and risk management approaches developed, before NMPED Management and key stakeholders can authorize a project to proceed into the next phase of the acquisition process. The following diagram shows how EdUI risk management fits into the phases and milestones of the acquisition process.

EdUI Risk management Process

5.5.15.5.1 RRISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGY

Risk management strategy is intended to identify critical areas and risk events, both technical and non-technical, and take necessary action to mitigate the risks before they can become problems, causing serious cost, schedule, or performance impacts. Risk information will be included in all project reviews, and as new information becomes available, the project manager and vendor will conduct additional reviews to ascertain if new risks exist. The goal is to be continuously looking to the future for areas that may severely impact the project.

5.5.25.5.2 PPROJECTROJECT R RISKISK I IDENTIFICATIONDENTIFICATION

New Mexico Public Education Department (NMPED) Lack of NMPED expertise with SharePoint Programming New Decision support tools may need to be developed



Staff having the availability to complete tasks Lack of sufficient funding Lack of defined development policies, standards, best practices, and sustainable processes.

5.5.35.5.3 MMITIGATIONITIGATION OFOF I INITIALNITIAL P PROJECTROJECT R RISKISK

Project risk mitigation is the process of reviewing existing risk management practices and determining if the risks associated with EdUI have been appropriately identified, evaluated and mitigated by the project manager, NMPED management, and key stakeholders.

Description of Risk Mitigation

Lack of NMPED expertise with SharePoint Programming

Probability – NMPED has limited expertise

Mitigation Plan – extensive training in Sharepoint is scheduled and external resources will put in place to act as coaches through development

Contingency Plan – roll-out scope will be reduced and contractors retained to complete development.

New Decision support tools may need to be developed

Probability – 75%

Mitigation Plan – NMPED resources have been made available to develop tools as required.

Contingency Plan – Content could be cut to utilize only existing reports, or roll-out scaled back and contractors retained to develop required reports

Staff having the availability to complete tasks if emergencies arise in daily operations

Probability – 50%

Mitigation Plan – two term employees were allocated to perform daily operations. If emergencies arise in daily operations, the term employees will be assigned either EdUI tasks or the emergency tasks.

Contingency Plan – roll-out scope will be reduced and contractors retained to complete development.

Lack of sufficient funding. Probability – 100%

Mitigation Plan – Scope has been reduced based on available funding

Contingency Plan – roll-out scope will be further reduced.

Lack of defined development policies, standards, best practices, and sustainable processes.

Probability – 100%

Mitigation Plan – Scope has been defined to create the policies as they arise.

Contingency Plan – None, standards and policies must be developed.

5.5.45.5.4 RRISKISK R REPORTINGEPORTING ANDAND E ESCALATIONSCALATION S STRATEGYTRATEGY

The project manager will provide regular updates to NMPED Management and key stakeholders on any aspect of the high-level risks that cause concern. High-level risks are defined as those risks to which the organization as a whole may be subject. These could be political, social, economic, structural, strategic,



people related, general systems related, regulatory, or legal. Reporting will focus on the results of actions and the evidence of success of the risk management strategy.

5.65.6 IINDEPENDENTNDEPENDENT VALIDATIONVALIDATION ANDAND V VERIFICATIONERIFICATION (IV&V) (IV&V)

5.6.15.6.1 SSTRATEGYTRATEGY

Productive Data Solutions (PDS) IV&V Contractor will conduct the IV&V Services of EdUI. The IV&V service will be conducted based on IV&V guidelines derived from PMI Best Practices and IEEE standards for system verification and validation (Standard 1012) and the IEEE guide for system verification and validation plans (Guide 1059). Additionally, IV&V will be required according to the criteria established and set forth in the Oversight and Program/Project Management Rule and as selected by the DoIT or ITC to engage IV&V.

5.6.25.6.2 OOBJECTIVEBJECTIVE

At a minimum, IV&V will be required to verify the appropriate project requirements/ specifications so that objective verification and validation is possible to achieve.

Review all project deliverables and methodology. Structure an IV&V plan to oversee the project efforts and outcomes in accordance with

the State PMO for this project. Participate in EdUI project meetings and review project activities.

5.6.35.6.3 PPROCEDURESROCEDURES

The function of IV&V is to provide Independent Evaluation/Assessment of: Are we building the product right? = Verification

Products of a given phase of the system development lifecycle fulfill the requirements established during the previous phase.The product is internally complete, consistent and correct and will support the next phase.

Are we building the right product? = ValidationThe process of evaluating software throughout its development process to ensure compliance with software requirements. This process ensures: expected behavior when subjected to anticipated events; no unexpected behavior when subjected to unanticipated events; and system performs to the customer’s expectations under all operational conditions.

IV&V efforts will develop and execute an IV&V Project Plan that is aligned with the overall EdUI Project plan. The IV&V plan will detail a schedule of verification and validation activities with deliverables, budget and resource management. The IV&V Project Manager will develop and provide monthly or phased IV&V reports, at a minimum, and other reports and expert advisements as requested by the EdUI Project Director, DoIT, PMO, ITC and Project Steering Committee.

The IV&V Project Manager will develop and execute an IV&V Plan based on PMI Best Practices and IEEE standards for system verification and validation (Standard 1012) and the IEEE guide for system verification and validation plans (Guide 1059) and appropriate for analyzing and monitoring the project objectives in accordance with the State PMO best practices and standards.

The IV&V project plan, methodology, and tasks will be outlined, scheduled, and executed, based on the best practices, processes, and techniques provided by or comparable to the methodology endorsed by the State PMO; in each of the Project Management Lifecycle phases:

1. Initiate2. Plan3. Execute4. Control5. Close



5.6.45.6.4 PPRIMARYRIMARY E ELEMENTSLEMENTS OFOF P PROPOSEDROPOSED IV&V S IV&V SCOPECOPE OFOF W WORKORK

Overall Project Execution and PerformanceThe purpose of this task is to provide a periodic review of the executed project management activities, including maintenance of the project schedule, issue identification, and resolution Project Change Control and task execution. The IV&V Project Manager will provide the project management review based on PMI Best Practices. The first will consist of a detail review of the existing project management policies and procedures; another typically is performed after requirements definition, another typically during procurement, another is typically during system test; another is typically performed just prior to end-user testing and final acceptance testing; and the last performed during the post production support.

Project Plan and Execution – The purpose of this task is to monitor all aspects of NMPED’s EdUI project plan. The plan should detail the who, what, when, where, and how much description of the major aspects of the project. The plan should capture and summarize the project’s approach to implementation, training, testing, change management, and other project related tasks. Periodic monitoring of NM NMPED’s Project Schedule will assure that the project is using a structured methodology and disciplined approach; that the plan is being used effectively to manage and monitor the project. Monitoring the EdUI Project Plan will consist of individual interviews and the key project team members and stakeholders and assessing the extent that the plan is being used to manage the progress of the project.

Project Controls and Procedures – During the initial Project Execution and Performance Review, the IV&V Project Manager will verify there are adequate Project Controls and Procedures in place to adequately measure and manage scope and change management, issues resolution, project communications, status, and reporting. Future Project Execution and Performance Reviews will assess how well the Project Control and Procedures are used to manage the project.

Issues Identification and Resolution – The purpose of this review will be to monitor the EdUI issue log to determine if project issues are efficiently identified, escalated, and resolved appropriately. A further purpose of this task can be to provide facilitation support for the timely resolution of identified project issues.

Risk Identification and Risk Mitigation Strategies – The purpose of this task is to review existing risk management practices and determine if the risks associated with the project have been appropriately identified, evaluated and mitigated by project and NM NMPED management. The task is also focused on the continued identification of additional risks related to the project based on individual reviews.

Project Deliverable ReviewThe IV&V Project Manager will review the project deliverables for quality of content, completeness, accuracy, and timeliness. This will include reviewing requirements defined in RFP, RFP Response and Best and Final Offer, implementation agreement, change orders, NM State law, administrative policy, and Federal law. Specific review activities will include reviews of deliverables identified in the IV&V Project Plan.

5.6.55.6.5 RREPORTINGEPORTING R REQUIREMENTSEQUIREMENTS

The IV&V Project Manager will use standard project management disciplines and IV&V methodologies to develop and document an IV&V plan that will monitor activities, progress, and issues.

At a minimum, the IV&V assessment reporting provided by the IV&V Contractor shall:1. Provide a risk assessment within the first 10 business days.2. Provide a Project Status report within the first 10 business days3. Prepare an IV&V assessment report at the end of each phase or monthly of the product

development lifecycle, or more frequently, if requested by the project executives.4. Submit a copy of each IV&V assessment report to lead agency management and the DoIT

within seven (7) days of each IV&V assessment.



5. Include in the project schedule as a project activity each IV&V assessment that is performed during the project management lifecycle execute phase.

6. Store a copy of each IV&V assessment report in the agency’s project repository.7. Provide a post-implementation assessment

5.75.7 SSCOPECOPE M MANAGEMENTANAGEMENT P PLANLANThis project plan will be used as the principal tool to manage the scope of the project. This plan will serve as the written statement detailing the parameters of the project, and the process required to ensure that the project includes all the work required for successful completion. It identifies the project objectives, project justification, a product description and a summary list of major project deliverables. Utilizing this plan as the written scope statement, it will establishes the basis for future project decisions, and forms the basis for an agreement between the project team and the customer.

The major project deliverables are subdivided into smaller, more manageable components in a work breakdown structure (WBS) to improve accuracy of cost, time and resource estimates. The WBS also defines a baseline for performance measurement and control, and provides a graphic representation that completely defines the project by relating elements of work to each other and to the end product. The WBS shows the relationship of all elements (hardware, software, service, data, etc.) supporting the project, and provides a sound basis for technical costs and schedule control. Formal WBS designation can be found in the EdUI Project Schedule.

Scope verification is the process of formalizing acceptance of the project scope by stakeholders. It requires review of work products and results to ensure that all were completed correctly and satisfactorily. If the project is terminated, scope verification will establish and document the level and extent of completion.

Change control is critical. Project Managers will use the change control process, as defined in Section 5.9 to manage changes when they occur, and to ensure changes are beneficial.

5.85.8 IISSUESSUE M MANAGEMENTANAGEMENTThe issue process is a component to the successful delivery of any project. It ensures that each issue identified in the project environment is documented, prioritized, and resolved in an appropriate length of time.

5.8.15.8.1 IISSUESSUE D DOCUMENTATIONOCUMENTATION

The EdUI project will have 5 steps in the Issue Documentation and Resolution Process:1. Identify current issues.2. Logging and prioritizing the issues.3. Determining the issue resolution action.4. Monitoring and control of assigned issue resolution actions.5. Closure of issue.

Identification of Issues:The process provides the ability for any member of the project team to raise a project-related issue. The source of the issue can be internal from the project team, or external from stakeholders outside of the project team. The following two step procedure will be undertaken when raising an issue:

1. Issue originator identifies an issue applicable to a particular aspect of the project.2. If the originator is external to the project team, the originator must find a project team member

to document the issue. If no team member assumes responsibility for the issue, the external originator should get the project manager to document the issue. In the later case the Project Manager becomes the issue originator and owner.

3. Issue originator completes an issue form and distributes the form to the Project Manager. (See appendix 8.7 – Issue Description and Resolution Form).



Logging and prioritizing the issues:The process allows the project manager to review all issues raised and determine whether each issue is applicable to the project. The decision will be based on whether the issue impacts:

Specified project deliverable. Quality deliverable. Schedule impact. Budget impact.

The issues will be prioritized with the following guidelines: High – Critical path, High probability for schedule slippage. Medium – Non critical path, potential schedule slippage. Low – Non critical path, no immediate impact to project.

Receipt acknowledgement and logging of the issue, is the responsibility of the Project Manager. The project manager will:

Acknowledge receipt of the issue from the issue originator. Determine the priority of the issue with the issue originator. Assign the received issue a control number. Log the issue into the issues log. (See appendix 8.7 – Issue Management Log)

Determination of the issue resolution plan:This process requires the formal review of the issues log by the project review group. This group will review each issue in turn (based on issue priority). (Refer to the below Issue Resolution Flow diagram).

Issue Resolution Flow

The group can decide to: Close the issue if there are no outstanding issue actions and the issue is no longer impacting

the project. Perform an issue risk assessment and generate a change request if the issue has resulted in

the need for a change to the project.



Assign the issue to a project team member to determine and recommend a resolution approach. If the project review group determines that this is the course of action for the issue, the project manager enters the project team member who has been assigned resolution into the issues log.

Monitoring and control of assigned issue resolution actions:This process requires the implementation of all actions assigned by the project review group. It involves:

Scheduling each action for completion. Implementing each action scheduled. Reviewing the success of each action completed. Communicating the success of each action completed.

The project manager is required to monitor all of the steps within this process and report to the issue originator and the project review group.

Closure of issues:This process will assure that the issue solution has been completed and closed, the project manager has notified the project review group and the issue originator, and has entered the necessary detail closure information into the issues log and issue submittal form.

5.8.25.8.2 PPROJECTROJECT I ISSUESSUE E ESCALATIONSCALATION ANDAND R RESOLUTIONESOLUTION P PROCESSROCESS

Effective issue tracking and resolution are critical to the success of the project. The following issue escalation process is recommended.

An issue may be initiated by anyone associated with the project. The appropriate form to use is the Issue Description and Resolution Form. Timeliness in resolving issues has an immediate impact on the costs of the project effort. The following is the procedure for escalating both internal and external issues.

Tier 1 – Team to Team LeaderProject Team members can identify or escalate an issue to their Team Leader by sending an email to the Team Lead documenting the following (Project Manager should be copied on email):

Issue Description. Impact:

o High – Resolution is expected within 8 hours.o Medium – Resolution is expected within 2 workdays.o Low – Resolution is expected within 5 workdays.

Recommendation / Plan.

The team leader is then responsible for resolving the issue. If the team leader determines that the issue cannot be solved at their level or needs to be escalated, they will document the issue in the appropriate Issue Description and Resolution Form and forward it to the Project Manager. The Issue Description and Resolution Form should have the following completed:

Issue Description. Impact. Functional & Technical Areas Affected. Recommendation.

Tier 2 – Team Leader to Project Manager



Upon receipt of a newly escalated issue, the Project Manager is responsible for logging the escalated issue in the issue-tracking logbook. The Project Manager is then responsible for working with the project team to define the following information for the issue:

Resolution Owner / Team. Resolution Strategy & Activities. Resolution Time Frame (before being escalated). Risks.

The Project Manager will then work with the issue resolution team and the issue owner to make sure that it is resolved within the established time frame. If it is determined that the issue will not get resolved in the resolution time frame, the Project Manager will assess the impact of the time slippage and assign a new resolution time frame or escalate to the Project Sponsor.

Tier 3 – Project Manager to Project DirectorThe Project Manager escalates issues to the Project Director when further escalation is needed to resolve an issue. The Project Manager will update the status of the issue in the Issue tracking log. The Business Owner will then work with the Project manager in resolving the issue, and setting a new resolution time frame. If resolved, the Project Director will update the issue-tracking logbook and close out the issue. If the issue cannot be resolved at the Project Director Level, it will be escalated to the Steering Committee.

Tier 4 – Project Sponsor to Steering CommitteeIf the issue requires executive representation or additional escalation, the Project Sponsor escalates issues to the steering Committee. All contractual and legal issues will be escalated to the Steering Committee for resolution. The Project Director and Project Sponsor will assist the Steering Committee in resolving the issue. If resolved, the Project Director will update the issue-tracking logbook and close the issue.

Upon resolution of each issue, the project manager will communicate back to the impacted parties as to the final disposition of the issue.

5.95.9 PPROCUREMENTROCUREMENT M MANAGEMENTANAGEMENT P PLANLANAll procurement activities will be accomplished through existing contract channels. There is no direct procurements that will be associated with this appropriation. The existing contract channel for license, maintenance, and Hosting support services will expire in December of 2009. As NMPED determines support requirements a procurement activity will occur to support FY2010. At this time NMPED will initiate a proper procurement in accordance to State Purchasing guidelines.

5.105.10 CCHANGEHANGE C CONTROLONTROLDuring the course of the project many issues will occur that influence the scope of the project. Those issues may either be requirements in the form of additional complexity or in the form of new deliverables. These “potential increases” to the project scope must be properly managed and approved before they can be incorporated into the project’s work effort. The following outlines a process for managing “change control”. If scope changes are not controlled the project schedule and budget will be destroyed before the project manager recognizes that anything has happened. A well thought out change control process will assist the Project Director and project teams in controlling this “scope creep” nemesis.As scope change requests are made, a change control process is necessary to insure that the following occurs:

Only necessary changes are made. Changes are approved by appropriate parties prior to release for implementation Changes are communicated to all affected parties. Changes are implemented in an orderly fashion.

5.10.15.10.1 CCHANGEHANGE C CONTROLONTROL P PROCESSROCESS

Upon identification of a potential project change the following six tasks will be executed:



1. The EdUI Project Director shall ensure the new requirement is sufficiently documented; see Change Request Form, Appendix 8.7. The initiator of the change will complete the reason and scope sections of the Change Request Form and sign the “Initiated by” section. The initiator will then submit the form to the project manager. If the change request is initiated by the Integration Partner, the integration partner’s project manager will be responsible for completing the change control document.

2. The Project Managers are the channels through which Change Requests are funneled. Any Change Request that does not have the Project Manager’s signature is immediately returned to the submitter.

3. The project team will review the documented change with the project manager. The Project Director will also communicate the proposed change to the Core Team and the Project Status Meeting attendees.

4. The project team will then perform the necessary analysis to determine the cost and timeline estimates for incorporating the proposed change or validate the proposed change if initiated by the integration partner.

5. The project manager will then present the proposed change, the cost, timeline, and changes to project delivery dates to the Change Control Board.

6. If the change is approved, the EdUI Project Director will formally document the change in both the Project Plan and Project Schedule.

Throughout this process, the EdUI Project Director will document the status of each proposed change in the weekly status report and the change control log.

5.10.25.10.2 CCHANGEHANGE C CONTROLONTROL B BOARDOARD (CCB) (CCB)The board consists of a group of individuals authorized to approve changes to the project plan. The change control board’s primary responsibilities are as follows:

Conduct periodic CCB meetings. Review all proposed changes submitted to the CCB by the PM team. Approve changes that are objectively beneficial to the overall success of the project. Review change request activity on a per-deliverable basis to determine the overall quality and

stability of the completed, baseline deliverables.

The CCB not only decides whether to make changes, but also the conditions for releasing changes. For example, a change may be of such critical nature the CCB will want to review final results prior to releasing the product.



PPROPOSEDROPOSED C CHANGEHANGE C CONTROLONTROL B BOARDOARD::

STATE OF NEW MEXICO CONSULTING PARTNER (S)Required:

Robert Piro Mike Baca Sheila Hyde

Required: Mitch Johnson IV&V contractor

Optional: Veronica Garcia Catherine Cross-Maple Don Moya

Optional: Will Wanker Name 2 Name 3

5.10.35.10.3 CCHANGEHANGE P PRIORITYRIORITY ANDAND C CLASSIFICATIONLASSIFICATION

Change requests will be assigned a change priority classification code during review by the Change Control Board. The classification code will be based on a set of standards. A sample set of standards is as follows:

1 – Critical : A critical priority change request is considered to be imperative to the success of the project, and likewise, may have a detrimental impact to the project if not addressed promptly. This type of change request is mandatory and must be completed. The timeframe for estimating the effort and cost required to implement a critical change request should be one (1) week or less. Examples of critical change requests are legal mandates, functionality to meet core business process requirements, or data integrity with respect to database content.

2 – High : A high priority change request is considered to be important to the success of the project. The timeframe for estimating the effort and cost required to implement a high priority change request should be two (2) to four (4) weeks. Examples of high priority change requests are issues and problems resulting from data integrity, legal mandates, and add-ons to improve data quality.

3 – Medium : A medium priority change request has the potential to impact successful completion of the project but is neither an immediate help nor hindrance. The timeframe for estimating the effort and cost required to implement a medium priority change request should be four (4) to six (6) weeks. Examples of medium priority change requests are requests that improve workflow processes.

4 – Low : Low priority change requests need to be addressed if the time and budget permit. Low priority changes requests are managed, as resources are available. The timeframe guideline for estimating the effort and cost required to implement a low priority change request is more than six (6) weeks. Examples of low priority change requests are cosmetic changes or “fixes” that do not affect business functional requirements or deliverables.

5.115.11 PPROJECTROJECT T TIMELINEIMELINE



5.125.12 PPROJECTROJECT B BUDGETUDGET

5.135.13 CCOMMUNICATIONSOMMUNICATIONSThe need for close coordination and communication with the project team, executive sponsors, and stakeholders is recognized as a vital part of this project. Communication plays an essential role in organizational change success. During times of change, communication is especially critical.

The following Communication Plan describes how specific aspects of the EdUI Project will be communicated to impacted audience groups. The plan also provides specific strategies to introduce personnel to the changes they will be experiencing by providing timely and comprehensive information



delivery. Clear, planned, and regular communication of information throughout all project phases is required to ensure effective management of project resources.

The project manager will serve as the hub for all formal project communication (scope, time, and budget) and for all official project deliverables. It will be the responsibility of the project manager to distribute all communications to the appropriate personnel. This does not imply that all communication goes through the project manager and teams cannot work together. It is to serve as a matrix for all official project communication.

A primary objective will be the continual communication of project status and progress with major stakeholders and the DoIT. Direct communications with the DoIT will include:

Monthly communications of project status based on the DoIT Project review forms. Consultation on technical architecture and requirements. Direct IV&V reviews.

5.13.15.13.1 AAUDIENCEUDIENCE

Project Management must report to multiple layers of management. The project team involves a large number of functional and technical personnel. The application and the re-engineered processes and procedures will result in new roles and

responsibilities for affected personnel. A large number of users will be affected by the new systems and business processes.

5.13.25.13.2 OOBJECTIVESBJECTIVES

Provide frequent, credible information that enables the awareness of the EdUI Project. Enable buy-in, ownership, and participation of organizational stakeholders. Assure that all stakeholders receive the appropriate level of timely communication that is

most meaningful to them. Carefully craft and communicate change messages, making sure that all messages are

aligned and appropriately targeted to each audience. Create ongoing, open, honest, feedback loops with key stakeholder groups. Establish a communication infrastructure.

5.13.35.13.3 BBENEFITSENEFITS

Creates an underlying foundation of trust needed to engage all levels of the organization in change.

Builds credibility. Prepares and manages expectations about change. Facilitates a sense of community. Promotes positive morale and feeling of value. Builds buy-in and ownership for the change.

5.13.45.13.4 CCOMMUNICATIONOMMUNICATION I INFRASTRUCTURENFRASTRUCTURE

In order to sustain effective communication as a part of the EdUI project, it is vital that a communication infrastructure be established. The infrastructure must align with the project vision and must be clearly recognized by all project team members. Elements of a communication infrastructure include:

Defining communication roles and responsibilities. Establishing key positions that have accountability for communication goals. Ensuring that those with EdUI Project responsibilities have the necessary skills and a clear

understanding of their roles. Embedding feedback measures in the communication process Recognizing that involvement is a key success factor in establishing an effective

communication infrastructure.

The following matrix describes the various forms of communication to be executed by the EdUI team. It outlines the type of communication, the media of communication, and the frequency.



5.13.4.1 STATUS MEETINGS

Project Summary Meeting:The Project Team meetings are held on a regular basis to facilitate communication of critical project status and issues. Project Team meetings address the following project related information:

Project status, progress, and performance. Changes to project scope, direction, and schedule. Critical project risks and issues, recommendations, and resolutions.

Any action items identified within the Project Team meetings are documented and actions are taken by Project Management. Project Management reports back to the Steering Committee.

Weekly Project Status Meeting:Status meetings will be held once a week. The status meetings will be chaired by the EdUI Project Manager and attended by project leaders, the Integration Partner Project Manager, and other personnel as appropriate. The list below shows the items that the Project Manager will deliver as part of the status reporting procedure:

Updated Project Schedule. Copies of Change Request Forms. Meeting Minutes. Copies of the Issue Log. Newly Identified Risks.

To ensure consistency from week-to-week, and to ensure that each attendee of the status meetings is prepared, a standard agenda has been developed for the meetings.

Agenda for status meetings:1. Status (deliverable status, scheduled project activity for the week)2. Issues3. Risks4. Change Orders

5.13.4.2 WEEKLY STATUS REPORTS

Project leaders and the consulting partner Project Manager will submit to the EdUI Project Director a status report of weekly activity by close of business on the day before the status meeting as mentioned below. This report should contain:

Project Status Summary. Deliverables / Tasks actual start and end dates. Key accomplishments for the current period.



Key plans for the next period. Activities in progress and estimated work for completion. Issues and management action items.

The status report will be distributed to project management and project team members upon completion. Project team members include all project leads and team leads, program administrator, program director, and project management consultants.

5.13.4.3 STAKEHOLDER MEETINGS

Stakeholder Meetings are conducted to maintain communication with the project team and the end users. The following information will be discussed to facilitate end user acceptance of new systems and business processes:

1. Functional area policy decisions.2. User participation in project tasks.3. Project direction, status, and progress information.4. System and process design considerations, issues and decisions.5. Project accomplishments and milestones.6. Project risks.

Stakeholders consist of user representatives from participating agencies, boards, and commissions affected by the project initiatives. They facilitate liaison between the Project Team and the user community. Specific objectives include:

Resolve functional area policy issues. Confirm system and process designs adequately meet use requirements and management

objectives. Provide user input on system and process design considerations and issues.

5.145.14 MMEASURINGEASURING ANDAND E EVALUATINGVALUATING P PERFORMANCEERFORMANCEPerformance measurement is essential for the Project Management Office to control the Project’s schedule, scope, and resources. Accomplished work must be continuously measured against planned work to determine whether corrective action is needed. The following measurements are used make these decisions: Planned start date versus actual task start date; Planned completion date versus actual task completion date; Planned effort expended for a task versus actual effort; Variance reasons; and

Impact of variances on subsequent work.

Most tasks are prerequisites for later work. Therefore, it is essential that each critical task is carefully reviewed and approved prior to initiating dependent tasks. As a result, walk-through of all Deliverables are required to verify that all acceptance criteria are met and product quality is maintained. (Deliverable walk-through are discussed further in MCP004, part of Appendix A.)

The high-level work plan provides the estimated duration of the Project. However, Work Team members must report their actual hours expended on each task. These reported hours are used with the estimates from detailed work plans as well as the task status to determine whether there is any deviation from the plan. All deviations are identified as early in the process as possible and thus can be addressed immediately.

5.155.15 CCORRECTIVEORRECTIVE A ACTIONCTION P PLANLANThe first step to controlling a large project is to identify and anticipate potential problems. Using the exception reports and actual-versus-planned activity graphs created in the monitoring activity, the PMO can identify those areas deviating from the master schedule. The Project Management Office will monitor the schedule and identify the individuals responsible for late tasks to determine which activity is causing the problem and what course of corrective action is appropriate.



If a task is late (or projected to be late) a Corrective Action Plan (CAP) is prepared. The CAP is designed to escalate the problem on a timely basis and assure its resolution. The CAP consists of the following components:

Purpose of the CAP; Problem Identification and Background; Discussion of Our Approach to Correcting the Problem; Revised Schedule; Revised Resource Loading; Additional Resource Commitment, if necessary; and Plan for Monitoring the CAP’s Success.



5.165.16 QQUALITYUALITY O OBJECTIVESBJECTIVES ANDAND C CONTROLONTROLThe objective of Quality Assurance is to eliminate errors and rework proactively, and to produce quality Deliverables efficiently. A close partnership between NMPED and its partners helps reduce the possibility of surprises that negatively affect tasks and Deliverables.

The approach to Quality Assurance relies primarily on defining quality and reviewing quality, as described below:

5.16.15.16.1 DDEFININGEFINING Q QUALITYUALITY

Quality begins by clearly defining the basic standards of quality performance. EdUI will accomplish this by developing Project standards and educating staff to these standards.

5.16.25.16.2 EEDUCATINGDUCATING S STAFFTAFF TOTO Q QUALITYUALITY S STANDARDSTANDARDS

Educating staff significantly reduces errors and misunderstandings. Once standards are established, all Work Team members are notified and trained in using them. All Work Teams are required to adhere strictly to the established standards.

5.16.35.16.3 RREVIEWINGEVIEWING Q QUALITYUALITY

Once quality standards are developed, these standards must be accompanied by an ongoing and comprehensive course of review. In addition to the formal review process documented in Project Planning, the QA Manager will establish an informal review process designed to assure that Deliverables meet quality standards before they reach formal review. This process involves continual monitoring by the QA Manager staff at all levels, as well as ongoing evaluation by the NM PED.

Quality reviews include self-review, joint team review, management review, and final review. Each type is discussed below:

5.16.45.16.4 SSELFELF-R-REVIEWEVIEW

Each Work Team member is responsible for his or her own work. The individual responsible for a Deliverable will use the Project Procedures Manual to evaluate the Deliverable’s readiness, measuring that specific Deliverable against the documented standards to assure that all conditions are met.

5.16.55.16.5 JJOINTOINT T TEAMEAM R REVIEWEVIEW

Project Deliverables can be reviewed in an informal walk-through by NMPED staff. Team members are chosen based on their qualifications to evaluate the specific Deliverable. The individual responsible for the Deliverable presents it to the team, who then examines it and identifies potential problems. This process will be repeated until the team is satisfied with the Deliverable.

This technique allows deficiencies to be identified and corrected early in the development process, ultimately saving time and resources. This also helps assure that NM PED personnel will have already exerted a strong influence on its form by the time a Deliverable reaches formal review.

5.16.65.16.6 MMANAGEMENTANAGEMENT R REVIEWEVIEW

All work performed on the Project is subject to various levels of review by Work Team Leads and the PMO. Work Team Leads will track the status of all items within their responsibility, checking thoroughly for accuracy and completeness.

5.16.75.16.7 FFINALINAL R REVIEWEVIEW

All these reviews build up to the formal Deliverable submission and approval process, during which the NM PED determines whether the Deliverable meets the level of quality expected. EdUI anticipates that using the techniques described above will result in the highest-quality Deliverables and, in turn, result in a higher likelihood of approval on the first submission.



5.175.17 CCONFIGURATIONONFIGURATION M MANAGEMENTANAGEMENTConfiguration Management includes the systematic evaluation, coordination, approval, disapproval, documentation, implementation and audit of all changes in the configuration of a project deliverable or work product after formal establishment of its configuration identification.

5.17.15.17.1 VVERSIONERSION C CONTROLONTROL

Each version of a Deliverable will contain a title and a revision notice sufficient to uniquely identify the document. Revision information may include the project name, version number, date of release, approval signature(s), and a list of version numbers and dates of release of all previous versions of the Plan.

All documents must be kept current with changes to maintain the integrity of the project. All approved changes must be reflected in the respective document. Changes to the product scope (features and functions) must be reflected in the definition of the project scope (the work to be done to incorporate new requirements).

5.17.25.17.2 PPROJECTROJECT R REPOSITORYEPOSITORY (P (PROJECTROJECT L LIBRARYIBRARY))The Project Library for all project related files, including project deliverables, work products, schedules, status reports, etc. will be housed in the NMPED’s secure web site for EdUI. Access to the Project Library will be granted by the Project Manager.

6.06.0 PPROJECTROJECT C CLOSELOSEProject closeout is the last major phase of a project's lifecycle. This phase is performed once all defined project objectives have been met and the customer has accepted the project's product.

Project Close-out PhaseProject closeout includes the following tasks:

• Redistribution of resources, including staff, facilities, equipment and automated systems.• Closing out any financial issues such as labor charge codes and contract closure.• Collect, complete and archive project records.• Document the success and issues of the project.• Formally close out each contract.• Conduct a “lessons learned” session.• Celebrate project success.

These activities are very important on large projects with extensive records and resources. Specific information technology processes that deal with the transition of the technical support into maintenance support is not discussed in this section. These tasks are diverse and specific to each project's environment.

6.16.1 AADMINISTRATIVEDMINISTRATIVE C CLOSELOSEAdministrative closure is the process of preparing closure documentation of the product or process deliverables to the customer as well as taking other administrative actions to ensure that the project and its assets are redistributed. Delivering closure documentation does not mean getting approval and acceptance signature on the deliverable. It involves a series of steps to ensure the product meets the customer's requirements that were defined in the Project Requirements document and approved by the customer. The Post Implementation Evaluation Report is produced in the Administrative Closure. Other areas included in administrative closure are archiving, facilities and personnel reassignment.

Closeout ProcessesJust because project closure appears at the end of the project, does not mean that all project closure activities need to be delayed until then. As each project phase is completed, it is important to conduct milestone reviews to ensure that phase activities have been completed to the satisfaction of all involved



parties. This frees the project manager and team from dealing with old action items and outdated information.

Post Implementation Evaluation Report (PIER)A Post Implementation Evaluation Report (PIER) documents the successes and failures of the project. It also provides valuable historical information of the planned and actual budget and schedule. Other selected metrics on the project may be collected using documented procedures. The report also contains recommendations for future projects of similar size and scope. Information within the PIER should include, but not be limited to, the following items:

Project sign-off. Staffing and skills. Project organizational structure. Schedule management. Cost management. Quality management. Configuration management. Customer expectations management. Lessons learned.

Defining Lessons Learned In addition to communicating the closure of a project in writing, it is also advisable to have a mechanism for group review. A lesson learned session is a valuable closure and release mechanism for team members, regardless of the success of the project. Some typical questions to answer in a lessons learned session are listed below:

Did the delivered product meet the specified requirements and goals of the project? Was the customer satisfied with the end product? Were cost budgets met? Was the schedule met? Were risks identified and mitigated? Did the project management methodology work? What could be done to improve the process?

The lessons learned session is typically a large meeting that includes the following groups: Project team. Stakeholder representation - including external project oversight. Executive management. Maintenance and operation staff.

Such sessions provide official closure to a project, as well as a forum for public recognition. These sessions offer an opportunity to discuss ways to improve future processes and procedures.

Documenting Lessons Learned One purpose of the PIER is to document lessons learned. This means that problems encountered by the project team are openly presented. Problem identification on completed projects provides a method to discuss project issues encountered in hopes of eliminating their occurrence in future projects. It is important that these discussions remain objective and professional and do not "point a finger" at a target other than the project team. Responsibility and ownership for problem identification and resolution by the team is critical for developing recommendations for future projects. The individual problems that occurred throughout the course of the project should have been presented and documented when they happened and subsequently addressed at that time. The lessons learned documented in Project Closeout is for upper management's review and action as well as to provide a valuable tool for future projects. This will help to prevent future project managers and teams from making avoidable mistakes and also lay the framework for success in other projects. Problems encountered should be prioritized with focus on the



top five to ten problems. It is not necessary to document every small event during the lifecycle of the project; however, all legitimate problems and issues should be discussed that are requested by customers or management. Due to the sensitive nature of information in the PIER, the content of the document should be reviewed by all parties included in the document prior to submitting it to the project team. It is useful to conduct the review in an interactive forum where all parties can discuss their recommendations for improvement. This enables the PIER to present a complete view of the system.

Identifying and Addressing Success Successes are just as important as problems and need to be documented on the PIER. It is also important to include new ideas that were successful in the project for future use. Make recommendations on how these success reports might be adapted for other projects. Share project successes with other organizations. In the same way problem identification can lead to improvements, successes should be translated to procedures that can be followed in future projects.

Preparing the Report Typically, the Project Manager has the responsibility to prepare the PIER report. The Project Manager obtains input from the entire team, customers, and other major stakeholders. People performing different functions on the project will have a different outlook on the successes and failures and on possible solutions. If every project member cannot be consulted, at least solicit input from all major areas of contribution. The customer's overall view of the project and its final product is also a major focus of the project. It is this view, along with the view of the major stakeholders, that lives on after closure of the project. There are other documents and processes that also need to be brought to closure as the project nears completion.

Customer Project Sign-off As stated earlier, the issue of primary importance with project closure is the acceptance of the product or project deliverable by the customer for which they were created. The best way to resolve this is to convene a final meeting with all necessary stakeholders to review the product delivered against the baseline requirements and specifications. By this time, any deviations from the established baseline will have been documented and approved but it is still good policy to make all parties aware of the baseline deviations and justifications. By conducting the meeting of all the stakeholders together in one meeting, the Project Manager avoids clearing up open issues on an individual basis. The final deliverable of this meeting should be a statement created by the Project Manager describing the project's final deliverables in comparison to the authorized project baseline documents. Approval is verified via the signature of a project closure statement by all stakeholders who signed the original project baseline document (e.g. Project Plan). This document may be customized to fit the needs of specific projects that include pertinent deliverables, key features and other important information about final project delivery.

Project Documentation All documentation that has information about the project (including design documents, schematics, technical manuals) that have not already been turned over to the operations and maintenance organizations must be completed and forwarded to the Project Manager.

Collecting Project Archive Data After the PIER document has been prepared, the project information is archived. Historic project data is an important source of information to help improve future projects. The information that is archived will vary from project to project. Typically, the following project data is archived:

Project Control Book. Project Plan - including the Project Charter, Project Scope Statement, Risk Management

Plan, and Quality Plan. Correspondence. Meeting notes. Status reports. Contract file. Technical documents.



Files, programs, tools, etc. placed under the use of Configuration Management. Any other pertinent information to the project.

Many of the technical documents and automated versions will be turned over to agency personnel responsible for maintenance and operation of the system. Summaries of technical information should be stored electronically for historical reference to facilitate later review. The project archive should include an inventory sheet and description of the files being submitted the application (including version) used to create the archived materials and a point of contact for the archived data. The project management information summary should also include a description of the project, a project organization chart, budgeted versus actual cost and budgeted versus actual schedule. Any assumptions associated with the project are also included.

Personnel and Facilities Personnel

If personnel have been applied against the project on a full time basis and the project is nearing the end, it is important to return the people back into the available resource pool quickly. This will ensure that the people stay busy and that other projects within the agency do not fall short of resources. This will also ensure closeout of the labor charge code (if necessary) used for the project.

Facilities

If the project team has occupied agency facilities for a long period of time, it is a good idea to notify the controlling facilities personnel that the space is no longer needed.

6.26.2 FFINANCIALINANCIAL C CLOSURELOSUREFinancial closure is the process of completing and terminating the financial and budgetary aspects of the project being performed. Financial closure includes both (external) contract closure and (internal) project account closure. The following sections describe some of the actions that must be taken to ensure financial closeout.

Project Account Closure

Project account closure is an internal process that formalizes the termination of a project for the staff within the agency. Without setting definitive dates and providing a formal process for closure, projects have a tendency to live past their scheduled completion date. For instance, if a termination date is not set for a project, it is possible that the project might continue indefinitely, allowing personnel to apply resources and labor against it. If this were to happen, a project would not be a project any longer, but could potentially turn into a program without a defined end date. Projects by definition have limited budgets and life-spans, so it is necessary to terminate them at some point.

Setting a Completion Date

Often projects have a completion date imposed upon them at their inception, which by nature makes that date the termination date for the project. The completion date for a project is the date that all project related activities needed to produce the product should be completed. Beyond this date, there should be no need to apply labor or resources against the project because it will have delivered or turned over to operations. Any further work done on the product beyond this date should be considered an operations and maintenance cost.

Closing Account Charge Codes

Most projects have account numbers associated with them that allow the financial departments to track labor hours and resource procurement. These labor charge codes will need to be deactivated so that no personnel may continue to charge time against the project or use the project charge codes to purchase materials, etc. Closure of the charge accounts should be formalized via written request that the Project Manager turns over to the managing financial organization.

Spreading the Word

Agency staff and management need to be told as far ahead of time as possible when the project will be coming to completion. There are a few reasons for this:



The staff applied to the project will know the date beyond which they will not be able to charge their time against and purchase resources for the project.

Management will be able to plan where their resources will be applied next after the current project is complete.

Setting a date provides a sense of urgency to resolve issues and complete activities that have been dragging on without resolution.

The termination date of the project should be included in the project schedule as well as any ongoing project documentation. Staff members should be reminded ahead of time that charge codes will become inactive on a certain date. This can be done via e-mail or whatever means is convenient to insure that the word is passed.

Process for Contract Closure Contract closure is the process of terminating contracts that outside organizations or businesses have with the agency as part of the project being performed. These contracts may be vehicles for providing technical support, consulting, or any number of services supplied during the project that the agency decided not to perform itself. Contracts can be brought to closure for variety of reasons, including contract completion, early termination, or failure to perform. Contract closure is a typical but important part of project management. It is a simple process, but close attention should be paid so that no room is left for liability of the agency.

Collect Documentation

In order to close a contract, it is important to collect all of the pertinent documentation for review. This will include all of the original contracts and supporting documentation such as schedules, contract changes, and performance reports. This documentation needs to be reviewed thoroughly to ensure that there are no unrealized contract issues that could open up legal liability. For specific methods on contract closure please refer questions to the Contract Management Division.

The Financial Audit The project audit is intended to determine where, in measurable terms, the actual costs on the project may have overrun or under-run and determine the cause of the variation. It is also an investigation into the ethical and financial responsibility of the staff involved with the project. Because many state projects are funded through state taxes and appropriations, it is imperative that all of the project members be held accountable to the highest degree of fiscal responsibility. Furthermore, the financial evaluation also provides an opportunity for project managers and agencies to learn where they can improve financially on the implementation of similar future projects.

Purpose of an Audit

A financial audit is the thorough examination of a project by an evaluation team and includes a detailed overview of the project's financial procedures, budgets, records, etc. It may deal with a project as a whole or separate part of a project. An audit may take a few hours to several months depending on the size, visibility, and the detailed information available on the project. Although financial audits can occur anytime throughout the project, the emphasis of this section is on the Closeout Phase.

Requirements

Financial project audits require quite a bit of information to make accurate assessments. This information may include, but not be limited to the following:

Budget plans (staff and resource baselines). Staff timesheets. Contracts with external organizations. Procurement guidelines. Purchase orders. Budget status reports. Change control results.

This information is evaluated by an audit team to determine if the time and resources spent on the project measurably reflect the product produced as a result of the effort.



The Audit Team

The financial audit may be performed by teams either internal or external to the organization. External teams may be selected because of their experience and impartiality. Internal teams may be selected as a result of the size of the project or the team members' knowledge of the financial guidelines of the agency. Internal teams, if used, may include members from the project team, the agency accounting department, executive management, human resources, contracts/procurement, and the legal department.

The audit team must have full accessibility to the project records and project staff to make an informed and unbiased assessment of the financial health of the project. Although accessibility to the staff may be difficult, and at times intrusive, it is important that the staff take the time to discuss the project with auditors. Care must be taken to avoid misunderstandings, and auditors must avoid comments that may be construed as critical. The auditors have a responsibility to be as fair as possible and occasionally may need to rely on their own interpretations of the data.

Project Audit Sections

A financial audit is a formal report that needs to be organized in an understandable and systematic format. It may be necessary for the audit team to develop a method for separating useful information pertinent to the project from irrelevant or distracting information. If a financial audit is done internally, the time spent should be commensurate with the amount of time actually spent on the project. Some audits will be much more detailed than others.

Once completed, the financial audit should be delivered to the project product owner or their designee. Copies may also be made available to the project manager, executive management, and as necessary in order to verify any assumptions made by the audit team or clarify any unresolved issues.

6.36.3 CCELEBRATIONELEBRATION OFOF S SUCCESSUCCESSCelebrate the success of completing a project! There is fairly universal recognition that positive reinforcement, or rewarding behavior, is an effective management tool. Because it is a goal within the state to increase the number of successfully executed projects, it is important to recognize teams that have met this goal. When success in a project is achieved, be certain to provide some recognition to the team. If individuals are singled out for significant achievements, don't forget to recognize the entire team as well.

One step of the Closeout Phase is the customer's acceptance of the system. This is a critical and important step, as the customer decides when the project is completed. Acceptance is based upon the success criteria defined in the very early concept and planning stages of the project. This acceptance may be very informal or it may be very formal, depending on the defined criteria.

What is Success?

Success is defined at the early stages of planning the project. In this project management methodology, success factors are developed as part of the Initiation Phase. Success is not tied to only budget and schedule. Many projects can be considered a tremendous success even though the project ultimately cost more than had been anticipated. Some key questions that determine success include the following:

• Were the success objectives achieved?• Do the stakeholders and customers view the project/product in a positive manner?• Was the project well managed? • Did the team work well together and know what was going right and wrong?

Informal Recognition

There are many ways to reward people for a job well done. The reward might be an informal after work gathering or a lunchtime pizza celebration.

Formal Recognition

Organization management may also want to express recognition of a successful team effort by praising the team at a key meeting or a large gathering of staff. Team members are proud to have executive management state appreciation, and such recognition sets the stage for future successful work.



Formal recognition can also be achieved through coordination with the organization for articles in industry periodicals and updating project data that is circulated to the legislature. Other options include plaques or gift certificates, should management and budget allow for such expenditures.

6.46.4 PPROJECTROJECT C CLOSELOSE--OUTOUT C CHECKLISTHECKLISTIn order to close this phase of the project it is important to make sure that all of the necessary documents that are pertinent to the particular project in question have been completed. This sub-section discusses the process of insuring that the activities have been finished, reviewed, and signed off.

Usefulness of Project Checklists A Close-out Checklist becomes a way for the Project Manager to organize and communicate tasks that should be completed prior to closing the project. Beyond serving as a communication document, use of the Close-out Checklist can also trigger completion of tasks that the project team might overlook. The checklist is a combination of an action list and a tool to verify that necessary steps have been completed. The Close-out Checklist should be organized according to the major areas of concern that will determine the project’s success. The development and use of a Close-out Checklist also provides the project team with the tools to ensure that all information has been reviewed and approved.

Project Close-out Checklist CreationThe Project Manager owns the Project Close-out Checklist, although in most projects, the full team provides input. A sample checklist can be found in Appendix 9.4.

7.07.0 GGLOSSARYLOSSARY

7.17.1 AACRONYMSCRONYMS ANDAND A ABBREVIATIONSBBREVIATIONSADS Accountability Data System

AYP Adequate Yearly Progress

CCSSO Council of Chief State School Officers

CFO Chief Financial Officer

COTS Commercial Off The Shelf

DBA Database Analyst

DBMS Database Management System

DFA Department of Finance & Administration

DSAC Decision Support Architecture Consortium

ETL Extract, transform, and load (re: data management)

GSD General Services Department

ISD Information Services Department (GSD)

ITC Information Technology Commission

LDAP Lightweight Directory Access Protocol

LEA Local Education Agency

LESC Legislative Education Study Committee

LFC Legislative Finance Committee

NAEP National Assessment of Educational Progress

NCLB No Child Left Behind



NMPED New Mexico Public Education Department

DoIT Office of the Chief Information Officer

OEA Office of Education Accountability (DFA)

PCR Project Change Request

PERA Public Employees Retirement Association

PMBOK Project Management Body of Knowledge

PMI Project Management Institute.

PMO Program Management Office

PMP Project Management Plan

QAP Quality Assurance Plan QM Quality Management

RFP Request For Proposal

SEA State Education Agency

SIF Schools Interoperability Framework

SIS Student Information Management System (SIS)

SME Subject Matter Expert

SoNM State of New Mexico

SPD State Purchasing Division

STARS Student, Teachers Accountability Reporting System

WAN Wide Area Network

WBS Work Breakdown Structure

XML Extensible Markup Language

7.27.2 DDEFINITIONSEFINITIONSAcceptance 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]

Architecture – a set of standards, guidelines, and statements of direction that constrain the design of information technology solutions for the purpose of eventual integration.

Assumption - refers to a condition or an event that must exist or occur in order for the project schedule and the project costs to be met as documented in the project charter.

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

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

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 – Consists of the development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur.

Database - A structure and efficient mechanism for the storage, description and management of discrete data elements and bodies of Agency information.

Data Element – A discrete category of data, e.g. “age,” “ethnicity,” “test score.”

Data Managers - The individual owners/care takers of the individual systems of record.

Data Warehouse – A centralized source of key Agency data drawn from various Systems of Record and brought together for the purposes of data integration in line with the Agency’s analysis and reporting requirements.

Deliverable - A specific product or event that is to be produced by a project. Examples include such things as a training session, a document, a software product, a process definition, etc. Deliverables are intended to align with and produce the desired results expected from a project.

Dependencies - Other projects, efforts, groups, processes and/or standards that are related to, that affect, or may be affected by, the project being planned.

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

Extract, Transform, and Load (ETL) – The process and IT tools employed to draw out (extract) data from Source Systems, to systematically alter the data (transform) to conform with the database structure of the Data Warehouse, and to deposit (load) that data into the warehouse.

Governance (as related to data)– A combination of policy, organizational roles and responsibilities, committee and team charters, and job descriptions that collectively describe how decisions are made, monitored and enforced regarding the management of the department’s data.

Infrastructure - The backbone of IT delivery, the networks, communication services, operating systems, servers, desktops, and related platforms, products and services that provide IT capabilities to the end user.

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

Metadata - Data about the data, including: descriptions of what kind of information is stored where, how it is encoded, how it is related to other information, where it comes from and how it is related to our business.

Milestone - A major event in a project’s schedule that is easily identifiable by such things as the completion of a significant deliverable, the occurrence of an event, etc.

Process - A structured method focused on obtaining desired results. It is any activity or group of activities that takes an input, adds value to it, and provides an output to an internal or external customer.

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

Program Management Office - An organizational entity responsible for management and oversight of the organization’s projects.

Project Charter – The document that describes the project in terms of its scope, schedule, assumptions and resources. It facilitates project planning and approval. It also establishes a high level of understanding between the sponsor and the rest of the project team to help ensure a project’s success.

Project Manager – the person responsible for the day-to-day direction of a project, under the direction of the sponsor. The project manager develops and maintains the Project Charter and detailed plan. The project manager executes the project according to the Charter and Detailed Plan, conducts work reviews for all significant deliverables, identifies and tracks issues, manages the project budget, and ensures the quality of the deliverables.



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 Management Plan - A formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and documents approved scope, cost, and schedule baselines. The Project Management Plan (PMP) is a project plan.

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

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

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

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

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

Risk - Possibility of suffering loss.

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

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

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

Scope - A description of the work to be performed in terms of the desired results and deliverables.

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

Source System – Typically a transactional IT system, such as a financial, human resources, student information, or assessment management system.

Sponsor – The individual within the organization who has the highest level of authority and responsibility for the success of a project (oversees the project manager). The sponsor is responsible for ensuring that the project, its desired results and specific outcomes are successfully delivered.

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

Stakeholder - Individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results.

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

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]

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



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.



8.08.0 AAPPENDIXPPENDIX8.1 Deliverable Acceptance Form

8.2 Project Schedule

8.3 Change Request Form

8.4 Project Close-out Checklist



AAPPENDIXPPENDIX 8.1 D 8.1 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE F FORMORM

Deliverable Specification (Sample)Date: January 3, 2006

To: Austin Buff, NMPED Project Manager

From: Andy Hutton

Subject: Deliverable Specification for Demonstrate Operational Prototype

This memo serves as the Deliverable Specification for the Demonstrate Operational Prototype. Please review the sections below and indicate your approval by signing in the space provided.

Identification: Title: Demonstrate Operational Prototype

Projected Delivery Date: January 3, 2006

Lead Individuals: Alan Hartwig

Estimated Size: 2 pages

Copies Needed: 1

Desc ription: The purpose of the Operational Prototype is to demonstrate the potential capabilities of the STARS system using operational data provided by the NM PED. The data was loaded into the eScholar data warehouse. Reports were developed with the Cognos decision support suite to display AYP, State Report Card, Teacher and Financial data analysis.

Acceptance Criteria: This Deliverable will be acceptable when the agreed upon AYP, State Report Card, Teacher and Financial reports are satisfactorily demonstrated utilizing the State data loaded into the data warehouse.

Approval to Proceed:

Austin Buff, NMPED Project Manager Date



NMPED EdUI ProjectDeliverable Acceptance Form (Sample)

Deliverable Title:

Delivery Date:

Delivered By:

Received By:

Acceptance Due Date:

Date Accepted:

Accepted By:



AAPPENDIXPPENDIX 8.2 P 8.2 PROJECTROJECT S SCHEDULECHEDULEThe full EdUI Implementation Project Schedule can be found on the EdUI Implementation e-room documentation library.



AAPPENDIXPPENDIX 8.3 C 8.3 CHANGEHANGE R REQUESTEQUEST F FORMORMThe NM PED will identify their decision on the CRF form, a sample of which follows:

Change Request Form (CRF) Form (Sample)

COR Number:

COR Title:

Initiator Name: Request Date:

Change Order Description (Please use extra pages if required or use this as a cover page and attach a separate document):

Disposition: Accept

Reject

By: Date:



AAPPENDIXPPENDIX 8.4 P 8.4 PROJECTROJECT C CLOSELOSE--OUTOUT C CHECKLISTHECKLISTProject Close-out Transition Checklist The format of the Project Close-out Checklist can be whatever the project team defines, but it usually resembles more of an outline than a dissertation. It could be a single line item with space provided for the person to list the current status of an item. Sample answers might be:

• Y = Item has been addressed and is completed.• N = Item has not been addressed, and needs to be in order to complete the process.• N/A = Item has not been addressed and is not related to this project.• P = Item has been addressed and some issue resolution is needed to complete the item.

If the item status information is modified, then the person responsible for the Close-out Checklist should ensure that the information is given to the full project team for use. Each item on the Close-out Checklist should also have an area for comments and should note plans to resolve “N” or “P” entries.

Project Name: Date:Modification Dates:Prepared by:

1 Post Implementation Evaluation Report (PIER)1.1 Document lessons learned.

1.2 Document project success.

1.3 Complete the PIER report form.

1.4 Review the report with stakeholders.

1.5 Obtain project sign-off.

2 Archive Project Information2.1 Gather all project information.

2.2 Archive information in project repository.

2.3 Store all hard copy records in designated area.

2.4 Release any personnel or facilities.

3 Financial Closure3.1 Close any account charge codes.

3.2 Notify team members and stakeholders of closure date.

3.3 Perform contract closure.

3.4 Conduct final audit.

4 Celebration of Success4.1 Recognize the successes.

4.2 Recognize team members.

4.3 Celebrate!



This page left intentionally blank.

End of Document


share software selection - e… · web view23/07/2008 · project management plan. executive...

Documents