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.
NNUMBERUMBER DDESCRIPTIONESCRIPTION
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
NNUMBERUMBER DDESCRIPTIONESCRIPTION
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
NNUMBERUMBER DDESCRIPTIONESCRIPTION
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
PPHASEHASE SSUMMARYUMMARY OFOF P PHASEHASE KKEYEY D DELIVERABLESELIVERABLES
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
PPHASEHASE SSUMMARYUMMARY OFOF P PHASEHASE KKEYEY D DELIVERABLESELIVERABLES
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
DELIVERABLE ACCEPTANCE CRITERIA - PROJECT STEERING COMMITTEE (PSC) REVIEW, COMMENT, DISCUSSION, AND APPROVAL
STANDARDS FOR CONTENT AND FORMAT –
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.
QUALITY REVIEW - PROJECT MANAGER AND CIO REVIEW, THEN PSC REVIEW
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)
DELIVERABLE ACCEPTANCE CRITERIA - PROJECT STEERING COMMITTEE (PSC) REVIEW, COMMENT, DISCUSSION, AND APPROVAL
STANDARDS FOR CONTENT AND FORMAT –
MICROSOFT WORD FOR EVALUATION DOCUMENTTABLE OF CONTENTS FOR EVALAUTION IS SPECIFIED BY THE AGENCY.
QUALITY REVIEW - PROJECT MANAGER AND CIO REVIEW, THEN PSC REVIEW
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
PM, Contractor, Project TeamProject S/C
Y 12 days 7-2008 8-2008 4
7 Complete System Design Alternatives Assessment Report
PM, Contractor, Project TeamProject S/C
Y 21 days 8-2008 9-2008 6
8 Complete System Prototype Scope of Work
PM, Contractor, Project TeamProject S/C
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
PM, Contractor, Project TeamProject S/C
Y 15 days 1-2009 2-2009 10
12 Complete System Implementation Plan
PM, Contractor, Project TeamProject S/C
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)
$25,000 Including GRT
3-Build & Test Development EnvironmentSystem Build 1-NSystem Test ResultsTraining Materials
$90,000 Including GRT
4-Accept & Train User Acceptance Test Training ScheduleProduction Environment
$80,000 Including GRT
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)
User-Provide Functional Expertise
Nancy Riley WRAP
Hydrographic Survey Specialist
User-Provide Functional Expertise
Jim McNees LAP
Hydrographic Survey Specialist
User-Provide Functional Expertise
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
User-Provide Functional Expertise
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