STARS OPERATIONAL SUPPORT
PROJECT PLAN
EXECUTIVE SPONSORS
PUBLIC EDUCATION DEPARTMENT
PROJECT DIRECTOR – ROBERT PIRO
ORIGINAL PLAN DATE: JULY 25, 2007
REVISION DATE:
REVISION:
STARS Operational Support Project Management Plan
TABLE OF CONTENTS
About this Document..................................................................................................... iii
Revision History ............................................................................................................ iv
1.0 Project Overview ....................................................................................................... 5
1.1 INTRODUCTION ......................................................................................................................... 5
1.2
CURRENT STATE ................................................................................................................ 5
1.3
FUTURE STATE ................................................................................................................... 5
1.4 PROJECT JUSTIFICATION .......................................................................................................... 6
2.0 Operational Support Scope ..................................................................................... 6
2.1
MAINTENANCE, LICENSE, AND HOSTING .............................................................................. 6
2.2 OPERATIONAL SUPPORT........................................................................................................... 6
2.3 TRAINING ................................................................................................................................. 7
2.4 PROJECT OBJECTIVES.............................................................................................................. 7
2.5 DELIVERABLES......................................................................................................................... 7
2.4 WORK BREAKDOWN STRUCTURE (WBS) ................................................................................ 11
3.0 Operational Support Strategy ................................................................................ 11
3.1 CRITICAL SUCCESS FACTORS ................................................................................................. 11
3.2 PROJECT LOGISTICS .............................................................................................................. 12
3.3 TECHNICAL STRATEGY ........................................................................................................... 12
4.0 Project Organization ............................................................................................... 12
4.1 STAKEHOLDERS ..................................................................................................................... 12
4.2 CUSTOMERS .......................................................................................................................... 13
4.3 PROJECT TEAM ...................................................................................................................... 13
4.4 PROJECT GOVERNANCE PLAN ................................................................................................ 18
5.0 Project Management and Controls ........................................................................ 18
5.1 MANAGEMENT CONTROL PROCEDURES ................................................................................... 19
5.2 STANDARDS AND GUIDELINES ................................................................................................. 29
5.3 DOCUMENTATION LIBRARY ..................................................................................................... 29
5.4 PROJECT MANAGEMENT SYSTEM ............................................................................................ 30
5.5 MEASURING AND EVALUATING PERFORMANCE ........................................................................ 30
5.6 CORRECTIVE ACTION PLAN..................................................................................................... 30
5.7 PRIMARY ASSUMPTIONS ......................................................................................................... 31
5.8 CONSTRAINTS ........................................................................................................................ 31
5.9 DEPENDENCIES ...................................................................................................................... 31
Initial Release
i
July 25, 2007
STARS Operational Support Project Management Plan
5.10 PROJECT TIMELINE............................................................................................................... 32
5.11 PROJECT BUDGET ................................................................................................................ 33
5.12 COMMUNICATIONS ................................................................................................................ 34
5.13 QUALITY OBJECTIVES AND CONTROL .................................................................................... 37
5.14 CONFIGURATION MANAGEMENT ............................................................................................ 38
5.15 INDEPENDENT VERIFICATION AND VALIDATION (IV&V)............................................................ 39
6.0 Operational Support Staffing Planning ................................................................. 39
6.1 CORE TEAM ASSIGNMENTS ..................................................................................................... 39
6.2 DISTRICT RESOURCE REQUIREMENTS ..................................................................................... 39
7.0 Project Close ........................................................................................................... 43
7.1 ADMINISTRATIVE CLOSE ......................................................................................................... 43
7.2 FINANCIAL CLOSURE .............................................................................................................. 46
7.3 CELEBRATION OF SUCCESS .................................................................................................... 48
7.4 PROJECT CLOSE-OUT CHECKLIST ........................................................................................... 49
8.0 Glossary .................................................................................................................. 50
8.1 ACRONYMS AND ABBREVIATIONS ............................................................................................ 50
8.2 DEFINITIONS........................................................................................................................... 51
9.0 Appendix ................................................................................................................. 54
APPENDIX 9.1 DELIVERABLE ACCEPTANCE FORM ......................................................................... 55
APPENDIX 9.2 PROJECT SCHEDULE .............................................................................................. 57
APPENDIX 9.3 CHANGE REQUEST FORM ....................................................................................... 58
APPENDIX 9.4 PROJECT CLOSE-OUT CHECKLIST ........................................................................... 59
Initial Release
ii
July 25, 2007
STARS Operational Support Project Management Plan
ABOUT THIS DOCUMENT
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, 2007
STARS Operational Support Project Management Plan
REVISION HISTORY
Revision
Number
Initial Release
Date
Comment
July 25, 2007
Initial Release
iv
July 25, 2007
STARS Operational Support Project Management Plan
1.0 PROJECT OVERVIEW
1.1 INTRODUCTION
NMPED 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.
1.2 CURRENT STATE
STARS development and roll-out is complete. For SY2007 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. FY2006 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. SY2007 Special Educations performance indicators are being calculated and
reported utilizing STARS. Finally, FY2007 AYP is currently being loaded and calculated in STARS
(estimated completion Aug 1, 2007).
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.3
FUTURE STATE
New Mexico’s STARS is providing many benefits for education management by using data to:
 Improve student performance information.
 Influence decision making.
 Identify specific areas for improvement.
 Enhance budgetary control.
 Examine relationships between cost and effectiveness.
 Improve administrative time management and mandated reporting.
 Inform parents and citizens about student progress and school quality.
Due to the status of STARS being in full production mode, NMPED is now focused on enhancing STARS
and will focus on providing the system users with the additional tools and training necessary to make
more effective use of the readily available data and reports.
Initial Release
5
July 25, 2007
STARS Operational Support Project Management Plan
1.4 PROJECT JUSTIFICATION
The No Child Left Behind Act (NCLB) represents probably the most significant federal education policy
initiative of the last 40 years. It passed Congress with overwhelming bipartisan support, was signed into
law by President Bush early in his first term, and has since been attended to by states in a way not seen
since the mid-1970s, when states rose to the challenge of implementing Public Law 92-142 (the
Individuals with Disabilities Education Act – IDEA) and Title IX of the Educational Amendments of 1972,
which prohibited discrimination based on gender.
NCLB builds on the accountability and assessment requirements of its predecessor, the 1994 Elementary
and Secondary Education Act (ESEA), and mirrors, in many ways, the general direction of states’
education policy initiatives over the past decade. However, as noted by the Education Commission of the
States in their recent publication, Report to the Nation: State Implementation of the No Child Left Behind
Act, NCLB differs from past initiatives in two important ways:
1. It represents a more systematic approach to achieving reform and improvement, tying
together a variety of requirements and incentives in areas ranging from student testing,
school safety, and reading instruction to professional development for teachers and technical
assistance to low-performing schools.
2. It significantly raises the stakes – for states, districts, and schools – for failure to make
steady, demonstrable progress toward improving student achievement.
As such requirements of the new law are much more specific than what was presented in the 1994
ESEA. For example, NCLB sets deadlines for states to develop annual assessments aligned to state
standards and to use achievement on these tests as the primary measure of district and school
accountability. Assessments must include all students, and test results must include individual student
scores and be reported by race, income, and other categories to measure not just overall trends but gaps
among, and progress of, various subgroups of students. This will require technology capable of
producing disaggregated data and tracking students across time.
2.0 OPERATIONAL SUPPORT SCOPE
As detailed in previous Project Plans, to adhere to federal 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.
The appropriation will be divided into two parts:
2.1 MAINTENANCE, LICENSE, AND HOSTING
During the FY2007 Appropriation Cycle NMPED requested operational budget to fund the annual
maintenance, License, and hosting fees for STARS. During the appropriation cycle this request was
denied. This section of the appropriation will be used to pay those fees, estimated at $900,000.
2.2 OPERATIONAL SUPPORT
Also in the FY2007 Appropriation Cycle NMPED requested operational budget to transfer the four term
employees that were designated in HB2 for STARS development into a STARS support operational
position. This request was also denied. A portion of the remaining appropriation will be used to fund
these term position as internal operational support.
The remaining 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:
 District/Charter Level Submission Support
 District/Charter Level Reports and Cube Development
Initial Release
6
July 25, 2007
STARS Operational Support Project Management Plan


Design and development of a Proof of Concept for the Statewide Education User Interface to
provide PED and districts with the tools to communicate, collaborate, and mange content and
data across the state.
Design, develop, and implement STARS security and user provisioning. As STARS is roll-out to
more and more users, Access control will be a major component of the STARS security strategy.
STARS security and user provisioning will develop and implement a plan to mange the access to
confidential student, staff and financial data.
2.3 TRAINING
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.4 PROJECT OBJECTIVES
THE GOALS AND OBJECTIVES OF THE STARS OPERATIONAL SUPPORT:
 Finalize the state-wide the data dictionary and STARS Users Manual.
 Confirm that the all districts and PED are capable of performing the data collection and transmittal
from legacy systems into STARS.
 Support 40th, 80th, 120th, and end of year submission of district specific data into STARS.
 Provide stakeholders with detailed STARS user education and training.
 Develop and promote the Statewide Education User Interface
 Develop and Promote the STARS Security and User Provisioning Model
2.5 DELIVERABLES
M AINTENANCE, LICENSING, AND HOSTING DELIVERABLES
STARS PD034 – M AINTENANCE, LICENSING, AND HOSTING CONTRACT EXTENSION
Description – Upon
completion of the negotiation
of the Contract Addendum
required to extend the
original contract, this
deliverable will be
considered complete.
Initial Release
Deliverable Acceptance Criteria – This document will be
considered acceptable when it has met the approvals of the
NMPED’s Project Director, the consulting partner’s Project
Director, the Project’s executives (sponsors) and the Information
Technology Commission (ITC) Project Certification Committee
(PCC).
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).
7
July 25, 2007
STARS Operational Support Project Management Plan
STARS PD035 – OPERATIONAL SUPPORT PROJECT PLAN
Description – This
document will serve as the
initial Project Plan for the
project. Upon completion of
the contract negotiation for
the external support
services, the deliverable
section will be updated
based on actual contractual
deliverables. After update,
this project plan will serve to
monitor the status of
completion.
Deliverable Acceptance Criteria – This document will be
considered acceptable when it has met the approvals of the
NMPED’s Project Director, the consulting partner’s Project
Director, the Project’s executives (sponsors) and the Information
Technology Commission (ITC) Project Certification Committee
(PCC).
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.
STARS PD036 – DISTRICT SUPPORT DELIVERABLE
Description – TBD &
updated when contract
signed.
Deliverable Acceptance Criteria – TBD
Enhance district data quality
and reporting.
Quality Review – The periodic QA and IV&V reviews will monitor
the quality of the pilot and associated deliverables.
Standards for Content and Format – TBD
STARS PD037 – STATEWIDE EDUCATION USER INTERFACE
Description – TBD &
updated when contract
signed.
Deliverable Acceptance Criteria – TBD
Statewide Education User
Interface (proof of concept at
a minimum)
Quality Review – The periodic QA and IV&V reviews will monitor
the quality of the pilot and associated deliverables.
Standards for Content and Format – TBD
STARS PD038 – STARS SECURITY AND PROVISIONING MODEL
Description – TBD &
updated when contract
signed.
Deliverable Acceptance Criteria – TBD
Statewide security
enhancements.
Quality Review – The periodic QA and IV&V reviews will monitor
the quality of the pilot and associated deliverables.
Standards for Content and Format – TBD
DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS
DELIVERABLE
NUMBER
Initial Release
APPROVERS (WHO
CAN APPROVE)
DELIVERABLE
8
DATE
APPROVED
July 25, 2007
STARS Operational Support Project Management Plan
DELIVERABLE
NUMBER
STARS - PD034
STARS - PD035
APPROVERS (WHO
CAN APPROVE)
DELIVERABLE
Maintenance, Licensing, and
Hosting Contract Extension
Operational Support Project
Plan
DATE
APPROVED
Project Sponsor
Key Stakeholders
Project Sponsor
Key Stakeholders
Project Sponsor
Key Stakeholders
STARS - PD036
District Support deliverable
STARS - PD037
Statewide Education User
Interface
Project Sponsor
STARS - PD038
STARS Security and
Provisioning Model
Project Sponsor
Key Stakeholders
Key Stakeholders
DELIVERABLE SPECIFICATION, PREPARATION, AND APPROVAL
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 Management Office. Once
completed, the Deliverable Specification is forwarded to the Project Management Office for review,
comment, and approval. The approved Specification then serves as the Team’s “road map” for preparing
the Deliverable.
After receiving approval of its Deliverable Specification, the Work Team may further define the content
and format for its Deliverable by preparing a template and/or sample. The creator will present these
templates and samples to the NM PED for review and approval early in the Deliverable preparation
process. These templates and samples are intended to establish a common understanding and
expectation for 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 NM PED 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.
Initial Release
9
July 25, 2007
STARS Operational Support Project Management Plan

Approval to Proceed. Provides a space for the NM PED 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.
STEP 2: DELIVERABLE PREPARATION
Two sub-steps are involved in Deliverable Preparation—interim deliverable reviews and structured walkthroughs.
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 NM PED’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. By soliciting preliminary feedback from the NM PED, Deloitte
Consulting should be able to expedite the final approval process.
STRUCTURED WALK-THROUGHS
In the structured walk-through, the creator will conduct a narrated review of the Deliverable as it turns the
document over to the NM PED for detailed review and approval. This is designed to provide an
orientation to the Deliverable, which will facilitate the NM PED’s final review. Any aspects of the
Deliverable requiring further clarification should be discussed at this time.
STEP 3: DELIVERABLE SUBMISSION AND APPROVAL
All Project Deliverables will be submitted to the NM PED 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. (A sample Deliverable Acceptance Form is included at the end of
this MCP.)
The Deliverable Specification will guide the NM PED to determine whether the Deliverable is complete,
accurate, and acceptable.
The NM PED Project Manager will issue the NM PED’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 NM PED Contract Manager will meet with the creator to discuss the
reasons for rejection and to set in motion the rework process.
The NM PED 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 NM PED will prepare a list of deficiencies for the creator to address. The creator will
then meet with the NM PED Project Manager to clarify these deficiencies. Deloitte Consulting will then
integrate the NM PED’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 NM PED Project Manager will then indicate the NM PED’s acceptance in writing or will arrange a
meeting with the creator to discuss further changes.
Initial Release
10
July 25, 2007
STARS Operational Support Project Management Plan
2.4 WORK BREAKDOWN STRUCTURE (WBS)
Reference the STARS Project Schedule for dependencies, durations, resources and further details. The STARS
Project Schedule can be found in Appendix 8.2. The following table summarizes the project’s major milestones and
deliverables.
Major Milestones
Baseline Due
Date
Deliverable
NMSBA Results from Vendor
July, 2007
Calculate SY2007 AYP Designations
July, 2007
Publish 2007 AYP Designations
Actual
Deliverable
Date
Status
August 3, 2007
Publish 2007 State Report Card
August 15, 2007
2007 State Report card
Communicate Data Template Changes to
Districts
Aug 15, 2007,
Conduct SY2008 Data Conference
October 2, 2006
STARS SY2008 Set-up
Sept 15, 2007
Load PED Financial/Licensure Data
September, 2007
Load 40th Day District Data
October, 2007
Determine SY2008 SEG
November, 2007
Load 80th Day District Data
December, 2008
Calculate and Report SY2008 HQT
December, 2007
Load 12/1 SPED District Data
December, 2007
Complete SY2008 SPED EDEN Data
Feb, 2008, 2007
Load 120th Day District Data
March, 2008
End of Year District Data
June, 2008
3.0 OPERATIONAL SUPPORT STRATEGY
3.1 CRITICAL SUCCESS FACTORS
Initial Release
11
July 25, 2007
STARS Operational Support Project Management Plan
The following Success Factors have been identified as Critical in order for the Operational Support of
STARS to be successful:

Team members need to be empowered in order to make:
o Technical Decisions.
o Creative Decisions.

Knowledge Transfer must be an integral part of the project so that NMPED and district staff is
capable of supporting and maintaining STARS.

A data management and governance process must be enforced by NMPED in support of the
STARS Project.

The STARS Project must continue to support other NMPED initiatives dependent upon
financial, human resources, and procurement data.

NMPED will need to update the policies and procedures required to support STARS. This
includes defining organizational roles and responsibilities.
3.2 PROJECT LOGISTICS
In 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.3 TECHNICAL STRATEGY
The selected solution meets the technical objectives of NMPED. It is the intent of the pilot to be in
operation in the eScholar Hosting facility. The system administration personnel (platform administration)
will be located at NMPED. The present direction is to locate the application software, database
administration, and security administration personnel at NMPED.
STARS is not being developed on a proprietary operating platform and network. STARS is utilizing
existing State of New Mexico assets, standards and guidelines, including those that reside at the district
level. STARS’ technical objective to utilize existing assets will include, but not limited to, utilization of the
existing State communications network; optimizing use of State Portal (MAGPortal and SHARE); adhering
to existing database and LDAP standards;
4.0 PROJECT ORGANIZATION
4.1 STAKEHOLDERS
Initial Release
12
July 25, 2007
STARS Operational Support Project Management Plan
NAME
STAKE IN
PROJECT
ORGANIZATION
TITLE
Veronica Garcia
Sponsor
NMPED
Secretary
Robert Piro
Project Director
NMPED
Asst. Secretary / CIO
Daryl Landavazo
Project Manager
NMPED
IT Director
Manu Patel
Oversight
LFC
Deputy Director
Pauline Rendoni
Oversight
LESC
Deputy Director
Catherine CrossMaple
User/Oversight
NMPED
Deputy Secretary
Don Moya
User/Oversight
NMPED
Deputy Secretary
Patricia Parkinson
User
NMPED
Asst. Secretary
Carlos Martinez
User
NMPED
Asst. Secretary
Elizabeth
Gutierrez
Observer
HED
P-20 Education Policy
Advisor
Kurt Steinhaus
Observer
Governor’s
Office
Governor’s Education
Polity Advisor
Peter Winograd
User
OEA
Director OEA
Mike Baca
Observer
OCIO
OCIO Consultant
Superintendent’s
Advisor Committee
User
Local Education
Agencies
4.2 CUSTOMERS
All 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.3 PROJECT TEAM
Initial Release
13
July 25, 2007
STARS Operational Support Project Management Plan
4.3.1 PROJECT TEAM ORGANIZATIONAL BREAKDOWN STRUCTURE
ORGANIZATIONAL CHART
The State’s STARS Project Team will consist of the following STARS 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.
S.T.A.R.S
Project Sponsor
Dr. Veronica Garcia
IV & V
PDS Services
S.T.A.R.S
Executive Steering Committee
S.T.A.R.S Project Director
Robert Piro - PED
Phil Benowitz - Deloitte
Catherine Cross-Maple
Don Moya
Pauline Rendoni
S.T.A.R.S Project Manager
Daryl Landavazo - PED
Alan Hartwig - Deloitte
Quality Assurance
Mitch Johnson
Data Dictionary
David Gross
Brian Hendrix
Data Warehouse
Team Lead
Tim Garrison
Training
Team Lead
Ashish Desai
Karkit Rathore
ETL
Team Lead
Susan Holden
Content Advisors
Rick Rozelle
William Wanker
Roy Soto
Christine Chavez
Content Advisors
Phyllis Bustamanti- PED
Minerva Carrera- PED
PED DBA
Kate Cleary
PED Business
Analysis
Jarad Vigil
Technical
Support
TDB
SME
Team Members
DISTRICT Represetatives
STARS Organization Structure
4.3.2 PROJECT TEAM ROLES AND RESPONSIBILITIES
Conducting a system improvement project, like the STARS 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:
Initial Release
14
July 25, 2007
STARS Operational Support Project Management Plan






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
STARS 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.
STARS Project Director
Roles 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.
STARS Project Manager
Roles and Responsibilities
Initial Release
15
July 25, 2007
STARS Operational Support Project Management Plan
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.
Team Leads
Roles and Responsibility
The Team Leads are organizational leaders, responsible for the evaluation and integrating the functional
requirements into cross-functional Business processes. They will report to the Project Manager and are
responsible for the coordination of the over-all management of the project activities as they relate to their
individual core processes. Team Leaders are selected for the team because of their understanding of
business processes and awareness of industry best practices within business flows. 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:
 Integration of data and functional requirements into cross-functional business processes.
Initial Release
16
July 25, 2007
STARS Operational Support Project Management Plan







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
Team Leads 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 process workshops, process flow
documentation, requirement definition workshops, test script development, vendor
demonstration and selection.
 Provide cross-organizational input to the Team Leads.
 Participate in the completion of project activities through design, selection, pilot and package
training sessions.
 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 Consultants
External 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.
Initial Release
17
July 25, 2007
STARS Operational Support Project Management Plan



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.
OTHER OUTSIDE SUPPORT
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.4 PROJECT GOVERNANCE PLAN
The NMPED has organized the STARS 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 Team Leads 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.
To facilitate the knowledge transfer to PED personnel and to relieve Deloitte of administrative tasks, PED
will assume responsibility for the execution of the STARS Pilot and Implementation Help Desk. The
STARS Help Desk will be based on the following structure:
Help Desk
Level 1
Level 2
Level 3
Resp
Freq
PED
PED
D
All
All/As Requested
As Requested
All incoming help desks request will be forwarded to the STARS Help desk Coordinator to be logged and
if applicable solved by Level 1 resources. If the level one resource can not resolve the issue, the issue
will be escalated to the Level 2 resources. The Level 2 resources will consist of the PED technical team.
Only those issues that can not be resolved by the PED team will be forwarded to the Deloitte team for
resolution.
5.0 PROJECT MANAGEMENT AND CONTROLS
Initial Release
18
July 25, 2007
STARS Operational Support Project Management Plan
Using 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.
The tools used to control the Project include:







Management Control Procedures;
Standards and Guidelines;
Documentation Library;
A Project Management System;
Change Control;
Measuring and Evaluating Performance; and
Corrective Action Plans.
The following sections discuss these Project controls in detail.
5.1 MANAGEMENT CONTROL PROCEDURES
To maximize consistency across all tasks a variety of Management Control Procedures will be developed
and published throughout the life of the Project. A Management Control Procedure (MCP) defines the
approach to addressing core Project activities. These MCPs also generally provide for the management
signoffs necessary to complete specific activities.
MCPs are developed over the course of the Project as necessary to ensure consistency. Before
beginning each new major task, the Project Management Office will evaluate the need for additional
MCPs and will develop them when necessary. Before a new MCP is published, it will be reviewed with
appropriate NM PED staff.
To maximize consistency across all phases of the Project, a variety of Management Control Procedures
will be developed and published throughout the Project. Management Control Procedures (MCPs) define
approaches to core Project activities and include the necessary management sign-off procedures to
complete these activities. The following MCPs have initially been developed for this Project:





Correspondence Tracking
Meeting Write-Ups
Issue Tracking and Resolution
Change Order Management
Risk Management
(MCP001)
(MCP002)
(MCP003)
(MCP004)
(MCP005)
MCP001: CORRESPONDENCE TRACKING
MCP001 details the procedures and controls employed to track formal written communication between
project participants.
Initial Release
19
July 25, 2007
STARS Operational Support Project Management Plan
Correspondence documents will be used to facilitate formal written communication between Deloitte
Consulting and the NM PED concerning fulfillment of the Contract. The purposes for correspondence
documents include, but are not limited to, the following:





Deliverable submissions;
Contract amendments;
Resolution of contractual issues;
Necessary interpretation of specific provisions; and
Other Project management issues.
All correspondence sent to the NM PED should be delivered to the NM PED Project Manager at the
address below:
Daryl Landavazo, Project Manager
NM PED
300 Don Gaspar
Santa Fe, New Mexico
All correspondence sent to Deloitte Consulting should be delivered to the Deloitte Consulting Project
Manager at the address below:
Alan Hartwig, Project Manager
Deloitte Consulting
2500 One PPG Place
Pittsburgh, PA 15222
All formal correspondence should be printed on each respective organization’s letterhead.
CORRESPONDENCE LOG
To maintain an audit trail of all correspondence, Deloitte Consulting will maintain a correspondence log.
This log, organized into sections by Project phase, will be kept up-to-date by Deloitte Consulting’s Project
Manager. For all correspondence submitted, the log will contain the following information:




Date sent;
Author;
Recipient; and
Brief description of correspondence.
Deloitte Consulting will maintain a hard copy log of all formal correspondence sent or received by Deloitte
Consulting. In addition, Deloitte Consulting will maintain soft copies of all correspondence sent by the
Project Management Office.
MCP002: MEETING WRITE-UPS
Before each meeting, Deloitte Consulting and the NM PED will decide whether meeting write-ups are
required and, if so, what level of detail is required. Meeting write-ups will document the meeting’s
purpose, topics discussed, agreements, issues, and parties responsible for action items. The person
responsible for preparing the write-ups will also be mutually determined prior to each meeting.
CONTENT
Depending on the reporting requirements of each meeting, the meeting write-ups may contain the
following information:
Initial Release
20
July 25, 2007
STARS Operational Support Project Management Plan
Meeting Description
Short description of the meeting’s purpose
Date
Date meeting was held
Author
Individual who drafted the summary write up
Attendees
List of attendees (including organizational unit)
Not Present
Individuals originally scheduled but absent from the meeting
Agenda
An overview of each topic discussed, in sufficient detail to provide a
non-participant with a good understanding of the discussion
Major Issues
Issues raised during the discussion
Key Points
Major conclusions and insights gained from the meeting
Action Items
Listing and description of the action items assigned during the
meeting
Individual
Responsible
Individuals responsible for each action item
Due Date
Deadline for completing each action item task
The write-ups will not contain the details of all topics discussed.
TIMING AND DISTRIBUTION
Whenever possible, meeting write-ups will be prepared and distributed within three working days of the
meeting. Write-ups will be logged and distributed by Deloitte Consulting’s Project Manager. Deloitte
Consulting will maintain copies of all meeting write-ups in the eRoom.
A template for meeting write-ups follows.
Meeting Write-Up (Template)
MEETING DESCRIPTION
DATE
AUTHOR
WRITE-UP DATE
ATTENDEES
NOT PRESENT
AGENDA
MAJOR ISSUES
KEY POINTS
ACTION ITEMS
Initial Release
RESPONSIBLE
21
DUE DATE
July 25, 2007
STARS Operational Support Project Management Plan
If no comments or disputes regarding the content of these meeting write-ups are received by the author
within five business days from the date of distribution, the author will assume that the meeting attendees
concur that this documentation accurately reflects the meeting discussion.
MCP003: ISSUE TRACKING AND RESOLUTION
The 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.
ISSUE DOCUMENTATION
The STARS 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.
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.
Initial Release
22
July 25, 2007
STARS Operational Support Project Management Plan
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).
Identify Issue &
Submit to Project
Manager
Review Issue
Is It Relevant?
Yes
Update the Issue
Log & Assign a
Priority
Review the Issue
Log
No
Can We
Resolve This
Issue ?
No
Does Issue
Raise a Risk?
Yes
Submit Change
Control
No
Yes
Issue Actions
Assigned
Close Issue &
Update Log
Issue Actions
Completed
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.
PROJECT ISSUE ESCALATION AND RESOLUTION PROCESS
Initial Release
23
July 25, 2007
STARS Operational Support Project Management Plan
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 Leader
Project 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 Director
The 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 Committee
Initial Release
24
July 25, 2007
STARS Operational Support Project Management Plan
If 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.
MCP004: CHANGE CONTROL
During 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.
CHANGE CONTROL PROCESS
Upon identification of a potential project change the following six tasks will be executed:
1. The STARS 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 STARS Project Director will formally document the
change in both the Project Plan and Project Schedule.
Initial Release
25
July 25, 2007
STARS Operational Support Project Management Plan
Throughout this process, the STARS Project Director will document the status of each proposed
change in the weekly status report and the change control log.
Team Member
Team member
identifies change,
includes description,
impact, and
recommendation via email to respective
Project Manager.
Project Management
The appropriate Project
Manager assess the need
for change and completes
the Change Request
Form.
Project Management
Change Control Board
Project Management logs
the change request and
schedules a technical team
session to identify the
impact of the change
request and then
documents it in the log. If
applicable, Change
requests will be taken to the
Change Control Board
The Change Control
Board will review
the change request
for an accept/reject
decision.
Project Manager
Both Project Managers
will document
decisions and any risks
associated with those
decisions.
CHANGE CONTROL PROCESS
CHANGE CONTROL BOARD (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.
PROPOSED CHANGE CONTROL BOARD:
STATE OF NEW MEXICO

Required:
Daryl Landavazo
Robert Piro
Mike Baca
Don Watson



Optional:
Veronica Garcia
Catherine Cross-Maple
Don Moya



CONSULTING PARTNER (S)



Required:
Phil Benowitz
Alan Hartwig
Norma Cordova



Optional:
Will Wanker
Mitch Johnson
Name 3
CHANGE PRIORITY AND CLASSIFICATION
Initial Release
26
July 25, 2007
STARS Operational Support Project Management Plan
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.
MCP005: RISK MANAGEMENT
The objective of Risk Management is to develop an effective risk management plan for identifying,
categorizing, prioritizing, and quantifying project risks, as well as selecting and executing Risk Mitigation
Strategies. In addition, it must be determined whether the implemented Risk Mitigation Strategies are
achieving the desired objective and corrective action must be provided if necessary.
Nonetheless, Deloitte Consulting recognizes that not all risk can be anticipated. As a result, we will
develop and implement a Risk Management Plan as part of the overall Project Plan. Our approach is
described below:
• Risk Identification Method: The focus of the risk identification method described here is on risks that
are known, whether or not they have yet been communicated to project management, and on unknown
risks. Risk identification must cover all key development and support areas of the project. Our risk
analysis method begins with a risk identification step, which is captured through the use of a risk
questionnaire, which was developed based on our previous project experiences and with the unique
characteristics of a project in mind.
• Risk Analysis Method: The second step of the risk management process is to analyze the information
that is gathered during the risk identification step. Analysis provides the information necessary for risk
planning. The key to risk analysis is the application of a quantifiable measure to the relatively
unstructured data that is gathered during the risk identification step. At a minimum, a risk likelihood
measurement and a risk impact measurement are determined so that each risk can be plotted (see figure
below).
Initial Release
27
July 25, 2007
STARS Operational Support Project Management Plan
• Risk Planning Method The project management team will take the results of the Risk Analysis phase
and develop a Risk Management Plan. The amount of planning will vary depending on the nature of the
risk. For example, a risk that has low likelihood of occurrence and a low impact will not have a
corresponding risk plan whereas a high likelihood, high impact risk will have a plan established. Possible
risk actions include: mitigate the risk, avoid the risk, accept the risk, and study the risk (see figure below).
A description with action items is also useful.
• Risk Tracking and Control Once the risk plan is established it is important that the plan is monitored in
an ongoing manner. The risk plan should be a living document in that the project’s exposure to the risks
will vary across time. The risk actions must be continually monitored in order to verify that the proper level
of control is being applied. The risk plan will be coordinated with the overall project work plan to create
greater awareness of the potential impact on the scheduled activities and deliverables.
• Risk Communication Risk Communication is central to the success of the risk management effort. The
project team will determine the methods used to communicate the outcomes of the risk management
process. This communication is vital feedback to participants in the identification process. Stakeholders
must have their concerns validated and be apprised of proposed actions to be taken and completed.
Initial Release
28
July 25, 2007
STARS Operational Support Project Management Plan
In the following table we provide some examples of common risk areas on large-scale implementation
projects and tools we use to mitigate them.
Risk Areas and Suggested Mitigation
Risk Mitigation
Risk Area
Risk Area: Integration Between Teams
Tools to Mitigate Risk
Management structures typically drive information up the
organization, without effectively facilitating communication
between teams.
Conduct cross-team status meetings and project integration
workshops.
Individual teams have a tendency to focus on their specific
objectives, as opposed to balancing the common objectives
of the project.
Project infrastructure frequently provides for little crossteam issues identification and resolution.
Reinforce overall project goals in assessing team performance
and managing status meetings.
Identify resources whose responsibilities focus on integration.
Develop a central issue tracking process and system that
prioritizes integration issues.
Risk Area: Planning and Management Measurements
Tools to Mitigate Risk
Stress project costs, time tracking, and work planning at
extremely low levels of detail without focusing on
deliverables.
Develop work plans that are linked to deliverables and provide
an accurate assessment of resource requirements and
completion dates.
Stress high-level milestones without sufficiently planning
that assess resource requirements or accurate milestone
forecasting.
Test resource and timing forecasts when deliverables are due.
Lack of focus on the most pertinent issues, where team
members deliberate overall issues.
Integrate issues management into project management status
meetings, focusing teams on issues that have the greatest
impact on the overall project.
Risk Area: Vision, Sponsorship, and Leadership
Tools to Mitigate Risk
Unclear purpose for overall project mission or specific team
goals.
Document, present, and publicize project mission, objectives,
and value.
Lack of public commitment from senior executives, where
project successes and issues are not fed back to the team.
Help ensure senior executives are visible during major project
activities, where executives provide status of project progress
against business goals.
Lack of leadership that provides a focus on the most
pertinent tasks, issues and deliverables.
Establish strong leaders at all project management levels that
provide an integrated and consistent project message.
Risk Area: Project versus Organization
Tools to Mitigate Risk
Communications limited to project team members.
Staff project team with people in the organization who will later
hold line positions after the solution is implemented.
Isolation of project members from people in the organization
that will be impacted by the project’s implementation.
Lack of involvement of line staff members.
Assign line staff as advisors, on a part-time basis, where they
play some role in designing “the solution”.
Communicate project highlights and progress to the
organization.
Sell project accomplishments to the key leaders in the
organization during project milestones.
5.2 STANDARDS AND GUIDELINES
To maximize the consistency of all documentation and software produced throughout the Project, a
number of Standards and Guidelines (S&Gs) may be developed. An S&G document defines the system
documentation or software standards to which a Work Team member must adhere when performing
activities associated with such items. The various S&G documents that may be developed and published
over the life of the Project include:



Report Format Standards;
Standard Program Specifications; and
Data Modeling.
Before an S&G document is published, the appropriate NM PED staff will review it.
5.3 DOCUMENTATION LIBRARY
To control all Deliverables and Project documentation, a documentation library will be established. The
Deloitte Consulting Project Manager is responsible for managing all documents stored in this library. To
provide the proper audit trail for all documents related to particular Project Deliverables, separate folders
will be established for each Deliverable.
The documentation library will be implemented through the use of an electronic repository referred to as
the eRoom.
Initial Release
29
July 25, 2007
STARS Operational Support Project Management Plan
5.4 PROJECT MANAGEMENT SYSTEM
A Project Management System will be implemented to support all Work Teams with accurate and up-todate information. This System is used to track and monitor various information related to the Project. All
Work Team members will have access to the System to support various day-to-day Project activities. The
system will be implemented through the use of an eRoom electronic repository.
5.5 MEASURING AND EVALUATING PERFORMANCE
Performance 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-throughs of all Deliverables
are required to verify that all acceptance criteria are met and product quality is maintained. (Deliverable
walk-throughs 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.6 CORRECTIVE ACTION PLAN
The 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) and attributed solely to Deloitte Consulting, 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.
Initial Release
30
July 25, 2007
STARS Operational Support Project Management Plan
5.7 PRIMARY ASSUMPTIONS
NUMBER
TITLE
DESCRIPTION
STARS – AS1
Project buy-in
STARS – AS2
Availability
STARS – AS3
Decision
Making
STARS – 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.
STARS – AS5
Team
Participation.
Project Team members will be assigned and allowed to
spend the proper amount of their time to complete tasks
within a reasonable timeframe.
Pilot District participation and buy-in.
Project team members will have adequate time for project
planning activities.
Project management will make decisions in a timely
manner to support the project schedule.
5.8 CONSTRAINTS
Number
Description
STARS – C01
Decisions not made in timely manner.
STARS – C02
Funding at $2.5M.
STARS – C03
Staff participation.
STARS – C04
Qualified staffing to perform project tasks.
5.9 DEPENDENCIES
M ANDATORY DEPENDENCIES (IMPOSED BY OTHERS)
Number
Description
STARS – MD01
Periodic ITC reviews.
STARS – MD02
Periodic IV&V reviews.
STARS – MD03
Periodic Funding Requests.
DISCRETIONARY DEPENDENCIES (IMPOSED ON SELF)
NUMBER
DESCRIPTION
None
.
Initial Release
31
July 25, 2007
STARS Operational Support Project Management Plan
EXTERNAL DEPENDENCIES
NUMBER
STARS – ED01
STARS – ED02
DESCRIPTION
Districts participate and buy in to the objectives of the STARS project.
Consulting Partner fulfills all project tasks and deliverables on time.
5.10 PROJECT TIMELINE
The below timeline chart depicts the tasks associated with the operational support activities for STARS.
STARS Summary Project Schedule
The detailed project schedule can be found in Appendix 8.2 – Project Schedule
Initial Release
32
July 25, 2007
STARS Operational Support Project Management Plan
5.11 PROJECT BUDGET
The following table reflects the total budget for the Pilot and Implementation Phase of the project. The
budget will be updated monthly to reflect the financial status of the project.
Project Element
Salaries and Benefits
Contractual Services
Phase 0 - Procure
PM
Content
Procure
IV&V
Prototype Deliverables
Demonstrate Operational Prototype
Establish Hosting Facility
Full Prototype Deployment
Prototype Acceptance
Phase 1 - Data warehouse
PM
Content
FY2005
$0
FY2006
$462
FY2007
$0
FY2008
$395
$485
$160
$72
$96
$200
$150
$75
$75
$75
$348
$100
$418
$811
$200
$120
$65
IV&V
Phase 1 - Data Warehouse Build Deliverables
Training
Pilot Train and Change Mngt.
Pilot Implementation
Unique ID
State-wide Rollout
$50
$100
$1,233
$425
$1,558
Phase 1 Operational Support
Load Licensure Data
$450
$300
$475
$350
District Submission Support
Report Development
Education and Training
Phase - State Education Interface
Maintenance, License, Hosting
Load Financial Data
District Support Submission
Report Development
Education and Training
State EducationUser Interface
STARS Security and Provisioning
TOTALS
$6,519
$2,000
$875
$20
$75
$100
$75
$460
$350
$2,500
BUDGET TRACKING
The below table depicts the high-level budgetary control that NMPED will prepare monthly to capture the
STARS project costs.
Budgets
through
6/31/06
Budget
YTD
Actual
Encumbered
Remaining
Forecast to
6/31/05
Total
Expenditure
Forecast
Variance
Personal
Services
Contractual
Services
Other
Initial Release
33
July 25, 2007
STARS Operational Support Project Management Plan
Total
5.12 COMMUNICATIONS
The 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 STARS 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 OCIO. Direct communications with the OCIO will include:
 Monthly communications of project status based on the OCIO Project review forms.
 Consultation on technical architecture and requirements.
 Direct IV&V reviews.
AUDIENCE




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.
OBJECTIVES
 Provide frequent, credible information that enables the awareness of the STARS 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.
BENEFITS






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.
COMMUNICATION INFRASTRUCTURE
Initial Release
34
July 25, 2007
STARS Operational Support Project Management Plan
In order to sustain effective communication as a part of the STARS 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 STARS 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 STARS team.
It outlines the type of communication, the media of communication, and the frequency.
Item
Project Status
Project Summary
Project Activity
Software Demonstration
Milestone Review
Special Communication
Status Meetings
Executive
Project Team
Media
Report
Presentation
Report
Presentation
Report
Report
Presentation
Presentation
e-Mail
Frequency
Monthly
10th
As Required
Monthly
10th
As Required
Weekly
Monday
Weekly
Tuesday
As Required
As Required
As Required
Meeting
Meeting
Weekly
Weekly
Thursday
Tuesday
The following table further describes the various means of communication and its targeted audiences.
Initial Release
35
July 25, 2007
STARS Operational Support Project Management Plan
STAKEHOLDER
PED
Executive
Leadership Team
User
CIO
Executive
Staff
ITC
Executive
Staff
LFC
Executive
Staff
LESC
Executive
Staff
OEA
Executive
Staff
Pilot Districts
Executive
User
LEAs
Executive
User
ABQ
Executive
User
SAC
AAAC
IV&V
QA
Content Advisors
SW
Demo
Project
Status
X
X
X
X
X
X
X
X
Project Summary
Monthly Weekly
X
X
Project
Activity
Milestone
Review
Status Meetings
Exec
Team
X
X
X
X
X
X
X
X
X
X
X
Special
Comm
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
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 STARS 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)
Initial Release
36
July 25, 2007
STARS Operational Support Project Management Plan
2. Issues
3. Risks
4. Change Orders
WEEKLY STATUS REPORTS
Project leaders and the consulting partner Project Manager will submit to the STARS 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.
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.13 QUALITY OBJECTIVES AND CONTROL
The 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:
DEFINING QUALITY
Quality begins by clearly defining the basic standards of quality performance. STARS will accomplish this
by developing Project standards and educating staff to these standards.
EDUCATING STAFF TO QUALITY STANDARDS
Initial Release
37
July 25, 2007
STARS Operational Support Project Management Plan
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.
REVIEWING QUALITY
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:
SELF-REVIEW
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.
JOINT TEAM REVIEW
Project Deliverables can be reviewed in an informal walk-through by a team composed of the QA
Manager, Deloitte Consulting and NM PED 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.
M ANAGEMENT REVIEW
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.
FINAL REVIEW
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. STARS 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.14 CONFIGURATION MANAGEMENT
Configuration 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.
VERSION CONTROL
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.
Initial Release
38
July 25, 2007
STARS Operational Support Project Management 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.15 INDEPENDENT VERIFICATION AND VALIDATION (IV&V)
The development phase of the STARS implementation has been completed and all “project” related
objective of STARS have been accomplished. STARS is in full operational production and the remaining
activities are in operational support. As such, PDS, STARS IV&V contractor, has completed their post
implementation and project close-out reviews. Although, PMI, or the OCIO does not recommend utilizing
IV&V activities to monitor operational activities, PED realizes the value that that an independent view
point brings to execution. NMPED will continue to use the periodic monitoring of PDS to periodically
review the continued enhancement of STARS.
The IV&V contractor will:
1. Structure an IV&V plan to oversee the project efforts and outcomes in accordance with the State
PMO for this project.
2. Participate in STARS project meetings and review project activities.
6.0 OPERATIONAL SUPPORT STAFFING PLANNING
The project staffing plan is divided into to groups:
1. Resources required to execute day-to-day implementation tasks.
2. District specific resources required to execute district related data submission and reporting
tasks.
6.1 CORE TEAM ASSIGNMENTS
TITLE
STAFF
Project Directors
Project Managers
Team Lead
SME
TBD
Piro
Landavazo
TBD
TBD
TBD
Cleary
TRUJILLO
Vigil
TBD
Kain
Bustamante
Curtis
Moll
Aug
07
8
24
160
120
160
160
160
160
160
Sep
07
8
24
160
120
160
160
160
160
160
Oct
07
8
24
160
120
160
160
160
160
160
40
40
40
40
40
40
40
40
40
40
40
40
1272 1272 1272
Nov
07
Dec
07
Jan
07
Feb
07
Mar
07
Apr
07
May
07
8
8
8
8
8
8
8
24
24
24
24
24
24
24
160 160 160 160 160 160 160
120 120 120 120 120 120 120
160 160 160 160 160 160 160
160 160 160 160 160 160 160
160 160 160 160 160 160 160
160 160 160 160 160 160 160
160 160 160 160 160 160 160
160 160 160 160 160 160 160
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
80
1592 1592 1592 1592 1592 1592 1592
Jun
07
Total
Hours
8
88
24
264
160
1760
120
1320
160
1760
160
1760
160
1760
160
1760
160
1760
160
1280
80
760
80
760
80
760
80
760
1592 16552
6.2 DISTRICT RESOURCE REQUIREMENTS
The following table represents the resources assigned by each respective district to support district
specific implementation tasks and training.
Initial Release
39
July 25, 2007
STARS Operational Support Project Management Plan
TITLE
STAFF
Aug
07
District Implementation Representatives
ALAMOGORDO
ARTESIA
AZTEC
BELEN
BERNALILLO
BLOOMFIELD
CARLSBAD
CARRIZOZO
CENTRAL CONS.
CIMARRON
CLAYTON
CLOUDCROFT
COBRE CONS.
CORONA
CUBA
DEMING
DES MOINES
DEXTER
DORA
DULCE
ELIDA
ESPANOLA
EUNICE
FARMINGTON
FLOYD
FT SUMNER
murray
lacard
STARS Coord
STARS Coord
Montoya
Adams
McAlister
STARS Coord
rohra
garcia
talley
shaw
spragg
sultemeier
esparza
Jimerson
bradley
brown
terry
gomez
burch
cockerham
moberly
brooks
terry
mcmathews
Initial Release
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
Sep
07
Oct
07
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
Nov
07
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
40
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
Dec
07
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
Jan
07
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
Feb
07
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
Mar
07
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
Apr
07
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
May
07
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
Jun
07
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
Total
Hours
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
July 25, 2007
STARS Operational Support Project Management Plan
SOCORRO
murillo
SPRINGER
fleming
TAOS
spitz
TRUTH OR CONS. hegwer
TUCUMCARI
garcia
WAGON MOUND
STARS Coord
WEST LAS VEGAS STARS Coord
ZUNI
ivan
SCHOOL/DEAF
Bove
VISUALLY HANDICAP
oistman
SEQUOYAH
Bergman
MOUNTAINAIR
zamora
VAUGHN
gallegos
TATUM
lambert
CHAMA
valdez
MAXWELL
trujillo
SANTA ROSA
salas
MORA
ticia
LAS VEGAS CITY
trujillo
ANIMAS
STARS Coord
CAPITAN
STARS Coord
TULAROSA
STARS Coord
Initial Release
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
1640 1640 1640 1640 1640 1640 1640 1640 1640 1640 1640
41
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
220
18040
July 25, 2007
STARS Operational Support Project Management Plan
Initial Release
42
July 25, 2007
STARS Operational Support Project Management Plan
7.0 PROJECT CLOSE
Project 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 Phase
Project 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.
7.1 ADMINISTRATIVE CLOSE
Administrative 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 Processes
Just 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.
Initial Release
43
July 25, 2007
STARS Operational Support Project Management Plan


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.
Initial Release
44
July 25, 2007
STARS Operational Support Project Management Plan
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.
Initial Release
45
July 25, 2007
STARS Operational Support Project Management Plan
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.
7.2 FINANCIAL CLOSURE
Financial 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
Initial Release
46
July 25, 2007
STARS Operational Support Project Management Plan
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.
Initial Release
47
July 25, 2007
STARS Operational Support Project Management Plan
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.
7.3 CELEBRATION OF SUCCESS
Celebrate 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.
Initial Release
48
July 25, 2007
STARS Operational Support Project Management Plan
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.
7.4 PROJECT CLOSE-OUT CHECKLIST
In 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 Creation
The 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.
Initial Release
49
July 25, 2007
STARS Operational Support Project Management Plan
8.0 GLOSSARY
8.1 ACRONYMS AND ABBREVIATIONS
ADS
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
OCIO
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
Initial Release
50
July 25, 2007
STARS Operational Support Project Management Plan
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
8.2 DEFINITIONS
Acceptance Criteria - The criteria that a system or component must satisfy in order to be accepted by a
user, customer, or other authorized entity. [IEEE-STD-610]
Acceptance Testing - Formal testing conducted to determine whether or not a system satisfies its
acceptance criteria and to enable the customer to determine whether or not to accept the system. [IEESTD-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.
Initial Release
51
July 25, 2007
STARS Operational Support Project Management Plan
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 subprojects.
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.
Initial Release
52
July 25, 2007
STARS Operational Support Project Management Plan
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.
Initial Release
53
July 25, 2007
STARS Operational Support Project Management Plan
9.0 APPENDIX
9.1 Deliverable Acceptance Form
9.2 Project Schedule
9.3 Change Request Form
9.4 Project Close-out Checklist
Initial Release
54
July 25, 2007
STARS Operational Support Project Management Plan
APPENDIX 9.1 DELIVERABLE ACCEPTANCE FORM
Deliverable Specification (Sample)
Date:
To:
January 3, 2006
Daryl Landavazo, NM PED Project Manager
From:
Subject:
Alan Hartwig, Deloitte Consulting Project Manager
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
Description:
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:
Daryl Landavazo, NM PED Project Manager
Initial Release
55
Date
July 25, 2007
STARS Operational Support Project Management Plan
NM PED STARS Project
Deliverable Acceptance Form (Sample)
Deliverable Title:
Delivery Date:
Delivered By:
Received By:
Acceptance Due
Date:
Date Accepted:
Accepted By:
Initial Release
56
July 25, 2007
STARS Operational Support Project Management Plan
APPENDIX 9.2 PROJECT SCHEDULE
The full STARS Implementation Project Schedule can be found on the STARS Implementation e-room
documentation library.
Initial Release
57
July 25, 2007
STARS Operational Support Project Management Plan
APPENDIX 9.3 CHANGE REQUEST FORM
The 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:
Initial Release
Date:
58
July 25, 2007
STARS Operational Support Project Management Plan
APPENDIX 9.4 PROJECT CLOSE-OUT CHECKLIST
Project 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 Information
2.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 Closure
3.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 Success
4.1 Recognize the successes.
4.2 Recognize team members.
4.3 Celebrate!
Initial Release
59
July 25, 2007
STARS Operational Support Project Management Plan
APPENDIX END
This page left intentionally blank.
End of Document
Initial Release
60
July 25, 2007