WATER RIGHTS DATA QUERY, ANALYSIS & EXCHANGE SYSTEM
PROJECT MANAGEMENT PLAN
(PMP)
Executive Sponsors:
Greg Ridgley, Deputy General Counsel, Office of the State Engineer
Rick DeSimone, Water Rights Abstracting Bureau Chief
Project Manager
Renee Martinez, Chief Information Officer
Original Plan Date: November 1, 2008
Revision Date:
Revision:
Table of Contents
Preparing the Project Management plan 4
About This Document 4
1.0 Project Overview 4
1.1 Executive Summary- rationale for the Project 4
1.2 funding and sources 4
1.3 constraints 4
1.4 dependencies 5
1.5 ASSUMPTIONS 5
1.6 Initial Project Risks Identified 6
2.0 Project Authority and Organizational Structure 7
2.1 Stakeholders 7
2.2 Project Governance Structure 8
2.3 Executive Reporting 9
3.0 Scope 9
3.1 Project Objectives 9
3.2 Project exclusions 9
3.3 Critical Success Factors 9
4.0 Project Deliverables and methodology 10
4.1 Project Management Life Cycle 10
4.2 PRODUCT LIFE CYCLE 12
5.0 Project Work 16
5.1 Work Breakdown Structure (WBS) 16
5.2 Schedule allocation -Project Timeline 18
5.3 Project Budget 19
5.5 STAFF PLANNING AND Resource ACQUISITION 19
5.6 PROJECT LOGISTICS 19
6.0 Project Management and Controls 19
6.1 Risk and issue Management 19
6.2 INDEPENDENT Verification And Validation - Iv&V 19
6.3 Scope Management Plan 19
6.4 Project Budget Management 19
6.5 Communication Plan 19
6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS) 19
6.7 QUALITY OBJECTIVES AND CONTROL 19
6.8 CONFIGURATION MANAGEMENT 19
6.9 PROCUREMENT MANAGEMENT PLAN 19
7. 0 Project Close 19
7.1 Administrative Close 19
7.2 Contract Close 19
AttachmentS 19
Revision History
1.0
2.0
2.1
2.2
Preparing the Project Management plan
About This Document
1.0 Project Overview
1.1 Executive Summary- rationale for the Project
The adjudication of water rights by the Litigation and Adjudication Program (LAP) and the administration of water rights by the Water Resources Allocation Program (WRAP) are two distinct yet complementary activities performed by the Office of the State Engineer (OSE). These two programs use separate information systems to support these activities. The Water Rights Adjudication Tracking System (WRATS), is used by the LAP to generate legal pleadings and manage its data and attorney work product as water rights are adjudicated by the court system; and the Water Administration Technical Engineering System (WATERS), is used by the WRAP to store a variety of historical and current data and work products to facilitate the processing of water rights applications and to administer water rights.
Both information systems are used to store, edit and create data and information used to achieve the strategic goals of the Agency; and both were planned and designed to be able to exchange data between them. However, the data query, analysis and exchange tools and processes have not been fully developed and deployed across the Agency.
The purpose of this project is to design, build and implement a data query, analysis and exchange system that allows users to associate data within the WRATS and WATERS databases and other data stores and automate the process of exchanging data. The new system is needed to support the current and future business activities of the Agency.
The systems analysis and requirements phase of the project was completed in October 2008 and the Agency is positioned to start and be successful with the implementation phase of the project.
1.2 funding and sources
Source / AMT / Associated restrictions / Approvers /48TH LEGISLATURE - STATE OF NEW MEXICO - SECOND SESSION, 2008
HOUSE APPROPRIATIONS AND FINANCE COMMITTEE SUBSTITUTE FOR HOUSE BILLS 2, 3, 4, 5, 6 AND 10; SECTION 7, ITEM 24 / $200,000
1.3 constraints
Constraints are factors that restrict the project by scope, resource, or schedule.
Number / Description /1 / The special appropriations for the project must be used prior to JUNE 30, 2010.
2 / total projects costs can not exceed $250,000 unless other sources of funds are identified and secured.
1.4 dependencies
Types include the following and should be associated with each dependency listed.
· Mandatory dependencies are dependencies that are inherent to the work being done.
· D- Discretionary dependencies are dependencies defined by the project management team. This may also encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.
· E-External dependencies are dependencies that involve a relationship between project activities and non-project activities such as purchasing/procurement
Number / Description / Type M,D,E /1 / managing the project to schedule will depend on a well organized DELIVERABLE REVIEW AND APPROVAL process by appropriate project stakeholders and team members / D
2 / user acceptance of the system will require the involvement of employees with a range of program and technology experience in all phases of the project / D
1.5 ASSUMPTIONS
Assumptions are planning factors that, for planning purposes, will be considered true, real, or certain.
Number / Description /1 / managing the project to schedule will depend on a well organized DELIVERABLE REVIEW AND APPROVAL process by appropriate project stakeholders and team members
2 / user acceptance of the system will require the involvement of employees with a range of program and technology experience in all phases of the project
1.6 Initial Project Risks Identified
In this section identify and describe how each risk will be managed. Include the steps that will be taken to maximize activity that will result in minimizing probability and impact of each risk.
[Risk 1 – User Acceptance]
Mitigation Strategy:
1) Project Steering Committee members will include senior managers from the two programs (LAP, WRAP) that are the primary users of the system. A commitment from these members will be made to dedicate employees with the right skills and expertise to the project team.
2) A prototype of the system will be built early in the project lifecycle so that users will have the opprortunity to visualize the system and provide input. an iterative development process will be followed to build-out the system function by function allowing users to have multiple chances to interact with the system and provide input.
Contingency Plan: the system will not be deployed until user acceptance test and training are successful
2.0 Project Authority and Organizational Structure
2.1 Stakeholders
List all of the major stakeholders in this project, and state why they have a stake. . Stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results.
name / Stake in Project / ORG / Title /Water Resource Allocation Program (WRAP) / WRAP employees and managers will use the system to obtain direct access to the current water uses that are identified by hydrographic surveys and to be able to determine when water rights transactions may interact with an ongoing legal action / OSE / N/A
Litigation & Adjudication Program (LAP):
· Hydrographic Survey Bureau
· Northern Adjudication Bureau
· Pecos Adjudication Bureau
· Lower Rio Grande Adjudication Bureau / LAP employees and managers (attorneys, paralegals and hydrographic survey professionals) will use the system to obtain a snapshot of the water rights history of a geographic area at the outset of an adjudication for that area
LAP employees and managers will also use the system to obtain periodic updates of water rights transactions (declarations, permits, licenses, ownership changes) that take place during the course of an adjudication / OSE / N/A
2.2 Project Governance Structure
2.2.1 Describe the organizational structure – Org Chart
2.2.2 Describe the role and members of the project steering committee
Project Steering Committee:
· Greg Ridgley, LAP Deputy General Counsel, Role: Represents needs of the LAP organization as primary users of the system
· Rick DeSimone, WRAP Water Rights Abstracting Bureau Chief, Role: Represents needs of the Water Rights Abstracting Bureau as primary users of the system
· Christina Noftsker, WRAP District V (Santa Fe), Role: Represents needs of all WRAP district offices as primary users of the system
· Dario Rodriguez, LAP Hydrographic Survey Bureau Chief, Role: Represents needs of the LAP Hydrographic Survey Bureau as primary users of the system
· Renée Martínez, OSE Chief Information Office and IT Services Bureau Chief, Role: Represents IT needs for the entire Agency
2.2.3 Organizational Boundaries, interfaces and responsibilities
No special considerations.
2.3 Executive Reporting
3.0 Scope
3.1 Project Objectives
3.1.1 Business Objectives
Number / Description /1 / · Improve workforce efficiency
o Increased productivity of hydrographic survey staff by 5%
o Increased productivity of water resource specialists by 2.5%
2 / · Enhance the delivery of services to the public
3 / · Reduce time to complete adjudications and water rights transactions
4 / · Improve accuracy of water right determinations
5 / · Minimize errors/rework
6 / · Shorten service times to public
7 / · Improve public image of the Agency
3.1.2 Technical Objectives
Number / Description /1 / · Decrease variability in data query
2 / · Avoid costs associated with maintaining and upgrading multiple data query
3.2 Project exclusions
No exclusions.
3.3 Critical Success Factors
Identify the critical success factors for achieving success in this project. Metric are key to understanding the ability of the project to meet the end goals of the Executive Sponsor and the Business Owner, as well as the ability of the project team to stay within schedule and budget. See also section 6.7 Quality Objectives and Controls.
Number / Description /1 / project will use an interative deliverable review process that allows quality review and deliverable refinement opportunities throughout the project. These reviews include the primary technical and management leads within the agency.
The project steering committee and agency It Governance Committee will review project on a bi-monthly basis
4.0 Project Deliverables and methodology
4.1 Project Management Life Cycle
NOTE: Additional detail can be found in the IT Service Agreement
Phase / Summary of Phase / Key Deliverables /0. Project Initiation / Establish steering committee. Develop project management plan and charter. / · Complete Scope of Work for Requirement-Analysis Phase
· Execute Contract for Phase I
· Establish Project Steering Committee
· Kick-Off Project
1. System Planning / Define system requirements and analyze system design alternatives / · Complete “As-Is” Environment Discovery Report
· Complete “To-Be ” Environment Discovery Report
· Complete System Design Alternatives Assessment Report
· Complete System Prototype Scope of Work
2. System Design / prototype system, and finalize system design / · Complete System Prototype
· Complete System Design Specification
· Complete System Implementation Plan
3. System Implementation / build, test and deploy system / · Complete System Build 1-3
· Complete System Test Plan
· Complete System Training Plan
· Complete User Acceptance Test
· Complete System Implementation
4. Project Close-Out / evaluate and document project results / · Complete Post Implementation Assessment
4.1.1 Project Management Deliverables
Project Deliverables are work products or artifacts that are driven by the project management methodology requirements and standard project management practices regardless of the product requirements of the project.
4.1.1.1 Deliverable 1 - project work plan
Project Work Plan / Deliverable Acceptance Criteria – Project plan and revisions to be approved by Project Steering CommitteeStandards for Content and Format – MS Project
Quality Review –Agency CIO will review for quality
4.1.1.2 Deliverable 2 – project status reports
monthly Project Status Report (contains issues and risks) / Deliverable Acceptance Criteria - Project status reports approved by Project Steering CommitteeStandards for Content and Format – A standard template used for all IT projects will be used
Quality Review – Project Steering Committee will review for quality
4.1.2 Deliverable Approval Authority Designations
Complete the following table to identify the deliverables this project is to produce, and to name the person or persons who have authority to approve each deliverable
Deliverable Number / Deliverable / Approvers / Date Approved /PRJ-DEL
001-010 / Deliverables as noted in sections 4.1.1.1-4.1.1.10 / Project Steering Committee / Upon review and sign off from Project Steering Committee
4.1.3 Deliverable Acceptance Procedure
Describe the process that this project will use for the formal acceptance of all deliverables.
Deliverables will be reviewed by Project Manager and Project Team, then passed on to the Project Steering Committee for final approval. All defects will be communicated to the Contractor or Project Manager for correction before final approval and acceptance.
4.2 PRODUCT LIFE CYCLE
“During the project management lifecycle, agencies shall select and implement a phase product development lifecycle methodology approved by the Department.” PROJECT OVERSIGHT PROCESS Memorandum
Phase / Summary of Phase / Key DeliverablesSystem Requirements & Analysis / Define system functional and technical requirements / · “As-Is” Environment Discovery Report
· “To-Be ” Environment Discovery Report
· System Design Alternatives Assessment Report
· Complete System Prototype Scope of Work
System Design / complete system design specification (user interface, queries, reports, business logic, interfaces, security, architecture) / · Complete System Prototype
· Complete System Design Specification
· Complete System Implementation Plan (includes training plan)
System Build, Test / complete iterative build and function testing of the system / · operational development environment
· System Build 1-N
· System Test results
· training materials
system acceptance and training / users formally accept system and users are trained / · User Acceptance Test approval
· training schedule
· operational production environment
system deployment / system is available in production environment / · post implementation evaluation results and action plans (30 and 60 days out)
4.2.1 Technical Strategy
Discuss the key technical strategies for achieving success in this project.