Plan Management
Antionette80
Obj5Topic2LA4Example2_ProjectManagementPlan-OregonPublicUtilityCommission.pdf
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
Project
Management Plan
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 2
VERSION HISTORY
Version # Date Author Key Differences
0.1 5/10/2019 Michael Dougherty
0.2 6/13/2019 Michael Dougherty Updates per OSCIO and PUC Staff
0.3 10/06/2020 Michael Dougherty New Format by EIS
0.4 11/04/2020 Michael Dougherty Updates per EIS and OPUC Staff
0.5 11/16/2020 Michael Dougherty Additional updates per EIS and OPUC Staff
0.6 11/25/20020 Michael Dougherty Additional updates per EIS and OPUC Staff
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 3
TABLE OF CONTENTS
Contents 1 Introduction .......................................................................................................................................... 6
1.1 Project Overview ........................................................................................................................... 7
2 Project Governance............................................................................................................................... 8
2.1 Governing Bodies .......................................................................................................................... 9
2.2 Project Governance Structure .................................................................................................... 10
2.3 Roles and Responsibilities ........................................................................................................... 11
3 Scope Management Plan .................................................................................................................... 14
3.1 Scope Development .................................................................................................................... 14
3.2 Roles and Responsibilities ........................................................................................................... 15
3.3 Scope Definition .......................................................................................................................... 17
3.4 Work Breakdown Structure (WBS) ............................................................................................. 17
3.5 Scope Validation ......................................................................................................................... 18
3.5.1 Deliverable Tracking. ........................................................................................................... 19
3.5.2 Receive the Deliverable. ..................................................................................................... 19
3.5.3 Prepare and Route Deliverable. .......................................................................................... 19
3.5.4 Review of Deliverable. ........................................................................................................ 20
3.5.5 Closing the Deliverable. ...................................................................................................... 21
3.6 Scope Control .............................................................................................................................. 21
4 Schedule Management Plan ............................................................................................................... 22
4.1 Schedule Development ............................................................................................................... 22
4.2 Roles & Responsibilities .............................................................................................................. 23
4.3 Schedule Control ......................................................................................................................... 24
4.4 Schedule Changes and Thresholds .............................................................................................. 25
5 Cost Management Plan ....................................................................................................................... 26
5.1 Roles and Responsibilities ........................................................................................................... 27
5.2 Cost Management Approach ...................................................................................................... 29
5.3 Cost Monitoring .......................................................................................................................... 29
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 4
Reporting Format ........................................................................................................................................ 30
5.4 Cost Change Control Process ...................................................................................................... 30
6 Stakeholder Management Plan .......................................................................................................... 31
6.1 Responsibilities ........................................................................................................................... 31
6.2 Stakeholder Management Processes .......................................................................................... 32
6.2.1 Stakeholder Identification ................................................................................................... 32
6.3 Stakeholder Analysis ................................................................................................................... 33
6.3.1 Stakeholder Engagement Assessment Matrix .................................................................... 33
6.4 Stakeholder Management Strategies ......................................................................................... 34
7 Resource Management Plan ............................................................................................................... 35
7.1 Roles and Responsibilities ........................................................................................................... 35
7.2 Project Organization Chart .......................................................................................................... 36
7.3 Project Staffing Estimates ........................................................................................................... 37
7.4 Staff Acquisition Strategy ............................................................................................................ 37
7.5 Staff/Team Development Plan .................................................................................................... 37
7.5.1 Team Development ............................................................................................................. 37
7.6 Project Orientation ..................................................................................................................... 38
7.7 Staff Transition and Replacement Plan ....................................................................................... 38
7.8 Transition at Project Completion ................................................................................................ 38
8 Procurement Management Plan ......................................................................................................... 39
8.1 Roles and Responsibilities ........................................................................................................... 39
8.2 Procurement Management Processes ........................................................................................ 40
8.2.1 Procurement Scope ............................................................................................................. 40
8.3 Contract Type .............................................................................................................................. 41
8.4 Decision Criteria .......................................................................................................................... 41
8.5 Procurement Document Preparation ......................................................................................... 41
8.6 Vendor Management .................................................................................................................. 41
9 Requirements Management Plan ....................................................................................................... 43
9.1 Roles and Responsibilities ........................................................................................................... 43
9.2 Requirements Management Approach ...................................................................................... 45
9.2.1 Requirement Types ............................................................................................................. 45
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 5
9.3 Requirements Development ....................................................................................................... 46
9.3.1 Requirements Elicitation ..................................................................................................... 46
9.3.2 Requirements Analysis ........................................................................................................ 46
9.4 Requirements Specification ........................................................................................................ 47
9.5 Requirements Validation through Traceability ........................................................................... 47
9.6 Requirements Change Management .......................................................................................... 48
10 Communication Management Plan ................................................................................................ 49
10.1 Roles and Responsibilities ........................................................................................................... 49
10.2 Communication Management Process ....................................................................................... 50
10.2.1 Identify Stakeholder Communication Requirements ......................................................... 50
10.2.2 Identify Information Collection Sources and Responsibilities ............................................ 52
10.3 Define Guidelines for Project Communication Meetings ........................................................... 53
10.4 Develop Project Meetings Schedule ........................................................................................... 53
10.5 Identify Communication Tools .................................................................................................... 54
10.6 Define Methods for Storage, Retrieval and Disposal .................................................................. 54
11 Risk Management Plan ................................................................................................................... 56
11.1 Roles and Responsibilities ........................................................................................................... 56
11.2 Risk Management Processes ....................................................................................................... 57
11.2.1 Identify Risks ....................................................................................................................... 57
11.3 Analyze Risks ............................................................................................................................... 58
Qualitative Risk Analysis .................................................................................................................... 58
Quantitative Risk Analysis ................................................................................................................. 58
11.4 Risk Response Planning ............................................................................................................... 58
11.5 Risk Monitoring and Control ....................................................................................................... 59
12 Issue Management Plan .................................................................................................................. 60
12.1 Roles and Responsibilities ........................................................................................................... 60
12.2 Issue Identification ...................................................................................................................... 61
12.3 Issue Analysis .............................................................................................................................. 61
12.4 Issue Resolution and Escalation .................................................................................................. 62
12.5 Issue Control, Tracking, and Reporting ....................................................................................... 62
13 Change Management Plan .............................................................................................................. 63
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 6
13.1 Roles and Responsibilities ........................................................................................................... 63
13.2 Change Management Process Description ................................................................................. 64
13.3 Change Request Identification .................................................................................................... 64
13.4 Analysis ....................................................................................................................................... 65
13.5 Approval ...................................................................................................................................... 65
13.6 Implement ................................................................................................................................... 65
13.7 Tracking & Reporting .................................................................................................................. 66
14 Quality Management Plan .............................................................................................................. 67
14.1 Roles and Responsibilities ........................................................................................................... 67
14.2 Approach ..................................................................................................................................... 68
14.3 Process Quality ............................................................................................................................ 69
14.4 Process Definition ....................................................................................................................... 69
14.5 Process Measurement ................................................................................................................ 70
14.6 Process Improvement ................................................................................................................. 70
14.7 Product Quality ........................................................................................................................... 70
14.8 Product Definition ....................................................................................................................... 71
14.9 Product Measurement ................................................................................................................ 71
14.10 Product Improvement ............................................................................................................. 72
1 Introduction The Oregon Public Utility Commission (PUC or Commission) relies on a variety of applications to support its business functions related to the conduct of official proceedings. These include a custom-built legacy “BizApps” docketing system and Huddle, a third party service for eDiscovery. The PUC seeks to replace these systems with an integrated, cohesive, and efficient solution for internal and external stakeholders doing business with the Commission. By replacing the outdated and unsupported docketing system, PUC will be better equipped to serve stakeholders and the citizens of Oregon.
The Dockets and Discovery project management plan defines how the Dockets and Discovery project is executed, monitored and controlled, and closed.
Project elements includes:
Project Governance
Scope Management Plan
Schedule Management Plan
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 7
Cost Management Plan
Stakeholder Management Plan
Resource Management Plan
Procurement Management Plan
Requirements Management Plan
Communication Management Plan
Risk and Issue Management Plan
Change Management Plan
Quality Management Plan
1.1 Project Overview
Currently, stakeholders use and access several distinct systems to participate in cases before the Commission. The current docketing system does not accommodate secure electronic records management for protected information or voluminous documents. Parties must provide the PUC and each other with physical copies of these protected or voluminous documents. While the current solution for eDiscovery is used for some dockets, because of the labor-intensive set up and maintenance, it has not been practical to use that solution for the electronic sharing of protected information. At a high level, significant risks of the existing system include major cybersecurity issues in the current architecture, outdated code, unsupported programming language, and 20 years of patchwork on the system.
Additionally, the current docketing system does not have the ability to accommodate secure electronic records management for protected information, the capacity to handle voluminous documents, or the ability to provide document access in native format. Parties must provide the PUC and each other with physical copies of these protected, voluminous, or native-format documents.
Although the use of a third party service (Huddle) for eDiscovery provides greater security, difficulties with set-up and maintenance have prevented its use for the electronic sharing of protected information. Further, since the current eDiscovery solution is a third-party service (Huddle) solution, records must be imported to a PUC or state-owned records management solution. Our current process is to collaborate with utility companies and intervenors using Huddle. We then export the files from Huddle to a PUC- owned file storage as the official record.
A new integrated solution for docketing and eDiscovery will increase efficiency for the PUC and its stakeholders. Currently, external stakeholders are required to use and access several distinct systems to participate in cases before the Commission. These systems include eDockets, eFiling through electronic mail, and eDiscovery (Huddle). Internal stakeholders, in addition to the systems accessed by external stakeholders, access three modules in BizApps: Dockets, List & Labels, and Data Requests. The targeted solution will integrate these systems, thus decreasing the number of systems stakeholders must learn
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 8
and use to submit and access documents. The proposed solution is designed to increase stakeholder convenience and efficiency and staff productivity because information will be available in a more timely fashion, will be easier to locate, and will be able to be stored and accessed in a variety of formats, such as providing complex economic forecasting models in their native Excel format.
BizApps modules not included in the project include Residential Service Protection Fund (Oregon Telephone Assistance Program and Telecommunications Devices Assistance Program) and Consumer Services. Agency personnel will examine these modules for improvements after completion of this project.
This investment in a new integrated solution will reduce vulnerability to cyber-attacks, streamline business processes for internal and external stakeholders, and allow for greater transparency as more documents will be accessible to the public.
Failure to act increases risk of the docketing system failure, cyber insecurity, improper records retention, and inadvertent allowance of utility actions without proper review. Relying on a system for case management when the system is based on source code that is no longer supported creates an immitigable risk of system failure that could impact residents statewide in relation to rates and services provided by regulated utility companies.
The project was split into two major phases. Phase 1 consisted of a Business Process Analysis of the system’s current and future states. This phase is completed; and using the information gathered during this phase, solution requirements were identified and documented.
Phase 2 includes the design, development, and implementation of a new system that will replace the existing Docketing and eDiscovery systems. The PUC is in the process of contracting with a vendor for Phase 2.
In order to complete the project by a revised date of the end of October 2021, the project must move forward expeditiously. In order to achieve the desired results, the solution must meet the requirements identified in Phase 1 of this project, including security and accessibility.
The total purchased information technology solution product cost plus five years of support, and PUC staff time is estimated to be $1.5 million including PUC employee time.
2 Project Governance Project governance is an oversight function that is aligned with the PUC’s governance model and that
encompasses the project life cycle. Project governance framework provides the project manager and
team with structure. Processes, decision making models and tools for managing the project, while
supporting and controlling the project for successful delivery.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 9
The governance process benefits projects by achieving the following objectives:
Ensures timely decisions are made at the appropriate level.
Ensures the project maintains sponsorship and funding.
Provides strategic leadership and direction.
Fosters a culture of accountability and transparency.
Provides oversight and guidance to improve the potential for success.
Promotes efficient and effective teams, reduced risks, and effective use of resources.
Ensures needed resources are available.
Ensures that business impacts are regularly identified, communicated, and understood by
stakeholders and business partners.
2.1 Governing Bodies The following governing bodies have a role in governing the project, such as a Steering Committee and
Change Control Board (CCB). The Steering Committee represents impacted stakeholders or units and
provides strategic direction to the project to ensure fulfillment of its goals and objectives.
Committee Name Responsibilities
Committee Type
(Decision- Making, Advisory,
Informational)
Meeting Frequency
Comments and Assignments
Steering Committee
Project Oversight Decision- Making
Monthly Governance of the project representing the interest of stakeholders.
Resolve Issues Escalated by Project Sponsor.
Project Advisory Committee
Assist in the direction of the project
Advisory Monthly Advise the Project Sponsor on project requirements, project scope, and project progress.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 10
Committee Name Responsibilities
Committee Type
(Decision- Making, Advisory,
Informational)
Meeting Frequency
Comments and Assignments
Change Control
Board
Review and analyze
change requests and
ensure that
scope/schedule/budget
impacts are identified
and acceptable
Decision-
Making
Weekly Approve or reject change request. Some change requests may need to be escalated to the Project Sponsor and Steering Committee.
2.2 Project Governance Structure For this project, the PUC is utilizing a functional organization as shown in the following diagram. Because
the Project Manager is also the Chief Operating Officer (COO), this structure maintains the advantage of
“unity of command” without the disadvantage of slow communications within multiple functions to
have input. The COO is a member of the agency’s Leadership Team, which also includes the Project
Sponsor (Chief Administrative Law Judge) and Utility Program Director (a primary user). Additionally, the
Chief Financial Officer reports to the COO and the COO is ultimately responsible for the finances of the
agency.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 11
2.3 Roles and Responsibilities The table of Roles and Responsibilities provides a description of duties for project roles governing the
project.
Name Role Responsibility
Michael Grant (Executive Director)
Executive Sponsor Provides leadership on culture and values.
Owns the business case.
Keeps project aligned with organization's strategy and portfolio direction.
Governs project risk.
Works with other sponsors.
Focuses on realization of benefits.
Recommends opportunities to optimize cost/benefits.
Ensures continuity of sponsorship.
Provides assurance.
Provides feedback and lessons learned.
Commission Chair
Chief Administrative
Law Judge
Project Sponsor
Chief Operating Officer
Project Manager
Chief Information Officer
Assistant Project Manager
Utility Program Director
Executive Director
Project
Advisory
Committee Project Team
Change Control Board
Steering Committee
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 12
Name Role Responsibility
Nolan Moser Project Sponsor Oversee project governance and serve as final arbiter on disputes among stakeholders.
Approve any changes in scope, schedule, or budget when these change beyond percentages specified in their individual sections of this document.
Ensure that external governing entities are properly consulted and engaged to provide timely approval of changes where required.
Ensure that Stakeholders who need to provide advice about decisions have opportunity for meaningful input.
Maintain a shared vision among steering committee members inside and outside the meetings.
Monitor risks and issues to make sure that matters are appropriately referred for decision promptly.
Remove obstacles.
Chair the Steering Committee.
Bryan Conway Diane Davis Lori Koho John Crider Jonathan Felling Michael Dougherty (non-voting) Qing Liu (non- voting)
Steering Committee
Recommend to the Project Sponsor any changes in scope, schedule, or budget when these change beyond percentages specified in their individual sections of this document.
Simultaneously provide global governance of the project and represent the interest of internal and external stakeholders.
Review and address project audit, quality assurance and risk assessment findings.
Actively engage in project status reviews to ensure the control of the scope, schedule and budget
Identify and resolve conflicts between project objectives/activities and other factors, such as organizational policies, business practices, standards, or relevant requirements.
Ensure compliance with relevant regulatory and contractual requirements and organizational policies.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 13
Name Role Responsibility
Michael Dougherty Project Manager Make daily decisions based on direction provided by the Project Sponsor or when changes are within the agreed upon delegated authority.
Ensure that other Stakeholders have opportunities and information necessary to provide advice regarding pending decisions.
Communicate with the Project Sponsor regarding decisions made.
Escalate issues for resolution to the Project Sponsor when they are outside the Project Manager’s span of control.
Ensure that decision items are properly analyzed
before presenting them for decision.
Compile and track requested changes to scope, requirements, or design details.
Qing Liu Assistant Project Manager
Make recommendations based on direction provided by the Project Manager or when changes are within the agreed upon delegated authority.
Ensure that other Stakeholders have opportunities and information necessary to provide advice regarding pending decisions.
Escalate issues for resolution to the Project Manager.
Ensure that decision items are properly analyzed
before presenting them for recommendation.
Assist in compiling and tracking requested changes to scope, requirements, or design details.
Sarah Rowe Caroline Moore Kimberly Toews
Project Advisory Committee
Advise the Project Sponsor, Project Manager, and Assistant Project Manager on project requirements, project scope, and project progress.
Qing Liu
Diane Davis
Jonathan Felling
Michael Dougherty
Lori Koho
John Crider
Change Control
Board (CCB)
Analyze the requested changes.
Approve or reject requested changes. Final approval may also need to be ratified by the Project Sponsor and Steering Committee.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 14
3 Scope Management Plan Scope Management is the collection of processes to ensure that the project includes all the work
required to complete it while excluding all work that is not necessary to complete it. The Scope
Management Plan describes how the project will control the activities and deliverables and the roles
and responsibilities of everyone involved.
The Scope Management addresses the following:
• Who has authority and responsibility for scope management
• How the scope is defined (i.e. Requirements, Scope Statement, WBS, WBS Dictionary, Statement
of Work, etc.)
• How the scope is measured and verified (i.e. Quality Checklists, Scope Baseline, Work
Performance Measurements, etc.)
• Who is responsible for final acceptance of project scope
3.1 Scope Development The project’s Scope Management will follow a five step process: Collect Requirements, Define Scope,
Create WBS, Verify Scope, and Control Scope.
1. Collect Requirements – The project team will define and document the requirements needed to
meet all project objectives. After the requirements have been identified and documented, the
team will collectively discuss details associated with meeting each requirement, conduct
interviews and follow-on discussion to clarify the requirements, and document the
requirements in sufficient detail to measure them once the project begins the execution phase.
This documentation also serves as an input to the next step in the process which is to define
scope.
2. Define Scope – The project team will develop a project scope statement that includes
deliverables, assumptions, and constraints and establishes the framework within which project
work must be performed.
3. Create WBS – The project team will create a WBS by breaking project deliverables down into
work packages.
4. Verify Scope – The project team will follow the documented deliverable acceptance process to
review and accept all deliverables.
5. Control Scope – The project team will follow the change management plan if there are any
changes to the scope baseline.
For this project, scope management will be the sole responsibility of the Project Manager. The Project
Manager, Sponsor and Stakeholders will establish and approve documentation for defining and
measuring project scope that includes deliverable quality checklists and work performance
measurements. Scope verification happens at the end of each project phase-or as major deliverables are
created. Scope verification is ensuring that the deliverables the project creates are in alignment with the
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 15
project scope. Quality checklists will be developed for each deliverable. Based on feedback and input
from the Project Manager and Stakeholders, the Project Sponsor is responsible for the acceptance of the
final project deliverables and project scope.
Proposed scope changes may be initiated by any member of the project team. All change requests will
be managed though the project change control process.
3.2 Roles and Responsibilities This section defines the role of the Project Manager, Project Team, Stakeholders and other key persons
who are involved in managing the scope of the project. It should state who is responsible for scope
management and who is responsible for accepting the deliverables of the project as defined by the
project’s scope. Any other roles in scope management are also be stated in this section.
Name Role Responsibility
Nolan Moser Project Sponsor Approve Scope Management Plan.
Provide and approve high-level scope definition (Project Charter).
Review escalated scope issues and provide direction for resolution.
Approve major scope change requests.
Confirm all Scope Management decisions.
Approve or deny scope change requests as appropriate.
Evaluate need for scope change requests.
Accept project deliverables.
Bryan Conway Diane Davis Lori Koho John Crider Jonathan Felling
Steering Committee Participate in Scope definition activities.
Review major scope change requests and makes final decision or recommendations to the Project Sponsor.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 16
Name Role Responsibility
Michael Dougherty Project Manager Oversee the development of the Scope Management Plan.
Assume overall responsibility for scope management.
Manage deliverable verification and acceptance.
Measure and verify project scope.
Facilitate scope change requests.
Facilitate impact assessments of scope change requests.
Approve scope change requests within their authority.
Escalate scope and change issues as necessary.
Organize and facilitate scope change control meetings.
Communicate outcomes of scope change requests.
Update project documents upon approval of all scope changes.
Qing Liu Deliverable Lead Review deliverable for alignment to requirements.
Forward deliverable for review to appropriate groups.
Track deliverable status in log.
Compile written feedback from reviewers.
Work with PM to determine if deliverable should be accepted or rejected.
Diane Davis Lori Koho John Crider Don Arct
Project Team Members and Subject Matter Experts (SMEs)
Help develop the project scope statement.
Submit scope change requests.
Review scope change requests when assigned
Provide feedback as and when required.
Participate in team-level scope change reviews.
Participate in defining change resolutions.
Evaluate the need for scope changes and communicate them to the project manager as necessary.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 17
3.3 Scope Definition The project was split into two major phases. Phase 1 consisted of a Business Process Analysis of the system’s current and future states. This phase is completed; and using the information gathered during this phase, solution requirements were identified and documented.
The scope for this project was defined through a comprehensive requirements collection process. First,
a thorough analysis was performed on the agency’s current software applications based on employee
and user feedback. From this information, the project team developed the project requirements
documentation, the requirements management plan, and the requirements traceability.
The project description and deliverables were developed based on the requirements collection process
and input from subject matter experts in software design, technical support, programming and business
applications. The approved scope statement baselines the scope and is located in the project repository,
DD Project Scope Management Plan - 11.16.2020.docx.
3.4 Work Breakdown Structure (WBS) Create WBS is the process of subdividing project deliverables and project work into smaller, more
manageable components. The key benefit of this process is that it provides a structured vision of what
has to be delivered.
The WBS for this project was established during Quarter 1 by the CIO, Public Records Request Officer,
and Chief Administrative Law Judge and all team members who brainstormed all work required to
complete project deliverables successfully.
First all project deliverables/milestones were identified and then decomposed one at a time into a
detailed and sequential list of activities required to complete the deliverable or milestone.
To effectively manage the work required to complete this project, it will be subdivided into individual
work packages. This will allow the Project Manager to more effectively manage the project’s scope as
the project team works on the tasks necessary for project completion. The project is broken down into
three phases: the design phase, the programming phase, and the testing phase. Each of these phases is
then subdivided further down to work packages. Once all the work packages and tasks are defined, the
task durations, resources and dependencies will be documented in the schedule.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 18
3.5 Scope Validation
The project’s deliverables will be reviewed by the project team and accepted through the project’s
formal acceptance process. Any comments or revisions will be communicated directly to the vendor
with a response managed against the project timeline identified in the SOW. A “user acceptance” form
will be used to verify the deliverable acceptance by the project team and vendor. Any disputes will be
resolved according to the stated contract. All deliverables will only be accepted if they meet the
respective acceptance criteria identified in the contract.
Deliverable Review Process Details
Process Step
Description Primary Responsible
Party
Available Tools/ Templates
1 Deliverable is submitted. Submissions should
be clearly labeled according to the approved
Deliverable Formatting Guidelines.
Vendor Vendor Contract
2 Acknowledge receipt of deliverable to vendor
and forward to deliverable lead for review.
PM
3 Review deliverable and forward to other
reviewers for feedback with a feedback log.
Deliverable Lead
4 Review deliverable. Deliverable Lead
and Reviewers
5 Record feedback in the Feedback Log and
email Deliverable Lead when done.
Reviewers Feedback Log
6 Make recommendation with compiled written
feedback to project manager via the
Deliverables Control mailbox. Record all
feedback in Feedback Log.
Deliverable Lead Feedback Log
Deliverables Control
mailbox developed by
IS
If deliverable is rejected, proceed to step 9. If
approved, proceed to step 11.
PM
9 Prepare letter of rejection and send letter
with Deliverable Lead’s compiled written
feedback to vendor.
PM Deliverable Rejection
Letter, Deliverables
Control mailbox,
Feedback Log
10 Address feedback and return to step 1.0. Vendor
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 19
Process Step
Description Primary Responsible
Party
Available Tools/ Templates
11 Prepare letter of approval, obtain signature of
project team member with sufficient
signature authority, and e-mail to vendor
along with Deliverable Lead’s compiled
written feedback.
PM Deliverable Approval
Letter, Deliverables
Control mailbox,
Feedback Log
12 File all submissions of deliverable, all feedback
and recommendations, and all approval and
rejection letters.
PM
3.5.1 Deliverable Tracking. Schedules of deliverables are maintained by the PM. They are saved in the following location: P:\Agency
Projects\BizApps Dockets and Discovery Replacement/Tools
The deliverable schedule tracks deliverable due dates, the receipt date of deliverables, and their
associated invoices, and both due dates and receipt dates for agency feedback. The schedule also
identifies who the Deliverable Lead is as well as additional reviewers. A task will be identified for each
deliverable in the schedule to track the entire review process. The task will be updated by the
Deliverable Lead at each step of the process to ensure the review is on schedule and due dates are met.
The Project Sponsor and Project Manager will assist the Deliverable Lead in identifying other reviewers
for deliverables. Additional reviewers review the deliverable based on their specific area of expertise
and provide feedback to the Deliverable Lead.
3.5.2 Receive the Deliverable. All deliverables are sent electronically in Word to the Deliverables Control Microsoft OneDrive:
https://opucteams-
my.sharepoint.com/personal/qingliu_opucteams_onmicrosoft_com/_layouts/15/onedrive.aspx?id=%2F
personal%2Fqingliu%5Fopucteams%5Fonmicrosoft%5Fcom%2FDocuments%2FBizApps%20D%26D%20P
roject.
The Deliverable Lead will receive notice of the deliverable through the file sharing location and logs
receipt of all deliverables in the Deliverable Tracking Spreadsheet when received. The Deliverable Lead
assignees access to users with access to this file sharing location.
3.5.3 Prepare and Route Deliverable. Once a deliverable has been received, the Deliverable Lead notifies the identified reviewers by e-mail.
Refer to the Deliverable Tracking Spreadsheet for the names of Deliverable Leads and reviewers. The
Deliverable Checklist will also be located at the file share location along with a due date to the reviewers
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 20
of when their feedback along with their recommendation is due. The Deliverable Lead will email the
reviewer of the deliverable to allow timely response. Refer to the schedule for feedback due dates.
3.5.4 Review of Deliverable. Any submitted deliverable will first be reviewed by the Deliverable Lead measured against the
Deliverable Checklist, any applicable contract requirements, or industry standards, as well as adherence
to mandated templates or formats. All pre-defined acceptance criteria will be referenced and used in
the review. This preliminary review will be supplemented as necessary by involved stakeholders.
While performing a review, feedback is recorded on the Feedback Log in the project repository.
Providing written feedback is a critical and mandatory piece of the deliverable management process.
Feedback provides a written record of the review and establishes due diligence by project staff.
When rejecting a deliverable the state provides the feedback recorded in the feedback log to the
vendor, who must modify the deliverable based on feedback prior to resubmitting. Examples of
feedback are corrections of information within the deliverable, disagreement on items within the
deliverable, needed clarification on items, or missing items that the state thinks should be included in
the deliverable.
The Deliverable Lead will conduct a group walkthrough with all reviewers to discuss their feedback as a
group after doing the initial individual review.
The Deliverable Lead will:
Determine what feedback needs to be included with the recommendation for approval or
rejection of the deliverable.
Consolidate and compile all the feedback from the Feedback Log.
Upload the final feedback and recommendation to the Control Deliverables file share location.
Makes the final recommendation on whether to approve or reject the deliverable.
A group walkthrough may also include the vendor to discuss the feedback or the basis for a rejection of
a deliverable.
If the deliverable is rejected, the Deliverable Lead will:
Prepare the rejection letter using the Deliverable Rejection Letter Template.
Obtain the appropriate signature for the rejection letter.
E-mail the rejection letter to the vendor along with the feedback outlining the basis for the
rejection.
The vendor will modify the deliverable based on the feedback and resubmit the deliverable to the
Deliverables Control Microsoft OneDrive for another review. In all cases, the Deliverable Lead will
expeditiously (within 24 hours) email the identified reviewers. This process needs to be repeated until
the deliverable meets the criteria for approval.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 21
The Deliverable Lead may choose to conditionally approve a deliverable to move forward. Conditional
acceptance is only used for minor corrections. The vendor will have TBD days to make the needed
changes or provide additional materials before resubmitting the deliverable. The deliverable may not
need to go through a full review again.
The Deliverable Lead may only need to perform a review of the corrections and a spot check of the rest
of the deliverable to ensure no other errors are introduced. The deliverable is not considered closed
until all the corrections are made. A letter is sent to the vendor with the conditional approval terms
using the Deliverable Conditional Approval Letter Template.
3.5.5 Closing the Deliverable. When a deliverable is approved it can be closed. The PM will prepare the approval letter using the
Deliverable Approval Letter Template, get the appropriate signature on the approval letter and e-mail
the signed letter to the vendor.
The Deliverable Lead will upload the final approved deliverable and approval letter to the project
repository under P:\Agency Projects\BizApps Dockets and Discovery Replacement\D&D Project
Replacement Forms and Logs and record the date of approval in the corresponding tracking tool.
3.6 Scope Control The Project Manager and the project team will work together to control the scope of the project. The
project team will ensure that they perform only the work described in the WBS and scope. The Project
Manager will oversee the project team and the progression of the project to ensure that the scope
control process is followed.
Any request for change in project scope will be processed through the project’s change management
process. Proposed scope changes will be reviewed. If the Project Manager and Project Sponsor
determine that the request has merit, it will be analyzed for its impact to project time and project costs,
and a risk assessment of the scope change will be conducted. If the change is approved, the project’s
WBS and WBS dictionary will be updated and re-baselined, the project schedule will be updated and
may be re-baselined, and the project’s requirements set will be updated.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 22
4 Schedule Management Plan The Schedule Management Plan is a component of the project management plan that establishes the
criteria and activities for developing, monitoring, and controlling the schedule. The PUC will be using
Microsoft Project to create and maintain the project schedule. Any change will be discussed at the
weekly status update meeting.
It is important to note that this project requires EIS Stage Gate approval. PUC will endeavor to meet
every EIS request with quality submission as to keep momentum on this project. The project schedule
contemplates EIS involvement and adherence to the schedule should be maintained by the project team
for project integrity.
4.1 Schedule Development Project schedules will be created and managed using MS Project starting with the deliverables identified
in the project’s Work Breakdown Structure (WBS). Activity definition will identify the specific work
packages which must be performed to complete each deliverable. Activity sequencing will be used to
determine the order of work packages and assign relationships between project activities. Activity
duration estimating will be used to calculate the number of work periods required to complete work
packages. Resource estimating will be used to assign resources to work packages to complete schedule
development.
Once a preliminary schedule has been developed, it will be reviewed by the project team and any
resources assigned to project tasks. The project team and resources must agree to the proposed work
package assignments, durations, and schedule. Once this is achieved the project sponsor will review and
approve the schedule and it will then be baselined.
The following will be designated milestones for the project schedule:
• Completion of scope statement and WBS/WBS Dictionary
• Baselined project schedule
• Approval of final project budget
• Project kick-off
• Approval of roles and responsibilities
• Requirements approval
• Completion of data mapping/inventory
• Project implementation
• Acceptance of final deliverables
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 23
4.2 Roles & Responsibilities The following table describe the Roles and Responsibilities of team members involved in the Schedule
Management process.
Name Role Responsibility
Nolan Moser Project Sponsor Review proposed schedule.
Approve final schedule before it is baselined.
Bryan Conway Diane Davis Lori Koho John Crider Jonathan Felling
Steering Committee Review schedule.
Michael Dougherty Project Manager Facilitate work package definition, sequencing, and estimating durations and resources with the project team.
Create project schedule.
Validate schedule with project team, stakeholders and project sponsor.
Obtain schedule approval from project sponsor and baseline schedule.
Lead the project team in Schedule Management related activities.
Review, evaluates and provides feedback on schedule progress reports and time-risk recommendations from the Project Coordinator.
Provide regular status information in meetings with the Project Sponsor and steering committees.
Diane Davis JP Batmale John Crider Lori Koho Roger White
Functional Managers Review and approves time estimates for staff reporting to them.
Notify the Project Manager and Project Coordinator of workload changes that may affect the schedule.
Work with the Project Manager and Project Coordinator on resource schedule-related items for risks, issues, and possible changes.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 24
Name Role Responsibility
Qing Liu Project Coordinator Assist in the development of the Schedule Management Plan.
Perform daily schedule-related analysis and update activities.
Lead schedule management activities, communicates schedule status, maintains the project schedule and provides updates.
Make schedule risk, issue and change recommendations to the Project Manager.
Diane Davis Lori Koho John Crider Don Arct
Project Team Members Participate in work package definition, sequencing, and duration and resource estimating.
Review and validate proposed schedule.
Notify the Project Manager and Project Coordinator about possible schedule risks and issues.
Provide accurate progress reporting during the project.
4.3 Schedule Control The project schedule will be reviewed and updated as necessary on a bi-weekly basis with actual start,
actual finish, and completion percentages which will be provided by task owners.
The project manager is responsible for holding bi-weekly schedule updates/reviews, determining
impacts of schedule variances, submitting schedule change requests, and reporting schedule status in
accordance with the project’s communication plan.
The project team is responsible for participating in bi-weekly schedule updates/reviews, communicating
any changes to actual start/finish dates to the project manager and participating in schedule variance
resolution activities as needed.
The project sponsor will maintain awareness of the project schedule status and review/approve any
schedule change requests submitted by the project manager.
To ensure the objectivity of status reporting, a consistent performance assessment methodology
determines activity percent complete. For activities with planned durations of 10 working days or less,
• 0%
• 25%
• 50%
• 100%
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 25
Milestones always use a 0/100 methodology. For tasks with more than 10 working days of planned
duration, the performance measurement methodology must be documented in the task Notes field.
As part of the status cycle, the Project Manager will conduct a health assessment and address any red
flags that violate the guidelines laid out in the schedule management standard. The health assessment
also indicates the project’s Baseline Execution Index (BEI), which is the total number of tasks completed
divided by the total number of tasks expected to be completed. This is calculated weekly.
The following scheduled reports will be available at the specified time intervals during the project:
Report Frequency Author Reporting Responsibility
Resource Task Lists and Work Packages
Weekly on Mondays
Project Coordinator Generate individual resource task lists and work packages from the scheduling tool and make them available to project team members
Project Schedule Report Monthly on the 4th of each month
Project Coordinator Generate the schedule progress report for use in the project status meeting
Project Master Schedule (Gantt chart)
Monthly Project Coordinator Generate the updated schedule Gantt chart for use in the project status meeting
Steering Committee Project Report
3 days before each Steering Committee Meeting
Project Manager Generate the Steering Committee project status report for presentation
4.4 Schedule Changes and Thresholds If any member of the project team determines that a change to the schedule is necessary, the project manager and team will meet to review and evaluate the change. The project manager and project team must determine which tasks will be impacted, variance as a result of the potential change, and any alternatives or variance resolution activities they may employ to see how they would affect the scope, schedule, and resources. If, after this evaluation is complete, the project manager determines that any change will exceed the established boundary conditions, then a schedule change request must be submitted. Submittal of a schedule change request to the steering committee for approval is required if the change is estimated to reduce the duration of the overall baseline schedule by 10% or more, or increase the duration of the overall baseline schedule by 10% or more. If the project’s BEI dips below 0.85 or a deliverable is forecasting beyond its contractual due date, the Project Manager will develop a corrective action plan. The schedule status is yellow with a BEI of 0.90 and red at 0.85.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 26
Any change requests that do not meet these thresholds may be approved by the project sponsor after vetting by the Change Control Board. Once the change request has been reviewed and approved, the project manager is responsible for adjusting the schedule and communicating all changes and impacts to the project team, project sponsor, and stakeholders.
5 Cost Management Plan Project Cost Management includes the processes involved in planning, estimating, budgeting, financing,
funding, managing, and controlling costs so that the project can be completed within the approved
budget.
The cost management plan is a component of the project management plan and describes how the
project costs will be planned, structured, and controlled. The cost management plan includes life cycle
costs, value analysis, and risk. The following project cost estimates establishes the budget for this
project. As previously mentioned, time spent on project by members will be tracked in MS Project and
costed at the fully loaded rate.
Spending for the project will be reported to and approved by the Project Manager. The estimated cost
for a Docket and eDiscovery project of $1,518,693 is based on the selected vendor cost; and by
calculating the fully loaded rates of PUC personnel. All spending will be recorded by the PUC business
office and available for audit purposes.
The Project Manager (PUC COO) is responsible to deliver the project on time and on budget. Budget or
timeline changes / concerns are first discussed with the Project Manager when they occur. The Project
Manager will notify agency leadership of any change in budget or timeline that affects the budget.
The legislature approved a $400,000 Policy Option Package for AY 17-19. Because of project timing and
actual quotes, the PUC will go to the E-Board to request an increase in limitation to approximately
$584,951 for one-time implementation cost and the prorated first year ongoing cost that will incur in
this current biennium 2019-2021 (AY21).
Staff time for the PUC SQL DBA and two developers and members of the project ($472,636) is calculated
separately (as they are not incremental costs) and is not included in the vendor cost of the Docket and
eDiscovery product. The estimated five-year cost for this project is $1.046 million, which includes
$116,000 annual ongoing costs (non-incremental).
The current budget for the project is $1,518,693. Although EIS procedure currently allows this to be +/-
10%, (up to $1,670,562); the PUC as an Other Funded agency will have to consider budget limitation and
cash flow to determine if we will proceed at greater stated costs. Although EIS maintains the standard,
EIS is not involved in deciding if the OPUC can go over the project budget
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 27
5.1 Roles and Responsibilities
Name Role Responsibility
Nolan Moser Project Sponsor Provide overall business leadership to ensure that cost and funding requirements are met.
Ensure requests for cost and funding changes have followed the approved Change Control Process, and that approved changes have been incorporated into cost and funding documents within the assigned timeframe.
Review and approve cost and funding documents prior to sending to control agencies.
Manage project budget to avoid cost overruns.
Bryan Conway Diane Davis Lori Koho John Crider Jonathan Felling
Steering Committee Actively engage in project status reviews to ensure the control of the budget.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 28
Name Role Responsibility
Michael Dougherty Project Manager Lead team in the development of the Cost Management Plan.
Provide regular status information and makes approval recommendations
Ensure the overall cost management effort is being executed in accordance with the plan.
Ensure the entire project team, State, and contractor (if applicable) are following this plan.
Ensure adherence to all of the other project processes that interact with or provide input to the cost management effort.
Ensure there are sufficient resources to execute this plan.
Ensure cost management activities are being performed within the assigned timeframe.
Manage and reports on the project’s costs.
Present and lead the review of project’s cost performance for preceding month at monthly project status meeting.
Account for cost deviations and presents project sponsor with options for getting project back on budget.
Barbara Seaman Financial Lead and/or
Financial/Budget
Manager
Work with the Project Manager and Financial Analyst to develop the Cost Management Plan.
Manage processes and activities outlined in the Cost Management Plan.
Lead overall cost management effort and the cost repository containing the cost and funding documents.
Ensure cost processes are organized, managed, and controlled and that all issues are identified and resolved in promptly to minimize rework.
Contribute to the development of cost and funding documents.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 29
Name Role Responsibility
Mia Seo Financial Analyst(s)
and/or Budget
Specialist
Assist in the development of the Cost Management Plan.
Serve as subject matter expert for the cost management processes.
Assist the Project Manager and Financial Lead in capturing, verifying, and communicating project cost and funding requirements.
Legislative Fiscal Officer Chief Financial Office Analyst
Funding Partners (such
as state, local, or
federal governments)
Approve significant cost variances via Special Project Reports in cases where such reporting is necessary.
5.2 Cost Management Approach The Project Manager will be responsible for managing and reporting on the project’s cost throughout
the duration of the project. During the monthly project status meeting, the Project Manager will meet
with management to present and review the project’s cost performance for the preceding month. The
Project Manager is responsible for accounting for cost deviations and presenting the Project Sponsor
with options for getting the project back on budget. The Project Sponsor has the authority to make
changes to the project to bring it back within budget.
5.3 Cost Monitoring A variance of up to 15% of original or re-baselined cost will change the status of the cost to cautionary
and the value will be changed to yellow in the project status report. A variance of more than 15% of
original or re-baselined cost will change the status of the cost to alert and the value will be changed to
red in the project status report. Corrective actions will require a project change request and must be
approved by the Project Sponsor.
Managing the total cost of ownership for the project will include building a total cost of ownership
model for the life of the project. It will establish the total project baseline budget and a time-phased
baseline budget by month and fiscal year for all phases. Inputs are vendor software and implementation
costs, contract deliverable payments, project team staffing costs, budgeted amounts for infrastructure
costs, and all other anticipated costs to the project.
The activities in the table below will be used to manage project costs:
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 30
Cost Management Activity
Date(s) Administered
Participant Roles Name of
Facilitator/Decision Maker
Monthly project
budget review
12/03/2020 and
first week of every
month
Project Manager
Project Financial Lead
Michael Dougherty Barbara Seaman
Quarterly project cost
forecast
01/16/2021 and
third week of
every quarter
Project Sponsor
Project Manager
Project Financial Lead
Nolan Moser Michael Dougherty Barbara Seaman
Change Request
budget impact analysis
As required Project Financial Lead
Change Request Analyst
Barbara Seaman Qing Liu
Reporting Format Cost management measures will be reported in the monthly status report. All cost variances outside of
the thresholds identified in this Cost Management Plan will be identified, along with any planned
corrective actions. Change requests triggered by project cost overruns will be identified and tracked in
the monthly status report.
At or under Original or Re-baselined Cost
Within 0-15% of Original or Re-baselined Cost
More than 15% of Original or Re-baselined Cost
The Project Manager will be responsible for managing and reporting on the project costs throughout the
duration of the project. During the monthly project status meeting, the Project Manager will present
and review the project’s cost performance for the preceding month.
5.4 Cost Change Control Process The Project Manager will present the Project Sponsor with options for corrective actions within five
business days from when the cost variance is first reported. Within three business days from when the
Project Sponsor selects a corrective action option, the Project Manager will present the Project Sponsor
with a formal Cost Variance Corrective Action Plan. The Cost Variance Corrective Action Plan will detail
the actions necessary to bring the project back within budget and the means by which the effectiveness
of the actions in the plan will be measured. If the corrective actions to be taken result in a change, the
project’s overall Change Control Process must be followed as well. Upon acceptance, the project will be
updated to reflect the corrective actions.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 31
6 Stakeholder Management Plan Stakeholder Management includes the processes required to identify the people, groups, and organizations that could impact or be impacted by the project, to analyze stakeholder expectations and their impact on the project, and to develop appropriate management strategies for effectively engaging stakeholders in project decisions and execution.
During Strategic Plan stakeholder sessions in 2018 and 2019, multiple stakeholders commented on the need for a web-based filing system similar to the one used by the California Energy Commission. Numerous stakeholders were also frustrated with the limitation of the third-party Huddle system in terms of handling protected information. A goal for the Commission was to update to an integrated system to handle filings and discovery and allow for convertibility (Excel, Word, etc.) of different files.
Because Stakeholders are completely engaged in PUC’s processes, we plan to work with a major customer group (Citizens’ Utility Board) and a major utility (PGE) during development and testing of the Dockets and eDiscovery system. This will include uploading dockets, receiving notification of uploads, viewing of all document, downloading documents, authentication, integration, and time stamping. We have selected these two groups based on long-term relationships and docketing activity of these two groups.
6.1 Responsibilities
Name Role Responsibility
Nolan Moser Project Sponsor Identify Stakeholders.
Provide input into categorization of Stakeholders.
Provide advice in preparation strategies to be included in the Stakeholder Management Plan.
Approve the Stakeholder Management Plan.
Play a lead role in representing the project to external Stakeholders.
Bryan Conway Diane Davis Lori Koho John Crider Jonathan Felling
Steering Committee
Provide advice and review the Stakeholder Management Plan.
Assist in identification and classification of Stakeholders.
Assist in development of management strategies.
Act as a key point of contact with other program representatives regarding business aspects of the project.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 32
Name Role Responsibility
Michael Dougherty Project Manager Initiate effort to develop the Stakeholder Management Plan.
Guide Stakeholder analysis.
Complete the Stakeholder Management Plan
Manage the schedule and activities related to stakeholder communication and engagement.
Diane Davis Stakeholder Manager
Undertake the stakeholder analysis in consultation with the project team and the sponsoring organization’s staff.
Write the Stakeholder Management Plan.
Review with the project team and the sponsoring organization’s staff.
Lead the effort to complete the approach identified in the Stakeholder Management Plan.
Diane Davis JP Batmale John Crider Lori Koho Roger White
Business Lead(s) Provide advice and review the Stakeholder Management Plan.
Assist in identification and classification of Stakeholders.
Assist in development of management strategies
Provide information to support Stakeholder communication.
Jonathan Felling Don Arct
Technical Lead Provide advice and review the Stakeholder Management Plan.
Assist in identification and classification of Stakeholders.
Assist in development of management strategies
Provide information to support Stakeholder communication.
6.2 Stakeholder Management Processes
6.2.1 Stakeholder Identification The project team will conduct a brainstorming session to identify stakeholders for the project. The
brainstorming session will include the primary project team and project sponsor. The session will be
broken down into two parts. The first part will focus on internal stakeholders. The second part of the
session will focus on external stakeholders.
The following criteria will be used to determine if an individual will be included as a stakeholder:
Will the person or their organization be directly or indirectly affected by this project?
Does the person or their organization hold a position from which they can influence the project?
Does the person have an impact on the project’s resources (material, personnel, funding)?
Does the person or their organization have any special skills or capabilities the project will require?
Does the person potentially benefit from the project or are they in a position to resist this change?
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 33
Any individual who meets one or more of the above criteria will be identified as a stakeholder.
Stakeholders from the same organization will be grouped to simplify communication and stakeholder
management. As stakeholders are identified the stakeholders’ information will be recorded in the
stakeholder register, DD Project Stakeholder Register - 11.16.2020.docx.
As a follow on to identifying stakeholders, the project team will identify key stakeholders who have the
most influence on the project or who may be impacted the most by it. These key stakeholders are those
who also require the most communication and management which will be determined as stakeholders
are analyzed. Once identified, the Project Manager will develop a plan to obtain their feedback on the
level of participation they desire, frequency and type of communication, and any concerns or conflicting
interests they have.
Based on the feedback gathered by the project manager, the determination may be made to involve key
stakeholders on steering committees, focus groups, gate reviews, or other project meetings or
milestones. Thorough communication with key stakeholders is necessary to ensure all concerns are
identified and addressed and that resources for the project remain available.
6.3 Stakeholder Analysis Once all project stakeholders have been identified, the project team will categorize and analyze each
stakeholder. The purpose of this analysis is to determine the stakeholders’ engagement level, plan the
management approach for each stakeholder, and to determine the appropriate levels of communication
and participation each stakeholder will have on the project.
The project team will categorize stakeholders based on their organization or department. Once all
stakeholders have been categorized, the project team will utilize a Stakeholder Analysis Register to
document the current stakeholder engagement level.
6.3.1 Stakeholder Engagement Assessment Matrix The project team will use information from the Stakeholder Register to document “current” stakeholder
engagement level with a “C” and “desired” stakeholder engagement with a “D.” The following
stakeholder participation descriptions will be used:
Unaware. Unaware of the project and its potential impacts.
Resistant. Aware of the project and potential impacts and resistant to the change.
Neutral. Aware of the project yet neither supportive nor resistant.
Supportive. Aware of the project and potential impacts and supportive of change.
Leading. Aware of the project and potential impacts and actively engaged in ensuring project is
successful.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 34
Stakeholder Unaware Resistant Neutral Supportive Leading
Nolan Moser (Sponsor) C
Michael Dougherty
(PM) C C
Qing Liu (Assistant PM) C C
Diane Davis (SME) C
C = Current level of engagement D = Desired level of engagement Note: This table is not inclusive and complete table is a stand-alone document.
6.4 Stakeholder Management Strategies
To effectively manage stakeholder engagement, the project will communicate project related
information to key stakeholders in a proactive and timely manner. In line with the matrix above, the
project team will also be actively listening and soliciting input and feedback to make sure
communications are being received and understood, and also to capture important information to help
make adjustments and to respond to problem areas.
Other project artifacts will factor into Stakeholder Management as well, including Business Process
Changes and the Change Control process, both of which consider the impact on stakeholders. The
project issue log will be used to collect, document, and address concerns raised by stakeholders and
stakeholder management risks that have materialized into issues that must be managed.
The Stakeholder Management Plan will be reviewed and assessed on a regular basis to determine:
If the project team is effectively engaging Stakeholders.
If the Stakeholder levels of engagement has changed.
If additional stakeholders have been identified.
Whether more needs to be done to obtain the needed level of Stakeholder engagement or
support.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 35
7 Resource Management Plan 7.1 Roles and Responsibilities
Name Role Responsibility
Nolan Moser Project
Sponsor
Provide overall guidance and direction to the project team.
Provide final approval on project milestones and deliverables.
Direct the acquisition of resources or funding for resources.
Qing Liu IT Sponsor Provide overall guidance and direction for technical staffing.
Provide final approval for commitment of technical resources.
Bryan Conway Diane Davis Lori Koho John Crider
Jonathan Felling
Steering
Committee
Ensure participation, collaboration, and commitment from all impacted organizational units.
Michael Dougherty Project
Manager
Either develop the plan or lead the team in the development of the HR and Staff Management Plan depending on the complexity of these plans.
Escalate staffing-related issues to the Project Sponsor or the steering committee.
Present the final staffing plan to the Project Sponsor for approval.
Attend oversight review and approval sessions and supports the sponsor in addressing oversight questions.
Stacy Traxler Human
Resources
(HR) Lead
Assist the Project Manager in identifying HR- related policies, constraints, and processes for hiring required staff.
Support the Project Manager in developing job descriptions and navigating the State hiring process.
Diane Davis Business
Transition
Lead
Assist the Project Manager in identifying training and organization change management resources and associated costs.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 36
Name Role Responsibility
Diane Davis JP Batmale John Crider Lori Koho
Project Team Provide input on the staff estimating process.
Provide input on the staff skill requirements.
Provide requirements for staff availability and agreements.
Diane Davis Lori Koho
Business
Owner(s)
Provide input on the staff estimating process.
Provide input on the staff skills requirements.
Provide requirements for staff availability and agreements.
7.2 Project Organization Chart
The project organizational chart below provides a graphical representation of the project’s
hierarchical reporting relationships. See the above for the chart representing governance of the
project.
Commission Chair
Chief Administrative
Law Judge
Project Sponsor
Chief Operating Officer
Project Manager
Chief Information Officer
Assistant Project Manager
Utility Program Director
Executive Director
Project Team
Change Control
Board
Steering
Committee
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 37
7.3 Project Staffing Estimates
Staffing estimates were determined from an analysis of the WBS and schedule, also taking into
consideration the roles and skill sets needed to complete tasks.
Role/Responsibility Number of Staff Required
Timeframe Needed
% of Time Needed
Project Manager 1 Project Duration 50%
Assistant Project Manager 1 Project Duration 50%
Business Analyst 1 Project Duration 25%
Policy SME 4 Project Duration 25%
7.4 Staff Acquisition Strategy Project staff will consist entirely of internal resources. The project manager, with support from the
project sponsor, will negotiate with department managers to identify and assign resources . All
resources must be approved by appropriate manager before they begin any project work . The
project team will be working on-site and remotely due toCOVID-19 restrictions.
Staff will be requested using a staff resource request form that includes:
Objective of the activity
Knowledge, skills and abilities
Duties
Number of staff needed
Specific named staff as appropriate
Number of hours per week required
Duration
Start date
7.5 Staff/Team Development Plan
7.5.1 Team Development The Project Manager should allocate adequate time for team development activities. A high-performing project team can be formed by:
Using open and effective communication
Creating team-building opportunities
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 38
Developing trust among team members
Establishing team norms, values, and guiding principles
Establishing recognition for positive contribution
Managing conflicts in a constructive manner
Encouraging collaborative problem-solving and decision-making
The following are the project team’s guiding principles:
Collaboration: Be adaptive and open-minded.
Growth: Learn from our mistakes and forgive others for their mistakes. Take chances even though we might fail.
Respect: Assume good intent and deal with disagreements compassionately, immediately and directly.
Leadership: Lead by example, model best practice, and work closely with team members and partner with authentic, transparent relationships.
Spirted: Create fun and very little weirdness.
7.6 Project Orientation The project manager will provide project orientation related to the following topics:
Background of the project
Current status of the project
Review of the project organization chart
Specific job duties and expectations
Introduction to the project team, (management, staff, and consultants)
Review project policies, standards, and tools
Review approaches to Governance, Communication, and Change Control management
Review the project calendar, including status meetings and team meetings
Overview of the facility, amenities, nearby restaurants, parking, and transportation
7.7 Staff Transition and Replacement Plan The project manager will manage all staff transitions and document in the staffing plan and
schedule. The project manager will also notify all stakeholder and project staff of staffing changes
as needed. Project manager will work with vendor to review resumes for key person replacements.
If there are vacant positions that are not able to be filled it will be documented as a risk or issue.
7.8 Transition at Project Completion Project staff not associated with the transition to operations and maintenance (O&M) will be reassigned
to other projects or positions within their department per normal processes. This will include
communication and the close-out or transition of tasks.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 39
8 Procurement Management Plan 8.1 Roles and Responsibilities
Name Role Responsibility
Nolan Moser Project Sponsor Provide overall business leadership to ensure the procurement requirements are met.
Review and approves procurement documents.
Coordinating the encumbrance of funds for contract.
Bryan Conway Diane Davis Lori Koho John Crider
Jonathan
Felling
Steering
Committee
Provide SME expertise for proposal evaluation.
Review high level purpose of RFPs and contracts.
Michael Dougherty Project
Manager
Ensure the overall Procurement Management effort is being executed in accordance with the Plan and promptly.
Oversee Procurement Management effort and Procurement repository containing Procurement documents.
Kimberly Mainwaring (DAS) Rich Palmer
Contract
Administrator
PUC Contract
Administrator
Manage processes and activities outlined in Procurement Management Plan.
Coordinate with the Procurement Analyst that conducted the procurement to initiate a formal change to the contract.
Recognize, investigate, document and act on emerging disputes or other risks, unique requirements, unusual situations or other issues that arise in managing any contracts.
Ensure the Procurement process is organized, managed, and controlled and that any and all issues are identified and resolved within the assigned timeframe to minimize rework.
Contribute to the development of Procurement documents.
Kimberly Mainwaring (DAS) Rich Palmer
Procurement
Analysts
Assist the Project Manager and Contract Administrator in capturing, verifying, and communicating project procurement requirements.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 40
Name Role Responsibility
Handle procuring a contract by performing the following:
Solicitations.
Contacting prospective contractor.
Developing the solicitation packages, including the Scope of Work (SOW).
Developing the contract including the SOW).
Coordinates final approval of the contracts with the Contract Administrator.
Distributing copies of the signed executed contract to the appropriate parties.
Advising the Project Manager of new or modified state procurement policies and regulations.
Barbara Seaman Agency Budget
Office
Receive and coordinate approvals of invoices and resolve invoice disputes.
Verify the encumbrance funds versus the fund availability and the project cost account codes used.
Jack McDonald Department of
Justice
Review for legal sufficiency.
Michael Dougherty Diane Davis
John Crider
Don Arct
Jonathan
Felling
Michelle Scala
Nolan Moser
Evaluation
Committee
Independently read and score all proposals according to the evaluation criteria set forth in the RFP.
Complete an evaluation scoring sheet for each proposal prior to attending the score Tabulation Meeting.
8.2 Procurement Management Processes
8.2.1 Procurement Scope The following procurement items have been determined to be essential for completion and success
of the project:
Item/Service Justification Category Needed By
Project Manager To manage project Project
Resource
04/16/2019
Solution/tool SaaS Software 12/09/2020
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 41
iQA Utilize InfoTech subscription in the
review of contract to ensure accuracy
and optimizing cost
Independent QA 11/30/2020
8.3 Contract Type All products and services for this project will be solicited under firm fixed-price contracts. The
project team will work with DAS Procurement to define the items, types, quantities, services and
required delivery dates. Once approved by the project Sponsor, EIS, and DSA PS, the request for
proposal (RFP) will solicit bids from vendors to procure the required items, with the required time
frame, and at the best value to the state under the firm-fixed price contract with the selected
vendor. The contract will be awarded for one (1) years of Design, Development and Implementation
(DD&I) and five (5) optional years of maintenance and operations.
8.4 Decision Criteria The evaluation criteria for the selection and award of a contract for this project will be based on the
following decision criteria:
Mandatory Requirements
Vendor financial documentation
General Qualifications & Experience (vendor and proposed staff)
Past performance Technical Qualifications
Quality
Ability of the vendor to provide all items by the required delivery date
Software Demonstration and/or Oral Presentation
System Infrastructure Impact
Cost
Key Persons
These criteria will be measured by the agency evaluation committee, Subject Matter Experts (SME),
and the Project Manager. The final decision will be made based on these criteria as well as available
resources.
8.5 Procurement Document Preparation The project manager along with agency staff will meet with DAS Procurement Services (DAS PS) to
determine the type of procurement model that best meets the need of the project. DAS PS and the
Agency will determine that a RFP will be procurement process that must be followed.
8.6 Vendor Management The Project Manager is responsible for vendor management and will oversee vendor performance
for the project. The Project Manager will measure the ongoing performance of the vendor as it
applies to the requirements and deliverables. To ensure acceptable vendor performance, service
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 42
level agreements (SLAs) will be included in the contract which must be met by the vendors. SLAs for
vendor performance include:
Delivery of item(s) on or before date as agreed upon in the contract
Delivery of item(s) at or below cost as agreed upon in the contract
Acceptable performance/quality of item as agreed upon in the contract
Failure of a vendor to adhere to these SLAs will result in the Agency submitting a formal dispute as
appropriate.
The project team will monitor vendor performance and output daily by communicating approvals,
disapprovals, changes, feedback and whatever else is necessary to deepen the relationship. The
things that will be managed outside of contract deliverables are:
Vendor responsiveness – responsiveness to general questions and follow up
Training quality – quality of training material
Vendor innovation – knowledge and adaptability of its services. Is the vendor
knowledgeable regarding their service and how it relates to agency business?
Key persons – any changes to key persons will be approved by the project manager.
The project team is committed to resolving any issues with open communication, personally
interfacing with vendors, making mutually beneficial decisions, sharing critical information, solving
problems jointly, collaborating with the project team and with others as needed to complete the
project and collaboratively educating each other on aspects of the project and product.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 43
9 Requirements Management Plan 9.1 Roles and Responsibilities
Name Role Responsibility
Nolan Moser Project Sponsor Approve the Requirements Management Plan.
Assure Business Owners and Subject Matter Experts are available for requirements development Review and approve requirements documentation.
Provide overall business leadership to ensure the requirements baseline is maintained.
Bryan Conway Diane Davis Lori Koho John Crider Jonathan Felling
Steering Committee Review requirements documentation and plans.
Michael Dougherty Project Manager Lead a team in the development of the Requirements Management Plan.
Provide regular status on requirement efforts
Ensure the overall requirements management effort is being executed in accordance with the Plan.
Ensure there are sufficient resources to execute this Plan and that requirements management activities are being performed within the assigned timeframe.
Ensure requests for requirement changes have followed the approved Change Management Process, and that approved changes to the baseline have been promptly incorporated into the requirements baseline.
Qing Liu Requirements Lead Along with the Project Manager and Business Analyst, develop the Requirements Management Plan.
Overall responsibility executing processes and activities outlined in the Requirements Management Plan.
Responsible for the overall Requirements Management effort and the requirements
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 44
Name Role Responsibility
repository containing the requirements baseline.
Ensure requirements are organized, managed, and controlled as well as issues are identified and resolved within the assigned timeframe to minimize rework.
Contribute to development of the requirements documentation and the Requirements Traceability Matrix.
Diane Davis JP Batmale John Crider Lori Koho Roger White
Business Owner(s) Review and recommend approval of the requirements documentation and the Requirements Traceability Matrix.
Participate in the requirements status reviews.
Review requirements management reports to ensure the requirements baseline is complete, that all approved changes have been incorporated, and impacts caused by changes are identified within the repository.
Jonathan Felling Diane Davis Lori Koho
Business Subject Matter Expert(s)
Participate in process to identify and document requirements.
Attend the requirements status reviews.
Diane Davis Sarah Rowe Lori Koho
Business Analyst Analyze, document and catalog the business processes for related business unit.
Define the data elements.
Document the relationships between business units, roles, capabilities, data elements, processes, systems, and technology.
Recommend changes in business processes.
Conduct interviews to gather and document user requirements via workshops questionnaires, surveys, site visits, workflow storyboards, use cases, scenarios, and other methods.
Communicate business requirement changes to project manager.
Work with the Enterprise Architecture (EA) team to apply a structured business capabilities architecture approach and methodology for capturing the key views of the business and IT.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 45
Name Role Responsibility
TBD Contractor Project Manager
Ensure the vendor team is complying with the requirements management process and procedures within this Plan and in accordance with requirements in the vendor’s contract.
Perform reviews of the requirements management work performed by the vendor team and verify that work complies with the requirements management process .described in this Plan and requirements in the vendor’s contract.
Identify issues to the Project Manager within the assigned timeframe to minimize the amount of rework necessary for state and vendor teams.
9.2 Requirements Management Approach The requirements management approach for the project specifies the development and change
management processes. The development process includes elicitation, analysis, specification, and
validation. Once validated and baselined, the change management section describes how
requirement updates are managed.
9.2.1 Requirement Types
Requirement Type Definition
Business Requirements
A business requirement is something that the business needs to do. Your business requirements change less than your functional requirements, and are typically more objective. The business requirement would read something like: “We need to contact the customer with xyz information”, not “the system will….” Examples include:
A process they must complete, a piece of data they need to use for that process, an Oregon Administrative Rule that governs that process and data.
Functional Requirements
Functional requirements define a function of a system or its component (what the system should do). Examples include:
Authentication, authorization levels, audit tracking, business rules, calculations, external interfaces, historical data, reporting requirements, technical details, data manipulation and processing.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 46
Requirement Type Definition
Non-functional Requirement
Non-functional requirements specify criteria that can be used to judge the operation of a system (describe how a system should behave and what limits there are on its functionality). Examples include:
Accessibility, availability, backup, data retention, disaster recovery, platform compatibility, reporting, security, supportability, testability, usability.
9.3 Requirements Development
9.3.1 Requirements Elicitation The project team will facilitate various methods to collect requirements which may include:
interviews, focus groups, facilitated workshops, group creativity techniques, questionnaires and
surveys, or product prototypes. These will be conducted among the Human Resource project
stakeholders to ensure all requirements are captured.
The project team will facilitate requirements elicitation with project stakeholder groups to ensure
all requirements are captured. The current state (as-is) business process flows will be captured and
documented in various forms and formats. In the early iterations, it is anticipated that the
documentation created will be primarily graphical in nature, such as flow charts, pictures from
white boards, etc. These types of documents will be captured in the form that they were developed
(e.g., Visio, PowerPoint, photo (jpeg), etc.). However, as the requirements are refined, they will be
documented in a MS Word format to allow for later analysis. Additional meetings will be held to
review processes and procedures, which will then be validated.
9.3.2 Requirements Analysis Once the requirements have been elicited and defined, the project team will analyze and group
requirements into subsets around common context. The project team will identify problems in the
form of requirement gaps in completeness, conflicts or inconsistency, affordability, scope, etc.
These problems will be resolved with the stakeholder group that provided the requirement . Once
the conflict is resolved each requirement set will be reviewed and validated with stakeholders.
Additionally, this analysis will determine where in the WBS the requirements will fall or what work
activities correspond to particular requirements.
The project manager will facilitate stakeholder meetings to establish priorities for all project
requirements. This project will use a three-level scale to prioritize requirements.
Mandatory – Indicates requirement is of the highest importance and critical to the
success of the project.
Highly Desirable – Indicates requirement would make the final product more appealing to
end users and meet a useful but not mission critical request from business.
Desirable – Indicates the requirement will add significant value to the project. However, if
meeting the proposed requirement adds significant cost or duration to the project, it can
be disregarded.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 47
As the project moves forward and additional constraints are identified or there are issues with
resources, it may be necessary for the project team and stakeholders to meet to determine what
requirements must be achieved, which can be re-baselined, or which can be omitted. These
determinations will be made in a collaborative effort based on the priorities of the requirements
and which level they are assigned. As any changes in requirements are made, all project
documentation must be updated, and changes communicated to all project stakeholders.
9.4 Requirements Specification Reviewing and approving requirements will include the following steps:
1. Determine distribution list of Reviewers, Approvers and Project Team
2. Distribute Requirements document to distribution list
3. Solicit feedback and document responses
4. Incorporate specific responses that do not impact other Stakeholders
5. Plan and schedule Requirements Approving Workshop
6. Conduct Requirements Approving Workshop
7. Address all responses received from Step 3 above
Once all the requirements have been reviewed and signed off, they will be “base-lined” and become the
first official version of the project requirements. Any change to the requirements will require a change
request. The baseline requirements will be the approved plan that maps out the development that will
take place leading to delivery of the product.
The following documentation will be included in the baseline documentation:
Use cases – Individual scenarios that describe the user’s requirements
Data dictionary – The definition of all data items and structures so that all Stakeholders
consistently use the same terminology and understand it
Analysis models – Graphical analysis models such as class diagrams, entity-relationship diagrams,
state-transition diagrams, object diagrams, domain model and/or data flow diagrams
Once approved, the baselined document will be the foundation of the requirements management
process and is the agreement between the project team and the business. The documentation will have
rigorous version control to ensure that all Stakeholders are working on the same version of the
document.
9.5 Requirements Validation through Traceability The Requirements Traceability Matrix (RTM) is a tool to ensure that the PUC is not expanding the scope
of the project by adding design elements, code, tests or other work products that are not called out in
the requirements. Thus, it traces the deliverables by establishing a thread for each requirement- from
the project’s initiation to the final implementation. This matrix is considered to be bi-directional. It
tracks the requirement forward by examining the output of the deliverables and backward by looking at
the business requirement that was specified for a particular feature of the product. The RTM is also used
to verify that all requirements are met and to identify changes to the scope when they occur. The RTM
can be used during all phases of a project to:
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 48
Track all requirements and whether or not they are being met by the current process and design.
Assist in the creation of the RFP, Project Plan Tasks, Deliverable Documents, and Test Scripts.
Help ensure that all system requirements have been met during the Verification process.
The requirements traceability matrix will ensure the project team verifies all requirements are
completed in accordance with the project charter. The traceability matrix provides a thread from all
requirements through design, testing, and user acceptance. Any approved changes in project scope
or requirements will result in changes to the traceability matrix. Based on impacts of the approved
changes, the Project Manager will make the necessary changes to the matrix and communicate
those changes to all project stakeholders.
9.6 Requirements Change Management Any proposed changes in project requirements must be carefully considered before approval and
implementation. Requirements may need to be frozen during different phases of the project, but
requirements may change for the following reasons:
Requirement was missed
Defect Identified
Business did not understand actual need
Political priorities
Legislative changes
Such changes are likely to impact project scope, time, and/or cost, perhaps significantly . Any
proposed changes to project requirements will be reviewed by the Change Control Board (CCB). The
role of the CCB is to review and determine the impact of the proposed change on the project, and
seek clarification on proposed change. The project sponsor is responsible for approving any changes
in project scope, time, or cost and is an integral part of the change review and approval process.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 49
10 Communication Management Plan 10.1 Roles and Responsibilities
The following table described the Roles and Responsibilities of those involved in the Communication
Management process.
Name Role Responsibility
Nolan Moser Project Sponsor
Communicates project status with the executives and Stakeholders outside the sponsoring organization.
Provides feedback to the Project Manager relative to communication issues.
Communicates vision and direction to project team members.
Bryan Conway Diane Davis Lori Koho John Crider Jonathan Felling
Steering Committee Review communication plan.
Michael Dougherty Project Manager Lead a team in the development of the
Communication Management Plan.
Provide regular status on communication.
Ensure the overall communication management effort is being executed in accordance with the plan in a timely matter.
Ensure there are sufficient resources to execute the plan.
Kandi Young Communication Lead Develops the Communication Management
Plan.
Assists the Project Manager in ensuring all communications are sent, received and understood based on Stakeholder needs and requirements.
Distributes information using methods that reach Stakeholders most effectively.
Diane Davis JP Batmale John Crider Lori Koho
Project Team Members Participate in defining communication needs and requirements.
Participate in the dissemination of project information.
Communicate progress and issues to the Project Manager.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 50
Name Role Responsibility
Utility Program Administrative Hearings Information Systems
Key Stakeholders Participate in defining communication needs and requirements.
Provide feedback on all communications.
Rich Palmer Contract Manager Communicate contract status to the project
management team.
Communicate status and issues to contractors.
10.2 Communication Management Process
10.2.1 Identify Stakeholder Communication Requirements
Stakeholder Group Communication Items Purpose
Steering Committee/Project Sponsor
Status reports Update management on project progress,
risks, and issues.
Provide project performance information
(cost, schedule, and quality).
Support decision-making.
Provide summary information regarding
proposed project changes.
Enterprise Information Services (EIS)
Monthly project status
reports
Provide EIS with information such as project
health, cost, schedule, scope and risk.
Project Team Project
Announcements
Communicate new information about project
status, activities, and issues.
Agency Leadership Monthly project status
reports
Provide information such as project health,
cost, schedule, scope and risk. This report will
be presented at the first Executive Team
Meeting each month.
Administrative Management Group
Monthly project status
reports
Provide information such as project health,
cost, schedule, scope and risk. This report will
be presented at the first AMG meeting per
month.
PUC Staff Monthly project status
reports
Provide Staff with general project information
that may include information such as project
health, cost, schedule, scope and risk. This
report will be posted on the intranet 9Agency
Information) and emailed to GR-PUC All.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 51
Stakeholder Group Communication Items Purpose
Utilities and Other Stakeholders
Monthly project status
reports
Provide Stakeholders general project
information that may include information
such as project health, cost, schedule, scope
and risk. This will be posted on the Project
Webpage. External entities listed in the
Stakeholder Registry will be sent an email
update on any addition to the Project
Webpage.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 52
10.2.2 Identify Information Collection Sources and Responsibilities
Communication Item
Data Sources (Frequency of
Data Collection)
Distribution Responsibilit
y
Distribution Channel
Target Audience(s)
Frequency
Status reports
Project team individual status reports (weekly from all team members)
Project schedule updates (weekly from Project Manager)
Verbal progress reports (weekly from all team members)
Change control requests (as identified by the Project Manager)
Michael Dougherty
Collaboration Site
Project Status Meetings
Project Intranet Site
All Stake- holders
Project Team
Monthly
Quarterly project updates
Project status reports (weekly from the
Michael Dougherty
Collaboration Site
Project Intranet Site
All Stake- holders
Project Team
Through- out the project
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 53
Communication Item
Data Sources (Frequency of
Data Collection)
Distribution Responsibilit
y
Distribution Channel
Target Audience(s)
Frequency
Project Manager)
Project schedule updates (weekly from the Project Manager)
Project announcements
Project Manager (as needed)
Kandi Young Email
Collaboration Site
Instant Messaging
Project Internet Site
Project Team
All Stake- holders (or select groups)
Through- out the project
10.3 Define Guidelines for Project Communication Meetings Define guidelines for project meetings detailing expected meeting facilitation activities and participant expectations.
A facilitator will be identified prior to each meeting.
The meeting facilitator will distribute the agenda at least 24 hours prior to the meeting.
All inputs and pre-read information will be distributed in advance with the agenda.
The agenda will contain a description of the meeting purpose, topics for discussion, and expected outcomes.
Minutes, including action items, will be delivered to team members within one business day after the meeting.
10.4 Develop Project Meetings Schedule
Communication Target Audience Purpose Frequency
Project Kick-off Meeting
All Stakeholders Communicate the project plan, and confirm project roles and responsibilities
On the project start date
Team Meetings Project team members
Review detailed project schedule, tasks,
Weekly
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 54
Communication Target Audience Purpose Frequency
assignments, issues, risks, and action items
Steering Committee Meetings
Project Sponsor Update the Project Sponsor on the project status, budget, critical issues, and change requests
Monthly or as necessary to address significant project issues and/or decisions
Stakeholder Meeting
Project Sponsor/ project Manager
Update Stakeholders on progress
Monthly
Lessons Learned Meeting
All Stakeholders Capture lessons learned that may benefit future project work and/or other projects
Upon completion of major project activities and during Post Implementation Review
10.5 Identify Communication Tools
Communication Tool Tool Description
Email The project will use the state email system for general project correspondence and to send out formal messages to project Stakeholders.
Project Website The project website will be used to post various types of project information, including:
o Project Status Reports o Project Communication Information o Project Events o Additional information as appropriate
10.6 Define Methods for Storage, Retrieval and Disposal Refer to Oregon Administrative Rules on record retention.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 55
Method Electronic Media Paper Media
Storage and Retrieval
Project information will be stored on the projects shared collaboration site.
Project information will be stored in the project team room in locked file cabinets.
Archive Project information will be exported from the collaboration site, archived in compressed format, transferred to a removable storage device, and stored with the project’s other historical artifacts at the Department’s storage facility.
Project information will be removed from the project team room, boxed and sealed, and stored with the project’s other historical artifacts at the Department’s storage facility.
Disposal All backup media containing project information not required for archival purposes will be collected and either physically destroyed or electronically shredded.
All project information will be collected and physically shredded.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 56
11 Risk Management Plan 11.1 Roles and Responsibilities
Name Role Responsibility
Nolan Moser Project Sponsor Provide support to the Project Manager to ensure state and vendor resources are available to support the execution of this Plan.
Provide necessary support to ensure that state and vendor resources commit to the risk management efforts.
Monitor efforts to address risks and provide leadership to focus resources on resolving open unplanned risk events.
Provide guidance on escalated risk events and assists in their resolution.
Bryan Conway Diane Davis Lori Koho John Crider Jonathan Felling
Steering Committee Review the Risk Register and/or risk reports provided to the Committee in accordance with this Plan.
Understand and evaluate the possible effects and impacts of identified risks.
Ensure the Project Manager has a sound plan for mitigating the impacts of risks that have been escalated to the Steering Committee.
Michael Dougherty Project Manager Track progress of the risk management effort by reviewing the Risk Register and/or risk management reports.
Escalate mitigation approaches for identified high severity risks that are beyond the Project Manager’s span of control and decision authority.
Ensure the entire project team, state and vendor, are following this Plan.
Ensure all other project processes that interact or provide input to the risk management effort are being adhered to.
Ensure there are sufficient resources to execute this Plan and that the risk management activities are being performed promptly.
Assign risks to owners.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 57
Name Role Responsibility
TBD Vendor Project Manager
Perform reviews of the risk management work being performed by the vendor team.
Verify the work complies with the risk management approach described in this Plan and the requirements in the vendor’s contract.
Share responsibility for identifying risks and risk events in a timely manner to mitigate the risk and minimize impact to the Project.
Michael Dougherty Risk Manager Maintain the overall risk management process and Risk Register.
Ensure risks managed by this Plan are organized, managed, communicated and controlled.
Ensure that project related risks are identified and mitigated promptly to minimize impact.
Obtain status from Risk Owners on mitigation progress periodically.
Qing Liu Risk Owner Manage assigned risks, including updating the Risk Register, the mitigation plan, and contingency plan details in the Risk Register.
Ensure (in combination with Risk Manager and the Project Manager) risks are organized, managed, and controlled and risks are identified and mitigated promptly to minimize impact to the project.
Provide status updates to Risk Manager.
11.2 Risk Management Processes The project manager working with the project team and project sponsors will ensure that risks are
actively identified, analyzed, and managed throughout the life of the project . Risks will be identified
as early as possible in the project so as to minimize their impact.
11.2.1 Identify Risks Risk identification was conducted in the initial project risk assessment meeting with the project
team and stakeholders. This included an evaluation of environmental factors, organizational culture
and the project management plan including the project scope. Careful attention was given to the
project deliverables, assumptions, constraints, WBS, cost/effort estimates, resource plan, and other
key project documents.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 58
11.3 Analyze Risks Qualitative Risk Analysis
All risks identified will be assessed to identify the range of possible project outcomes . Qualification will be used to determine which risks are the top risks to pursue and respond to and which risks are less concerning. The probability and impact of occurrence for each identified risk will be assessed by the project manager, with input from the project team using the following approach: Probability
High – Greater than <70%> probability of occurrence
Medium – Between <30%> and <70%> probability of occurrence
Low – Below <30%> probability of occurrence Impact
High – Risk that has the potential to greatly impact project cost, project schedule or performance
Medium – Risk that has the potential to slightly impact project cost, project schedule or performance
Low – Risk that has relatively little impact on cost, schedule or performance
Risks that fall within the RED and YELLOW zones will have risk response planning.
Quantitative Risk Analysis
Analysis of risk events that have been prioritized using the qualitative risk analysis process and their effect on project activities will be estimated, a numerical rating applied to each risk based on this analysis, and then documented in this section of the risk management plan. The results of this analysis will be reviewed monthly to confirm the current state.
11.4 Risk Response Planning Each major risk (those falling in the Red & Yellow zones) will be assigned to a project team member
for monitoring purposes. For each major risk, one of the following strategies will be selected to
address it:
Avoid – eliminate the threat by eliminating the cause
Mitigate – Identify ways to reduce the probability or the impact of the risk
Transfer – Make another party responsible for the risk (buy insurance, outsourcing, etc.)
Accept – Nothing will be done
For each risk that will be mitigated, the project team will identify ways to prevent the risk from
occurring or reduce its impact or probability of occurring. This may include prototyping, adding
tasks to the project schedule, or adding resources.
Im p
ac t
H
M
L
L M H
Probability
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 59
For each major risk that is to be mitigated or that is accepted, a course of action will be outlined for
the event that the risk does materialize to minimize its impact.
11.5 Risk Monitoring and Control Risk Monitoring Activities
Risks will be assigned a Risk Owner who will track, monitor and control and report on the status and
effectiveness of each risk response action weekly to the PM and Project Team. The level of risk on a
project will be tracked, monitored and reported throughout the project lifecycle. All project change
requests will be analyzed for their possible impact to the project risks. The top 10 risks will be
reported as a component of the project status report. Management will be notified of important
changes to risk status as a component to the. Risk activities will be recorded in the Risk Register
located on the shared drive, P:\Agency Projects\BizApps Dockets and Discovery Replacement\D&D
Project Replacement Forms and Logs.
The PM will:
Review, reevaluate, and modify the probability and impact for each risk item every two
weeks
Analyze any new risks that are identified and add these items to the risk register
Monitor and control risks that have been identified
Review and update the top ten risk list weekly
Escalate issues/ problems to management
The Risk Owner will:
Help develop the risk response and risk trigger and carry out the execution of the risk
response, if a risk event occurs
Participate in the review, re-evaluation, and modification of the probability and impact for
each risk item on a weekly basis
Identify and participate in the analysis of any new risks that occur
Escalate issues/problems to PM that:
o Significantly impact the projects triple constraint or trigger another risk event to
occur
o Require action prior to the next weekly review
o Has failed to respond to the planned risk strategy causing the need to execute the
contingency plan
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 60
12 Issue Management Plan 12.1 Roles and Responsibilities
The following table describe the Roles and Responsibilities of those involved in the Issue Management
process.
Name Role Responsibility
Nolan Moser Project Sponsor Provide necessary support to the Project Manager
to ensure state and vendor resources are available
to support execution of this Plan.
Provide necessary support to ensure state and
vendor resources commit to issue management
efforts.
Monitor efforts to address project issues and
provide leadership to focus resources on resolving
open issues.
Bryan Conway Diane Davis Lori Koho John Crider Jonathan Felling
Steering
Committee
Review issue reports provided to the Steering
Committee and understand the effects of all open
issues.
Ensure the Project Manager has a sound plan for
resolving open issues and for resolving issues
escalated to the Steering Committee.
Michael Dougherty Project Manager Track progress of issue management efforts.
Ensure other project processes that interact or
provide input to issue management efforts are
being adhered to.
Ensure the project team executes this Plan and
that issue management activities are being
performed promptly.
AeonNexus Vendor Project
Manager
Perform reviews of issue management work
performed by the vendor team.
Verify work complies with this Plan’s issue
management approach and contract requirements.
Share responsibility for identifying issues promptly
to mitigate and minimize project impact.
Qing Liu Issue Manager Maintain the overall issue management process as
well as Issue Log containing issue details.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 61
Name Role Responsibility
Ensure issues managed by this plan are organized,
managed, communicated and controlled.
Ensure all issues are resolved within the assigned
timeframe to minimize project impact.
TBD Issue Owner Manage, administer and complete assigned issue
management activities.
Share responsibility with the Issue Manager and
Project Manager to ensure issues are identified,
managed, and resolved within the assigned
timeframe to minimize project impact.
12.2 Issue Identification It is the responsibility of each team member and stakeholder to be vigilant in identifying and assessing Issues so decisions can be made promptly to reduce potentially negative impacts to project completion and program objectives. Issues can be created whenever a question, problem, or condition needing to be tracked to resolution is identified.
When a project issue is identified the issue originator will provide the pertinent information about the issue to the project manager. The project manager documents the issue in the issue log assign an issue owner.
12.3 Issue Analysis The issue owner will analyze the issue and develop and issue action plan that describes the activities
that need to be completed to address the issue. Analysis includes the following actives:
Assessing the consequences of a delayed issue resolution on quality, cost, technical success, and
schedule
Assessing the impact of an outstanding issues on the overall project, not just the discrete issue
Identifying potential risks associated with the issue
The initial assessment will include a recommendation on the decision or action that needs to be taken,
the due date by which the decision or action is needed, and impact of the decision or action is not
completed by the due date. The due date should be determined in relation to tasks or milestone dates
in the schedule that are affected by the decision/action requested. As determined by a schedule event,
the unique ID associated to that milestone task should be entered in the “Impact” field where it applies
to the relevant schedule.
The issue owner will collaborate with the issue originator to obtain a mutually satisfactory description of
the issue, priority, resolution plan, and due date and update the issue log.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 62
12.4 Issue Resolution and Escalation The Issue Owner will draft the Issue Resolution Plan by the 10th business day of the Issue entry into the
system. Once the resolution plan is completed, the Issue is brought back to Steering Committee for
approval of the resolution plan. If by the 10th business day, no resolution plan is documented with
assigned target dates, the Issue is reviewed at Steering Committee to determine the delay.
In the event an issue remains unresolved an escalation process is to be used. Project issues unable to be
resolved that will potentially cause project delay will need to be escalated to the next level in the
governance structure. Exhausting all options for resolution at the current level is also a reason to
escalate. Escalated issues will be documented in the issue log indicated as escalated. The issue
escalation levels are shown in the following table:
Level Role
1 Project Manager
2 Steering Committee (brief sponsor on escalation before steering committee meeting)
3 Project Sponsor
12.5 Issue Control, Tracking, and Reporting The Issue Owner is responsible for actively managing and controlling the execution of the Issue
Resolution Plan as well as taking the steps necessary to achieve the Due Date.
The project manager will have a weekly review with issue owners and determine whether specific
direction, decision, or action is required from the Steering Committee to complete Resolution Plan
steps.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 63
13 Change Management Plan 13.1 Roles and Responsibilities
Name Role Responsibility
Nolan Moser Project Sponsor Review and approve the Change Control Management Plan.
Make decisions on change requests (CRs) escalated by the Change Control Board (CCB).
Qing Liu
Diane Davis
Jonathan Felling
Michael Dougherty
Change Control Board (CCB)
Primary decision-making body for CRs.
Meet on a regular basis to address outstanding CRs and escalates to Project Sponsor or Steering Committees, as necessary.
Take action on CRs decisions by Project Sponsor or the Steering Committee.
Michael Dougherty
Project Manager Create the Change Management Plan.
Sponsor of approved changes.
Oversee implementation of approved changes.
Approves CR for analysis.
Assign a Change Request Owner.
Review the scope, budget and schedule impacts.
Assign project resources for CR analysis and, if approved, implementation.
Review the CR implementation after it is deployed
Communicate CR status/decision back to Stakeholders.
Vote as a member of the CCB. (May or may not be the CCB chairperson, depending on project size and complexity).
Initiate the escalation process to the Steering Committee, as needed.
TBD Change Request Owner
Identify possible solutions and their impact to the project and its Stakeholders.
Work with the project team to analyze, evaluate, and, if approved, implement CRs.
Prepare supporting documentation for the CR.
Verify CRs are implemented correctly.
Qing Liu Change Request Coordinator (CRC) or Project Coordinator
Serve as single point of contact for CRs.
Receive CRs and record them in the tracking tool
Perform initial CR risk assessment and follows up with the Risk Manager.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 64
Name Role Responsibility
Review CR’s impact to the project’s scope, schedule and cost.
Schedule and transcribe the CCB meetings.
Maintain the CR tracking tool.
Monitors CR progress and report status of CRs monthly.
Produce metrics on CRs.
Maintain project CR documentation.
13.2 Change Management Process Description The Change Management Plan describes how changes will be managed, what defines a change, the purpose and role of the change control board, and the overall change management process. All stakeholders will be expected to submit or request changes to the project in accordance with this Change Management Plan and all requests and submissions will follow the process detailed below.
The following changes may be requested and considered for the project:
Scheduling Changes — changes which will impact the approved project schedule. These changes may require fast tracking, crashing, or re-baselining the schedule depending on the significance of the impact.
Budget Changes — changes which will impact the approved project budget. These changes may require requesting additional funding, releasing funding which would no longer be required, or adding to project or management reserves. Such changes may require changes to the cost baseline.
Scope Changes — changes which are necessary and impact the project’s scope which may be the result of unforeseen requirements which were not initially planned. These changes may also impact budget and schedule. These changes may require revision to WBS, project scope statement, and other project documentation as necessary.
The project manager will ensure that any approved changes are communicated to the project stakeholders. Additionally, as changes are approved, the project manager will ensure that the changes are captured in the project documentation where necessary. These document updates will be communicated to the project team and stakeholders.
13.3 Change Request Identification Any project team member or stakeholder can submit a change request to the project manager using the change request form.
The requestor completes the change request form and submits it to the project manager for review.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 65
The project manager records the request in the change log and assigns a change request number.
The Project Manager reviews the change request form to confirm understanding and determines if:
o Further analysis is needed o Change request should be rejected o Change request should be deferred for further investigation at a later time
13.4 Analysis If the request is approved for analysis, the Project Manager assigns a Change Request Owner. The
Change Request Owner is responsible for completing the investigation analysis and updating the Change
Request Log.
The Change Request Owner will develop a written response that will include a statement as to whether
the change has any associated cost or schedule impact, and will include all project team entities so they
are included in the analysis and sizing effort. The objective of the analysis is to make sure that the
change is clearly understood to identify the total impact of the change, including rough order of
magnitude costs, resources, schedule, performance, and risk impacts.
If the change request includes modification to the system, the analysis will specify which release the
change could be scheduled into along with any other project impacts. If approval of a change request
results in a change to the contract Maximum Payment Amount, that will be included in the investigation
analysis results.
The Change Request Owner will present the analysis results at a subsequent Weekly Project Meeting.
13.5 Approval The CCB or Project Sponsor may decide to defer the change request, reject the change request, or
approve the change request for implementation. Decision criteria that will be considered includes:
impact on cost, schedule, operational benefits, system quality, performance, end-user satisfaction with
the system, and policies.
The Change Log is updated by the Change Request Coordinator (CRC) or Project Coordinator with the
decision, and uploaded to the shared drive, P:\Agency Projects\BizApps Dockets and Discovery
Replacement\D&D Project Replacement Forms and Logs.
Change requests that alter the contract require an amendment cannot be implemented until the
amendment process is completed. The Contract Change Management process is further discussed in the
Procurement Management Plan.
13.6 Implement After the change request is approved for implementation the Project Manager will instruct the project team and vendor to implement the change. Each component of the change will be addressed and all
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 66
project baselines will be brought up to date with the change. Once all components of the change are implemented, the Change Request will be closed within the Log.
13.7 Tracking & Reporting
Title Frequency Content Usage
Intake/Review/Approval Change Control Board Meeting (CCB)
Review analysis and determine if change should be deferred, rejected, approved, or escalated.
Determine next steps on change requests
Opened, Pending, and Approved CRs
Weekly Team Meeting
Summary of the CRs that have been opened, still pending and approved since the last reporting.
Keeps the project team and Stakeholders informed about the changes being made
CR Implementation Status
As Completed
Lists all CRs approved for implementation, activities to implement, estimated completion date, and current status.
Used by management, the CRC, and CR Owners to track CR implementation
Metrics Report Monthly Identifies the total number of CRs opened, approved and pending. Include aging statistics that show how long it takes to approve a CR, the duration at each phase of the process, the number of CRs referred to CCB and Steering Committee, and the number of rejected CRs.
Include as part of quality reporting
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 67
14 Quality Management Plan Quality Reviews include the processes required for reviewing key product documents and deliverables, how quality will be assessed, timing of reviews, what resources are needed, and designing review procedures.
The PUC requires the vendor to deliver a functional product that meets all functional requirements listed in the RFP. All deliverables are reviewed against the functional requirement by the PUC core project team. All deliverables will be reviewed by the PUC core project team within two weeks of delivery. Any deliverable not meeting the functional requirement will be remedied by the vendor within two weeks of the finding.
User Acceptance Testing (UAT) will start when the vendor delivers a working solution. The UAT will be performed by the PUC core project team and stakeholders within four weeks of delivery. Any finding from the UAT will need to be remedied by the vendor within four weeks of the finding.
14.1 Roles and Responsibilities
Name Role Responsibility
Nolan Moser Project Sponsor Set the tone and expectations for project and product quality.
Provide final approval of the Quality Management Plan.
Oversee Quality Management activities.
Bryan Conway Diane Davis Lori Koho John Crider Jonathan Felling
Steering Committee Review quality management plan.
Michael Dougherty Project Manager
Develop and maintain project management plans.
Oversee overall project quality and deliverables.
Ensure quality management activities are being conducted per the plan.
Develop and track project metrics.
Oversee contractor activities.
Promote quality culture.
Diane Davis JP Batmale John Crider Lori Koho
Project team Participate in quality definition activities.
Review major quality issues and approve or make recommendation to the Project Sponsor (and/or Steering Committee).
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 68
Name Role Responsibility
Participate in quality review meetings.
Monitor and resolve quality issues that are escalated to them.
Promote the quality culture.
Jonathan Felling Quality Manager
Draft the Quality Management Plan.
Maintain the Quality Management Plan.
Identify project quality standards and metrics.
Manage day-to-day quality management activities.
Provide oversight and audits of project processes including, but not limited to, project office processes, development processes, business processes, and procedures.
Identify and escalate any critical quality issues to the Project Manager, executive committee, steering committee, and the Project Sponsor.
Collect and analyze project metrics.
Establish reporting standards that provide findings from quality measurements on a periodic basis. These findings identify areas where business, technical, and/or management quality objectives are or are not being met, or where trends in quality are moving in or out of control limits.
Establish and maintain a repository for quality measurement and tracking.
Diane Davis JP Batmale John Crider Lori Koho
Project Team Members
Ensure adherence to processes standards.
Ensure deliverables meet quality standards.
Flag quality issues to the Quality Manager.
Participate in team-level quality reviews.
14.2 Approach
Define Quality – Quality definition is specific to a project process or project product. It sets the standard for acceptability
Measure Quality – Quality Measurement is the combination of processes and tools that compare project processes and project products to their quality definitions
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 69
Improve Quality - Quality Improvement is the set of steps a project takes to increase the quality of processes employed during the project and products resulting from the project
The scope of this quality management plan includes both Process Quality and Product Quality.
Process Quality focuses on the processes used to create the project deliverables. In this project, Process
Quality also includes the project management plans. Process Quality ensures the project’s policies and
procedures are being adhered to by project participants. For each process, there is a plan. After the plan
has been approved and implemented, the corresponding process is reviewed on a predetermined
frequency, depending on its complexity and criticality, to ensure that the plan and process are being
consistently followed. If the process is not being followed, a quality improvement corrective action plan
is developed and implemented to realign the process with its quality definition.
Product Quality focuses on the project deliverables. Product Quality ensures the deliverables are of
acceptable quality, meet their stated deliverable acceptance criteria and are complete and correct. Each
work product is reviewed against the standard governing its production as well as against any applicable
project practices. If the product does not meet its stated acceptance criteria, a quality improvement
corrective action plan is developed and implemented to realign the product with its quality definition.
14.3 Process Quality Process quality ensures that project participants follow applicable standards, processes, policies, procedures, and checks as they create project deliverables. During this process, audits are conducted against stated quality requirements. Audit results are presented to the Project Sponsor, the Steering Committee, and any other existing steering committees. Deficiencies in quality are flagged, and corrective actions are put in place. This ensures that the processes employed to produce project deliverables are sound and will improve chances of project success. For example, projects may have Independent Quality Assurance to perform the necessary quality processes mentioned earlier.
14.4 Process Definition The following table shows the project management process-related items that will be measured for
quality throughout the project, the criteria by which they will be measured, and the metrics that will be
used.
Phase Process Metrics
Initiating Project Charter development
The Project Charter scope and contents are compliant with the agencies standards.
The Project Charter is formally signed off by project sponsor.
Planning Project planning PMP Meets applicable standards and approved by appropriate Stakeholder(s).
Executing Change Control management
Number of pending change requests.
Time to complete change request analysis.
Time to finalize decision on a change request.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 70
Phase Process Metrics
Document Management
Define periodic reviews of project documentation.
14.5 Process Measurement
Documentation reviews – Review of the project’s management plans and other project documentation to determine if documentation and PMBOK standards are being followed.
Project process reviews – Review of PMP processes to determine if they are being followed or if there is a need for improvement.
Post-Implementation Review – Review of project efforts and outcomes to capture lessons learned from the project. The information captured can be used by other projects to learn from the successes and avoid any pitfalls the project may have experienced. This review is held at the conclusion of the project.
The project will conduct the following reviews to assess process quality and identify defects.
Review Type Review Goal Deliverables/Artifacts Review Team Timing
Documentation Review
Review of the project’s management plans and other project documentation to determine if the project’s documentation standards are being followed
Project Management Plan
Risk/Issue Log
Stakeholder List
Project Manager
Quality Manager
When a risk related to one or more of the processes has been identified
As needed
14.6 Process Improvement As a means of responding to defect reports, project managers will process approved improvements
through the project’s formal Change Control process. See the project’s Change Management Plan for
additional details.
14.7 Product Quality Product quality assessments ensure that deliverables meet quality standards as defined in the Quality
Management Plan. The assessments also ensure that deliverables are complete and correct. Quality
standards include such items as documentation standards, design and coding standards, testing
standards, and test coverage requirements.
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 71
14.8 Product Definition The following table shows the product and product-related items that will be measured for quality
throughout the project, the criteria by which they will be measured, and the metrics that will be used.
Product/Deliverable Criteria Metrics
Requirements Specification
Lists all business, functional, and non- functional requirements. Lists all business rules for functional requirements. Requirements are supported by use cases.
Requirements specification adheres to IEEE standards (cite the standard). Reviews have been conducted and the specification is deemed to be complete.
Detailed Design Specification (DDS)
The DDS is detailed to the module level. Follows architecture standards
Design specification adheres to Departmental standards. Reviews have been conducted and the DDS is deemed to be complete. The Requirements Matrix mapping from requirements to design components is complete and addresses all requirements.
System configuration Unit, integration, system, and acceptance testing.
Critical test cases passed, achieving complete functional coverage, fixed all high-priority or critical defects, and regression testing complete.
14.9 Product Measurement The following is a list of product quality reviews:
System Requirements Specifications Review — Checks the adequacy of the requirements stated in the System Requirements Specifications (SRS). This review may not be necessary if the system requirements do not change significantly.
Architecture Design Review — Evaluates the technical adequacy of the preliminary design (also known as top—level design) for the project’s components, sub—components, software, and services depicted in the contractor’s preliminary design description.
Detailed Design Review — Determines the acceptability of the detailed designs, as depicted in the contractor’s Detailed Design Document, for satisfying the requirements specified in the SRS.
Functional Audit – Verifies all requirements specified in the SRS document have been met. Functional Audits also include successful testing of the requirements.
Physical Audit — Verifies internal consistency of the software and its documentation and its readiness for release.
In-Process Audits — The consistency of the design including code versus design documentation, interface specifications (hardware and software), design implementations versus functional
OREGON PUBLIC UTILITY COMMISSION
DOCKETS AND DISCOVERY SYSTEM
PUC Dockets and eDiscovery Project Management Plan 0.3 | Page 72
requirements, and functional requirements versus test descriptions. The project will employ in—process audits on an as—needed basis.
Configuration Management Plan Review – Evaluates the adequacy and completeness of the configuration management methods defined in the both the project’s and the contractor’s Configuration Management Plan.
The project will conduct the following reviews to assess product quality and identify defects.
Review Type Review Goal Deliverables/
Artifact Review Team Timing
System Requirements Specification Review
Checks the adequacy of the requirements stated in the System Requirements Specifications (SRS).
System Requirements Specification
Project Manager
Technical Lead
Testing Manager
Quality Manager
Upon initial submittal of the SRS
Upon a change in the SRS baseline
When a risk related to the SRS has been identified
As needed
Architecture Design Review
Evaluate the technical adequacy of the preliminary design for the project’s components, sub- components, software and services depicted in the preliminary design description.
SRS
High-Level Design
Change Requests
Quality Management Plan
Project Manager
Project Architect
Testing Manager
Quality Manager
Upon initial submittal of the preliminary design
Upon a change in the preliminary design baseline
When a risk related to the design has been identified
As needed
14.10 Product Improvement As a means of responding to defect reports, project managers will process approved improvements
through the project’s formal Change Control process. See the project’s Change Management Plan for
additional details.
