WR Exchange Syste… · Web view

WATER RIGHTS DATA QUERY,WATER RIGHTS DATA QUERY, ANALYSIS & EXCHANGE SYSTEM ANALYSIS & EXCHANGE SYSTEM

PROJECT MANAGEMENT PLAN PROJECT MANAGEMENT PLAN (PMP)(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, 2008REVISION 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..............................................................................................................41.2 FUNDING AND SOURCES.........................................................................................................................................................41.3 CONSTRAINTS......................................................................................................................................................................41.4 DEPENDENCIES.....................................................................................................................................................................51.5 ASSUMPTIONS.................................................................................................................................................................51.6 INITIAL PROJECT RISKS IDENTIFIED.........................................................................................................................................6

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE..........................................................................................7

2.1 STAKEHOLDERS....................................................................................................................................................................72.2 PROJECT GOVERNANCE STRUCTURE.........................................................................................................................................82.3 EXECUTIVE REPORTING..........................................................................................................................................................9

3.0 SCOPE......................................................................................................................................................................... 9

3.1 PROJECT OBJECTIVES............................................................................................................................................................93.2 PROJECT EXCLUSIONS............................................................................................................................................................93.3 CRITICAL SUCCESS FACTORS...................................................................................................................................................9

4.0 PROJECT DELIVERABLES AND METHODOLOGY........................................................................................................... 10

4.1 PROJECT MANAGEMENT LIFE CYCLE......................................................................................................................................104.2 PRODUCT LIFE CYCLE.....................................................................................................................................................12

5.0 PROJECT WORK........................................................................................................................................................ 16

5.1 WORK BREAKDOWN STRUCTURE (WBS)................................................................................................................................165.2 SCHEDULE ALLOCATION -PROJECT TIMELINE............................................................................................................................185.3 PROJECT BUDGET...............................................................................................................................................................195.5 STAFF PLANNING AND RESOURCE ACQUISITION..............................................................................................................195.6 PROJECT LOGISTICS.......................................................................................................................................................19

6.0 PROJECT MANAGEMENT AND CONTROLS................................................................................................................. 19

6.1 RISK AND ISSUE MANAGEMENT.............................................................................................................................................196.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V.........................................................................................................196.3 SCOPE MANAGEMENT PLAN................................................................................................................................................196.4 PROJECT BUDGET MANAGEMENT..........................................................................................................................................196.5 COMMUNICATION PLAN......................................................................................................................................................196.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)...................................................................................................196.7 QUALITY OBJECTIVES AND CONTROL............................................................................................................................196.8 CONFIGURATION MANAGEMENT..................................................................................................................................196.9 PROCUREMENT MANAGEMENT PLAN...........................................................................................................................19

7. 0 PROJECT CLOSE........................................................................................................................................................ 19

7.1 Administrative Close.................................................................................................................................................197.2 Contract Close...........................................................................................................................................................19

ATTACHMENTS............................................................................................................................................................... 19

PAGE | 1

Revision History

RREVISIONEVISION N NUMBERUMBER DDATEATE CCOMMENTOMMENT

1.0

2.0

2.1

2.2

PAGE | 2

PREPARING THE PROJECT MANAGEMENT PLANPREPARING THE PROJECT MANAGEMENT PLAN

ABOUT THIS DOCUMENTABOUT THIS DOCUMENT 1.0 PROJECT OVERVIEW1.0 PROJECT OVERVIEW

1.11.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECTEXECUTIVE 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 SOURCES1.2 FUNDING AND SOURCES

SOURCESOURCE AMTAMT ASSOCIATED ASSOCIATED RESTRICTIONSRESTRICTIONS

APPROVERSAPPROVERS

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

PAGE | 3

1.3 CONSTRAINTS1.3 CONSTRAINTSConstraints are factors that restrict the project by scope, resource, or schedule.

NNUMBERUMBER DDESCRIPTIONESCRIPTION

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 DEPENDENCIES1.4 DEPENDENCIESTypes 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

NUMBERNUMBER DESCRIPTIONDESCRIPTION TYPE M,D,ETYPE 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 1.5 ASSUMPTIONSASSUMPTIONSAssumptions are planning factors that, for planning purposes, will be considered true, real, or certain.


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

PAGE | 4

1.6 INITIAL PROJECT RISKS IDENTIFIED1.6 INITIAL PROJECT RISKS IDENTIFIEDIn 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]

THE SYSTEM WILL NOT BE ACCEPTED BY ALL USERS AS THE USERS REPRESENT A BROAD RANGE OF PROGRAM AND TECHNOLOGY EXPERIENCE

PROBABILITY: LOW TO MEDIUM

IMPACT: HIGH

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

PAGE | 5

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE

2.1 STAKEHOLDERS2.1 STAKEHOLDERSList 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.

NAMENAME SSTAKETAKE ININ P PROJECTROJECT ORGORG TTITLEITLE

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 AREALAP 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

PAGE | 6

OSE-ISC IT Governance Committee MeetingRole: Project Investment, Project Portfolio Management

Project Steering CommitteeRole: Project Planning & Oversight

Project TeamRole: Project Execution

2.2 PROJECT GOVERNANCE STRUCTURE2.2 PROJECT GOVERNANCE STRUCTURE2.2.1 D2.2.1 DESCRIBEESCRIBE THETHE ORGANIZATIONALORGANIZATIONAL STRUCTURESTRUCTURE – O – ORGRG C CHARTHART

2.2.2 D2.2.2 DESCRIBEESCRIBE THETHE ROLEROLE ANDAND MEMBERSMEMBERS OFOF THETHE PROJECTPROJECT STEERINGSTEERING COMMITTEECOMMITTEE

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 O2.2.3 ORGANIZATIONALRGANIZATIONAL B BOUNDARIESOUNDARIES, , INTERFACESINTERFACES ANDAND RESPONSIBILITIESRESPONSIBILITIES

No special considerations.

PAGE | 7

2.3 EXECUTIVE REPORTING2.3 EXECUTIVE REPORTING

3.0 SCOPE3.0 SCOPE

3.1 PROJECT OBJECTIVES3.1 PROJECT OBJECTIVES3.1.1 B3.1.1 BUSINESSUSINESS O OBJECTIVESBJECTIVES


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 T3.1.2 TECHNICALECHNICAL O OBJECTIVESBJECTIVES


1 DECREASE VARIABILITY IN DATA QUERY

2 AVOID COSTS ASSOCIATED WITH MAINTAINING AND UPGRADING MULTIPLE DATA QUERY

3.2 PROJECT EXCLUSIONS3.2 PROJECT EXCLUSIONSNo exclusions.

3.3 CRITICAL SUCCESS FACTORS3.3 CRITICAL SUCCESS FACTORSIdentify 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.

PAGE | 8

NUMBERNUMBER DESCRIPTIONDESCRIPTION

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 METHODOLOGY4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE4.1 PROJECT MANAGEMENT LIFE CYCLENOTE: Additional detail can be found in the IT Service Agreement

PPHASEHASE SSUMMARYUMMARY OFOF P PHASEHASE KKEYEY D DELIVERABLESELIVERABLES

0. PROJECT INITIATION

ESTABLISH STEERING COMMITTEE. DEVELOP PROJECT MANAGEMENT PLAN AND CHARTER.

COMPLETE SCOPE OF WORK FOR RE-QUIREMENT-ANALYSIS PHASE

EXECUTE CONTRACT FOR PHASE I ESTABLISH PROJECT STEERING COMMIT-

TEE KICK-OFF PROJECT

1. SYSTEM PLANNING

DEFINE SYSTEM REQUIREMENTS AND ANALYZE SYSTEM DESIGN ALTERNATIVES

COMPLETE “AS-IS” ENVIRONMENT DIS-COVERY REPORT

COMPLETE “TO-BE ” ENVIRONMENT DIS-COVERY REPORT

COMPLETE SYSTEM DESIGN ALTERNA-TIVES ASSESSMENT REPORT

COMPLETE SYSTEM PROTOTYPE SCOPE OF WORK

2. SYSTEM DESIGN

PROTOTYPE SYSTEM, AND FINALIZE SYSTEM DESIGN

COMPLETE SYSTEM PROTOTYPE COMPLETE SYSTEM DESIGN SPECIFICA-

TION 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

COMPLETE POST IMPLEMENTATION AS-SESSMENT

PAGE | 9


RESULTS

4.1.1 P4.1.1 PROJECTROJECT M MANAGEMENTANAGEMENT D DELIVERABLESELIVERABLES

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 D4.1.1.1 DELIVERABLEELIVERABLE 1 - 1 - PROJECTPROJECT WORKWORK PLANPLAN

PROJECT WORK PLAN

DELIVERABLE ACCEPTANCE CRITERIA – PROJECT PLAN AND REVISIONS TO BE APPROVED BY PROJECT STEERING COMMITTEE

STANDARDS FOR CONTENT AND FORMAT – MS PROJECT

QUALITY REVIEW –AGENCY CIO WILL REVIEW FOR QUALITY

4.1.1.2 D4.1.1.2 DELIVERABLEELIVERABLE 2 2 – – PROJECTPROJECT STATUSSTATUS REPORTSREPORTS

MONTHLY PROJECT STATUS REPORT (CONTAINS ISSUES AND RISKS)

DELIVERABLE ACCEPTANCE CRITERIA - PROJECT STATUS REPORTS APPROVED BY PROJECT STEERING COMMITTEE

STANDARDS 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 D4.1.2 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

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

DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS DDATEATE A APPROVEDPPROVED

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 D4.1.3 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDUREDescribe 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 CYCLE4.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

PAGE | 10


SYSTEM REQUIREMENTS & ANALYSIS

DEFINE SYSTEM FUNCTIONAL AND TECHNICAL REQUIREMENTS

“AS-IS” ENVIRONMENT DISCOV-ERY REPORT

“TO-BE ” ENVIRONMENT DIS-COVERY 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 IMPLEMEN-

TATION 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 AP-PROVAL

TRAINING SCHEDULE OPERATIONAL PRODUCTION EN-

VIRONMENT

SYSTEM DEPLOYMENT

SYSTEM IS AVAILABLE IN PRODUCTION ENVIRONMENT

POST IMPLEMENTATION EVALU-ATION RESULTS AND ACTION PLANS (30 AND 60 DAYS OUT)

4.2.1 T4.2.1 TECHNICALECHNICAL S STRATEGYTRATEGY

Discuss the key technical strategies for achieving success in this project.

Our technical strategies include staffing and technology strategies:

Staffing - Agency professional staff will specify the functional and technical requirements for the system and verify that the system meet the requirements as built and tested by the Contractor. Internal staff is skilled in in-house application development and maintenance. However, the need for a contractor to construct this Application is required due to insufficient IT staff resources and relatively little in-house experience with data integration technologies.

Technology – Driven by the system requirements and constraints that have already been defined, the following technical approaches were evaluated:

Buy and Implement - Implementation of Commercial Off-The-Shelf (COTS) software packages or transfer solutions;

PAGE | 11

Buy and Modify COTS - Implementation and modification of COTS software packages or transfer solutions;

Buy and Modify Enterprise Data Integration Tools - Implementation and modification of Enterprise-level integration engines, including Enterprise Application Integration (EAI), Enterprise Service Bus (ESB), and Enterprise Information Integration (EII) engines;

Buy and Modify ETL tools - Implementation, modification and/or customization of Extract-Transform-Load (ETL) tools;

Build - Development and implementation of custom software systems or modification of existing systems

Combination - An integrated approach combining two or more of the above approaches (e.g., ESB with Custom, ETL with Custom, EAI with Custom).

The assessment identified that the “Buy and Implement” COTS packages or transfer solutions are not viable solutions for OSE at this time. In addition, all other “Buy and Modify” solutions require some level of customization in order to meet the system requirements. As a result, the “Build” and “Combination” solutions are the practical solutions for OSE at this time. The “Combination” solution provides the opportunity to optimize the solution to match the needs of OSE. Since OSE already owns Microsoft’s ETL tool (SQL Server Integration Services [SSIS]) and has not identified specific requirements for an Enterprise integration engine, use of SSIS with custom-built interfaces to fill in the functionality gaps would work well with the existing OSE capabilities. The primary advantage of this approach over pure custom development is the use of standardized ETL processes and engines for the database-related functions, rather than custom-building these engines. This will provide maintainability, extensibility, and reliability for the ETL processes and reduce overall costs of implementation of the data exchange system.

4.2.2 P4.2.2 PRODUCTRODUCT ANDAND P PRODUCTRODUCT D DEVELOPMENTEVELOPMENT D DELIVERABLESELIVERABLES

Product Deliverables are work products or artifacts that are driven by the product management methodology requirements and standard project management practices regardless of the product requirements of the project.

4.2.2.1 Deliverable 1 - System Requirements DocumentsDESCRIPTION – “AS-IS” ENVIRONMENT DISCOV-

ERY REPORT “TO-BE ” ENVIRONMENT DIS-

COVERY REPORT SYSTEM DESIGN ALTERNATIVES

ASSESSMENT REPORT COMPLETE SYSTEM PROTOTYPE

SCOPE OF WORK

DELIVERABLE ACCEPTANCE CRITERIA -ACCURATELY REFLECTS INFORMATION AND DISCUSSION FROM MULTIPLE USER GROUP INTERVIEWS

STANDARDS FOR CONTENT AND FORMAT –CONTRACTOR STANDARD FORMAT ACCEPTED BY PROJECT TEAM (USE OF ISHIKAWA DIAGRAMS TO SPECIFY INPUTS, CONTROLS, OUTPUTS, MECHANISMS)

QUALITY REVIEW – PROJECT MANAGER AND CIO REVIEW, THEN PSC REVIEW

PAGE | 12

4.2.2.3 Deliverable 2 - System Design DocumentsDESCRIPTION – COMPLETE SYSTEM PROTOTYPE COMPLETE SYSTEM DESIGN

SPECIFICATION COMPLETE SYSTEM IMPLEMEN-

TATION PLAN (INCLUDES TRAINING PLAN)

DELIVERABLE ACCEPTANCE CRITERIA - PROJECT STEERING COMMITTEE (PSC) REVIEW, COMMENT, DISCUSSION, AND APPROVALSTANDARDS FOR CONTENT AND FORMAT – ‘MUST HAVE’ FUNCTIONS ARE DEMONSTRATED IN PROTOTYPE.

TABLE OF CONTENTS FOR DESIGN SPECIFICATION AND IMPLEMENTATION PLAN ARE SPECIFIED BY THE AGENCY.

DESIGN SPECIFICATION DOCUMENT DESCRIBES FLOW OF EVENTS, AND INCLUDES USER INTERFACE DESIGN. QUALITY REVIEW - PROJECT MANAGER AND CIO REVIEW, THEN PSC REVIEW

PAGE | 13

4.2.2.4 Deliverable 3 – System Build & Test

4.2.2.5 Deliverable 4 – System Acceptance & TrainingDESCRIPTION – USER ACCEPTANCE TEST AP-

PROVAL TRAINING SCHEDULE OPERATIONAL PRODUCTION EN-

VIRONMENT

DELIVERABLE ACCEPTANCE CRITERIA - PROJECT STEERING COMMITTEE (PSC) REVIEW, COMMENT, DISCUSSION, AND APPROVAL

STANDARDS FOR CONTENT AND FORMAT –

MICROSOFT WORD FOR UA TEST APPROVAL DOCUMENT AND TRAINING SCHEDULE.

SOFTWARE INSTALLED AND DEMONSTRATED IN PRODUCTION ENVIRONMENT WITH SPECIFIED VERSIONS OF HARDWARE AND SOFTWARE

QUALITY REVIEW - PROJECT MANAGER AND CIO REVIEW, THEN PSC REVIEW

PAGE | 14

DESCRIPTION – OPERATIONAL DEVELOPMENT

ENVIRONMENT SYSTEM BUILD 1-N SYSTEM TEST RESULTS TRAINING MATERIALS



SOFTWARE INSTALLED AND DEMONSTRATED IN DEVELOPMENT ENVIRONMENT WITH SPECIFIED VERSIONS OF HARDWARE AND SOFTWARE. MICROSOFT WORD WITH SCREEN PRINTS TO BE USER FOR TRAINING MATERIALS.


4.2.2.6 Deliverable 5 – System DeploymentDESCRIPTION – POST IMPLEMENTATION BUG

TRACKING REPORT POST IMPLEMENTATION EVALU-

ATION RESULTS AND ACTION PLANS (30 AND 60 DAYS OUT)



MICROSOFT WORD FOR EVALUATION DOCUMENTTABLE OF CONTENTS FOR EVALAUTION IS SPECIFIED BY THE AGENCY.


4.2.3 D4.2.3 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

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.

DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))

DDATEATE AAPPROVEDPPROVED

ALL ALL AGENCY CIO, RENEE MARTINEZ ON BEHALF OF THE PROJECT STEERING COMMITTEE

4.2.4 D4.2.4 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

The Project Manager will review and comment on each deliverable as to conformance with requirements and acceptance criteria. Agency CIO will them comment on each deliverable as to conformance with requirements and acceptance criteria. A summary of each deliverable will be presented to the Project Steering Committee for comment and approval.

5.0 PROJECT WORK5.0 PROJECT WORK

5.1 WORK BREAKDOWN STRUCTURE (WBS)5.1 WORK BREAKDOWN STRUCTURE (WBS)A WBS is a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Describe the work activities that comprise the work breakdown structure (WBS) or the work packages within the WBS. Identify the WBS element or other work package identifier and provide a general description of the tasks or activities, the definition or objectives, and the milestones and deliverables of each work package.

Use the chart below for highest level presentation, and provide a more detailed WBS as an attachment to this project plan.

PAGE | 15

Identifier Work Package Description Definition/Objective Milestone/Deliverable

The WBS for the next phase of the project (design) will be available in December 2008

PAGE | 16

5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE5.2 SCHEDULE ALLOCATION -PROJECT TIMELINEPlease provide a more detailed project schedule as an attachment to this plan. A detailed project schedule for the next phase of the project (design) will be available in December 2008.

Identifier Task/Activity Name Resource Name

Milestone (Y/N)

Effort/ Duration

Start Finish Dependent Task

1 Complete Scope of Work for Requirement-Analysis Phase (Phase I)

PM 2 days 5-2008 5-2008

2 Execute Contract for Phase I PM 21 days 5-2008 5-2008 1

3 Establish Project Steering Committee

Project S/C 2 days 6-2008 6-2008 2

4 Kick-Off Project PM, Project Team

Y 1 day 6-2008 6-2008 3

5 Complete “As-Is” Environment Discovery Report

PM, Contractor, Project TeamProject S/C

Y 21 days 6-2008 7-2008 4

6 Complete “To-Be ” Environment Discovery Report


Y 12 days 7-2008 8-2008 4

7 Complete System Design Alternatives Assessment Report


Y 21 days 8-2008 9-2008 6

8 Complete System Prototype Scope of Work


Y 10 days 9-2008 10-2008 7

9 Execute Contract for Phase 2 PM, Project S/C 21 days 10-2008 12-2008 8

10 Complete System Prototype PM, Contractor, Project TeamProject S/C

Y 21 days 12-2008 1-2009 9

11 Complete System Design Specification


Y 15 days 1-2009 2-2009 10

12 Complete System Implementation Plan


Y 15 days 2-2009 3-2009 11

13 Execute Contract for Phase 3 PM, Contractor, Project TeamProject S/C

21 days 3-2009 3-2009 12

PAGE | 17

5.3 PROJECT BUDGET5.3 PROJECT BUDGETCosts estimates are the costs applied to an activity in a project by assigning resources with associated rates or fees. Resources can include equipment, material, technology, processing cycles, or people. The total cost is critical and should be consistent with the proposal; include breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or deliverable).

Phase-Activity Associated Deliverable Estimated Budget

1-Requirements &Analysis

“As-Is” Environment Discovery Report“To-Be ” Environment Discovery ReportSystem Design Alternatives Assessment ReportComplete System Prototype Scope of Work

$35,000 Including GRT

2-Design System PrototypeSystem Design SpecificationSystem Implementation Plan (includes training plan)


3-Build & Test Development EnvironmentSystem Build 1-NSystem Test ResultsTraining Materials


4-Accept & Train User Acceptance Test Training ScheduleProduction Environment


5-Deploy Post Implementation Evaluation (30 and 60 days out) $20,000 Including GRT

TOTALS $250,000 including GRT

PAGE | 18

Project Manager(Agency, Contractor)

Application Developers (User Interface, Business Logic, Data Integration, Database, GIS, Legacy System)

Security & Network Engineers

End User Support Specialists

Program Experts (Hydrographic Survey, Adjudication, Water Rights, Water Rights Abstracting)

5.4 PROJECT TEAM5.4 PROJECT TEAM5.4.1 P5.4.1 PROJECTROJECT T TEAMEAM O ORGANIZATIONALRGANIZATIONAL S STRUCTURETRUCTURE

PAGE | 19

5.4.2 P5.4.2 PROJECTROJECT T TEAMEAM R ROLESOLES ANDAND R RESPONSIBILITIESESPONSIBILITIES

RROLEOLE RRESPONSIBILITYESPONSIBILITY NNAMEAME FFUNCTIONUNCTIONALAL A AREAREA

Project Manager Manage Project Renée Martínez,Mercedes Ortega

ITIT

Contract Administrator Manage Contract Marcos Mendiola ISC

Water Rights Specialist (Santa Fe Office)

User-Provide Functional Expertise

Jerri Trujillo WRAP

Water Rights Specialist (Las Cruces Office)


Nancy Riley WRAP

Hydrographic Survey Specialist


Jim McNees LAP

Hydrographic Survey Specialist


James Aguirre LAP

Adjudication Attorney User-Provide Functional Expertise

Frank Reckard LAP

Adjudication Attorney User-Provide Functional Expertise

Ken Swain LAP

Water Rights Abstracting Specialist


Sylvia Lucero WRAP

Agency Enterprise GIS Specialist

Design, Implement, Support GIS Components

Steve Hayes IT

IT Applications Development Specialist

Design, Implement, Support Application Components

Michael MackenzieDiana HardyFrank Gao

IT

IT Infrastructure Specialist

Design, Implement, Support Application Infrastructure (Network, Security, Backup)

John BuchserTarmo Sutt

IT

IT Desktop Specialist Support Desktop Components

Tarmo Sutt IT

PAGE | 20

5.5 STAFF PLANNING AND RESOURCE ACQUISITION5.5 STAFF PLANNING AND RESOURCE ACQUISITIONComplete the chart below identifying the project team members and details concerning their project commitment. Project staff should include State, Contract, Customer (Business Owner), or Vendor team members

5.5.1 P5.5.1 PROJECTROJECT S STAFFTAFF

Resource Cost Estimate

Estimated Hours Availability Skill Set Work Product/Deliverable

Contractor-Project Manager $45,000 475 25% PM Expertise Project Work Plan & Status Reports

Contractor- Application Developer

$120,000 1,250 100% Software Development

System Specifications and Software

Contractor-Training Specialist $20,000 250 20% Training Expertise

System Training Plan & Materials

Agency Project Manager N/A 300 20% PM Expertise Project Work Plan & Status Reports

IT Governance Committee (8) N/A 80 5% Oversight Project Status Report

Project Steering Committee (7) N/A 250 10% Program Alignment

Approve Deliverables

Agency Functional Experts N/A 1,000 50% Functional Expertise

System Design and Build Input

Agency IT Experts N/A 800 40% IT Expertise Design, Implement, Support Application

4,155

5.5.2 N5.5.2 NONON-P-PERSONNELERSONNEL RESOURCESRESOURCES

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

Resource Cost Estimate

Estimated units/hours Availability Source Work Product/Deliverable

Software licenses $10,000 N/A N/A N/A Software Builds

PAGE | 21

5.6 PROJECT LOGISTICS5.6 PROJECT LOGISTICS5.6.1 P5.6.1 PROJECTROJECT T TEAMEAM T TRAININGRAINING

Describe training if any needed by project team members. This is not to include training for end users, system administrators or business owners; those should be handled within a training document or part of the transition to operations planning.

ResourceCost

EstimateEstimated

Hours Availability Skill Set Work Product/Deliverable

N/A

6.0 PROJECT MANAGEMENT AND CONTROLS6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT6.1 RISK AND ISSUE MANAGEMENT6.1.1 R6.1.1 RISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGY

This project has minimal technical and business risk as noted in Section 1.6. The Project Steering Committee is minimizing risk by meeting monthly to address issues and risks. Also an iterative system build and testing process will be used.

6.1.2 P6.1.2 PROJECTROJECT R RISKISK I IDENTIFICATIONDENTIFICATION

Risks will be identified through periodic assessments, project reports, and meetings.

6.1.3 P6.1.3 PROJECTROJECT R RISKISK M MITIGATIONITIGATION A APPROACHPPROACH

A mitigation plan will be developed for all risks rated with a high probability of occurrence and a medium or high impact. The following information will be carried in each monthly project status report.

Major Project Risks:No. Description Probability Impact Trigger Mitigation Actions Being Taken

6.1.4 R6.1.4 RISKISK R REPORTINGEPORTING ANDAND E ESCALATIONSCALATION S STRATEGYTRATEGY

Risks will be reported on monthly status reports and reviewed monthly by the project steering committee. Risks will be escalated per the direction of the Project Steering Committee.

6.1.5 P6.1.5 PROJECTROJECT R RISKISK T TRACKINGRACKING A APPROACHPPROACH

Please see response to item 6.1.3 above.

6.1.6 ISSUE MANAGEMENT6.1.6 ISSUE MANAGEMENT

6.1.6.1 Internal Issue Escalation and Resolution ProcessA three tier issue escalation process will be followed. The project team will identify and track issues on an ongoing basis. Issues that cannot be resolved at the project team level will be escalated to the Project Steering Committee which will meet monthly to in-part address outstanding issues. Issues that can not be resolved by the Project Steering Committee will be

PAGE | 22

addressed by the Agency IT Governance Committee. The Project Manager will manage issue resolution assignments just like other project tasks.

6.1.6.2 External Issue Escalation and Resolution ProcessPlease see response to item 6.1.6.1 above.

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&VThe project is low risk and the Agency has requested an exception to the IV&V requirement.

6.3 SCOPE MANAGEMENT PLAN6.3 SCOPE MANAGEMENT PLANDescribe the process that is going to be used to manage the scope of the project. Make sure to address managing stakeholder expectations.

6.3.1 C6.3.1 CHANGEHANGE C CONTROLONTROL

6.3.1.1 Change Control ProcessDue to the small size of the project and accelerated schedule for the project; little to no changes will be accepted once the specifications are approved. The project steering committee will review and decide on any changes requested by the project team.

6.3.1.2 Change Control Board (CCB)A CCB will not be implemented due to the small size, low risk and accelerated schedule for the project. The project steering committee will serve as the CCB if necessary.

6.4 PROJECT BUDGET MANAGEMENT6.4 PROJECT BUDGET MANAGEMENTCosts estimates are the costs applied to an activity in a project by assigning resources with associated rates or fees. Resources can include equipment, material, technology, processing cycles, or people. The total cost is critical and should be consistent with the proposal; include breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or deliverable).

6.4.1 B6.4.1 BUDGETUDGET T TRACKINGRACKING

Budget tracking is the responsibility of the project manager with oversight by the Project Steerting Committee. The following information will be carried in each monthly project status report.

Financial Summary:

Project Budget: $250,000

PAGE | 23

Project Expenditures to Date: $13,500Project Expenditures – Estimate to Complete: $236,500Projected Variance: $0

6.5 COMMUNICATION PLAN6.5 COMMUNICATION PLANCommunication planning involves determining the information and communication needs of the stakeholders, executive sponsors, project team and others as needed. The communication plan needs to address who needs what information, when they will need it, how it will be given to them, and by whom. The complexity of the project may require a separate communication plan; however a high level summary of that plan will need to be included here and a reference made to the appropriate Appendix.

6.5.1 C6.5.1 COMMUNICATIONOMMUNICATION M MATRIXATRIX

6.5.2 S6.5.2 STATUSTATUS M MEETINGSEETINGS

Weekly project team status meetings will be held. Monthly Project Steering Committee meetings will be held.

6.5.3 P6.5.3 PROJECTROJECT S STATUSTATUS R REPORTSEPORTS

Weekly status reports are required of the Contractor. Monthly project status reports are required of the Agency project manager to the Project Steering Committee. Bi-monthly project status reports are required of the Agency CIO to the Agency IT Governance Committee

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)The Project Manager and Executive Sponsors define the project metrics that will be used to control the project. Each project will need to have an established metrics program. Metrics are collected for measuring the progress of a project against its planned budget, schedule, resource usage, and error rates, and of establishing a historical database, which will aid in planning and forecasting future projects. At a minimum metrics must be established for time (schedule), cost (budget) and quality.

6.6.1 B6.6.1 BASELINESASELINES

Project Area Category Measure

All Schedule Deliverables received on schedule

Deliverables approved on schedule

All Cost Project costs do not exceed budget

All Quality Deliverables meet specifications

PAGE | 24

6.6.2 M6.6.2 METRICSETRICS L LIBRARYIBRARY

6.7 QUALITY OBJECTIVES AND CONTROL6.7 QUALITY OBJECTIVES AND CONTROLQuality Management includes the processes required to ensure that the project will satisfy the needs for which it was undertaken. It includes all activities of the overall management function that determine the quality policy, objectives, quality assurance, quality control, and quality improvement, within the quality system. If a separate Quality Plan is used, include a high level summary in this document and refer to the appropriate appendix.

6.7.1 6.7.1 QUALITYQUALITY S STANDARDSTANDARDS

Describe the agency, industry or regulatory project performance standards that will be followed and assessed by the project. These quality standards will be used to assess whether the quality objectives were achieved.

Identify each of the project quality standards that are directly related to the project and not to the performance of the actual product and/or service. For each quality standard, identify the tracking tool or measure such as number of project reviews or Project Status.

No. Quality Standard Tracking Tool or Measure

1 Standards for the design phase of the project are under consideration at this time.

TBD

2 •

3 •

4 •

5 •

•

•

•

6.7.2 P6.7.2 PROJECTROJECT ANDAND P PRODUCTRODUCT R REVIEWEVIEW AND ASSESSMENTSAND ASSESSMENTS

Review Type Quality Standard Tools Reviewer Reports

Requirements

Design

Build & Test

Deploy

6.7.3 A6.7.3 AGENCYGENCY/C/CUSTOMERUSTOMER S SATISFACTIONATISFACTION

The project manager should assess the on-going sense of the customer agency about how they feel the project is going, and how team members are acting on the project. This feedback would be helpful to the success of the project and the professional growth of the project team members.

The Post-Implementation Evaluation report will report feedback from stakeholder. The small size and duration of the project do not allow for on-going satisfaction assessments.

PAGE | 25

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS

The process is specified in the State of New Mexico standard IT professional services agreement.

6.8 CONFIGURATION MANAGEMENT6.8 CONFIGURATION MANAGEMENTConfiguration Management determines how project information (files, reports, designs, memos, documents, etc.) will be managed (tracked, approved, stored, secured, accessed, version control, etc.) and owned by (e.g., Agency managing the project or the Customer). Standards and team awareness are critical.

6.8.1 V6.8.1 VERSIONERSION C CONTROLONTROL

The Agency will adopt a file naming convention that specified the version of all artifacts within the project document repository.

6.8.2 P6.8.2 PROJECTROJECT R REPOSITORYEPOSITORY (P (PROJECTROJECT L LIBRARYIBRARY))The Agency will manage and make available all deliverables in a repository with open access for the Department to review.

6.9 PROCUREMENT MANAGEMENT PLAN6.9 PROCUREMENT MANAGEMENT PLANThe Agency will solicit proposals for IT professional services from vendors on the State IT Price Agreement. Competing proposals will be compared and proposals that represent the greatest value to the Agency will be selected.

7. 0 PROJECT CLOSE7. 0 PROJECT CLOSEProject Close will always consist of administrative project activities and possibly contractual project activities and an external vendor is employed. Completing both sets of activities is a mandatory step in the project life cycle. Administrative activities complete the internal needs for the Agency/Unit that is responsible for managing the project, such as lessons learned, recording the last hours against the project, and providing transition for the staff to other assignments. Contractual activities meet the contractual needs, such as executing a procurement audit and formal acceptance of the project work products.

7.1 A7.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE

Administrative Close occurs at both the end of phase and end of project. This closure consists of verification that objectives and deliverables were met. Acceptance is formalized and phase activities are administratively closed out. Administrative closure occurs on a “by-phase” basis in accordance with the WBS and should not be delayed to project end. At that point, the burden of closing is too great and audits inaccurate. The specific project close activities for a given project are contingent on the project’s complexity and size. Project managers should work with the project’s project management consultant to tailored Project Close procedures to compliment the project’s objectives

PAGE | 26

7.2 C7.2 CONTRACTONTRACT C CLOSELOSE

Contract close is similar to administrative close in that it involves product and process verification for contract close.

ATTACHMENTATTACHMENTSSAttachments are included for additional information, but are not formally considered part of the Project Plan for approvals and change management purposes. Examples

Acronyms, abbreviations and definitions

Technical glossary of IT terms

Project Work breakdown schedule

Project timeline

PAGE | 27

WR Exchange Syste… · Web view

Documents

Transcript of WR Exchange Syste… · Web view