SHARE Financials Upgrade Project
PROJECT MANAGEMENT PLAN
(PMP)
Executive Sponsor – Darryl Ackly
Business Owner –David Holmes
Project Manager – Steven Rupp
Project Management Plan for SHARE Financials Upgrade Project
Revision History
Preparing the Project Management plan
About This Document
Project Oversight Process Memorandum – DoIT, July 2007
1.0 Project Overview
1.1Executive Summary- rationale for the Project
1.2 funding and sources
1.3 constraints
1.4 dependencies
1.5 ASSUMPTIONS
1.6 Initial Project Risks Identified
2.0 Project Authority and Organizational Structure
2.1 Stakeholders
2.2 Project Governance Structure
2.2.1 Project Governance - Overview
2.2.1 Project Governance – Participants
2.2.2 Project Governance
2.2.3 the organizational structure – Org Chart
2.2.4 Project Decision/Issue Escalation Process
3.0 Scope
3.1 Project Objectives
3.1.1 Business Objectives
3.1.2 Technical Objectives
3.2 Application Products in scope
3.3 Project exclusions
4.0 Project Deliverables and methodology
4.1 Project Management Life Cycle
4.1.1 Project Management Deliverables
4.1.2 Deliverable Approval Authority Designations
4.2 PRODUCT LIFE CYCLE
4.2.1 Product Life Cycle Deliverables
4.2.2 Technical Strategy
4.2.3 Deliverable Approval Authority Designations
4.2.4 Deliverable Acceptance Procedure
5.0 Project Work
5.1 Work Breakdown Structure (WBS)
5.2 Schedule allocation -Project Timeline
5.4 Project Team
5.4.1 Project Team Roles and Responsibilities
5.6 PROJECT LOGISTICS
5.6.1 Project Facilities
6.0 Project Management and Controls
6.1 Risk and issue Management
6.1.1 Risk Management
6.1.2 Project Risk Identification
6.1.3 Project Risk Analysis
6.1.4 Project Risk Response Strategies
6.1.5 Project Risk Roles & Responsibilities
6.1.6 Project Risk Tracking Approach
6.1.7 ISSUE MANAGEMENT
6.3 Scope Management Plan
6.3.1 Change Control
6.4 Project Budget Management
6.4.1 Budget Tracking
6.5 Independent Verification &Validation - Quality Reviews
6.5.1 Objectives
6.5.2 Project Quality Review Process
6.5.3 Agency/Customer Satisfaction
6.5.2 READINESS ASSESMENT & SYSTEM ACCEPTANCE PROCESS
6.7 Project Repository
6.7.1 Project Management Documents
6.7.2 Change Management & Technical Management
6.7.3 Phases One Through Five Work Products
6.7.4 File Naming Convention
7. 0 Change Management plan
7.1 Change Management Plan
7.1.1 Leadership
7.1.2 Communications
7.1.3 Learning Strategies
7.1.4 Terms
7.1.5 Change Management Strategy
7.1.6 Stakeholder Expectations
7.1.7 Role and Responsibility Changes
7.4.8 Change Management in the Project Lifecycle
7.1.9 Change Management Team – Roles & Responsibilities
7.2 Communication Plan
7.2.1 Communication Purpose & Objectives
7.2.2 Communication Approach
7.2.3 Communication Success Factors
6.5.1 Communication Roles
7.2.4 Communication Process
7.2.5 Target Audiences
7.2.6 Vehicles for Communication
7.2.7 Topics for Communication
7.2.8 Monitoring Communication Execution (Communication Matrix)
7.2.9 Status Meetings
7.2.10 Project Status Reports
7.3 Change Liaison Network
7.3.1 Introduction & Objectives
7.3.2 What is a Change Agent Network
7.3.3 Why Institute a Change Network
7.3.4 Who Participates in a Change Agent Network
7.3.5 How Will the Change Agent Network Work
7.4 Knowledge Transfer Plan
7.4.1 Overview
7.4.2 Project Team Structure
7.4.3 Team Meetings
7.4.4 Documentation Strategy & Guidelines
7.4.5 Change Management and Communication Plans
7.4.6 Delta Analysis
7.4.7 Design Reviews
7.4.8 Testing
7.4.9 Training
8. 0 Testing
8.1 Testing Strategy
8.1.1 Overview
8.1.2 Purpose & Objectives
8.1.3 Types of Testing
8.1.3.1 Unit Testing
8.1.3.2 System & Integration Testing
8.1.3.3 User Acceptance Testing
8.1.4 Participants
8.1.4.1 SHARE Upgrade Team Technical Members
8.1.4.2 SHARE Upgrade Team Functional Members
8.1.4.3 Agency End Users/Functional Testers
8.1.5 Testing Procedures
8.1.6 System Test Team
8.1.6.1 Test Coordinator
8.1.6.2 SHARE Upgrade Team – Functional and End User/Functional Testers
8.1.6.3 SHARE Upgrade Team - Technical
8.1.6 Testing Infrastructure
8.1.7 Test Requirements
8.1.8 Creating Test Data and Writing Test Scripts
8.1.9 Testing Database
8.1.10 Checking Test Results
8.1.11 Special Security Considerations
8.1.12 Special Forms and Tools
8.1.13 Testing Assumptions
9. 0 Reporting & Analysis
10. 0 Project Close
10.1 Administrative Close
10.2 Contract Close
AttachmentS
Revision History
Revision Number / Date / Comment1.0 / July 27th, 2007 / DoIT Project Management Office Revision
2.0
2.1
2.2
Preparing the Project Management plan
The workbook for preparation of the Project Management Plan is built around helping the project manager and the project team to use the Project Management Plan in support of successful projects. Please refer to it while developing this PMP for your project.
About This Document
Project Oversight Process Memorandum – DoIT, July 2007
“Project management plan” is a formal document approved by the executive sponsor and the Department and developed in the plan phase used to manage project execution, control, and project close.
The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and documents approved scope, cost and schedule baselines.
A project plan includes at least other plans for issue escalation, change control, communications, deliverable review and acceptance, staff acquisition, and risk management.
“Project manager” means a qualified person from the lead agency responsible for all aspects of the project over the entire project management lifecycle (initiate, plan, execute, control, close). The project manager must be familiar with project scope and objectives, as well as effectively coordinate the activities of the team. In addition, the project manager is responsible for developing the project plan and project schedule with the project team to ensure timely completion of the project. The project manager interfaces with all areas affected by the project including end users, distributors, and vendors. The project manager ensures adherence to the best practices and standards of the Department.
Project product” means the final project deliverables as defined in the project plan meeting all agreed and approved acceptance criteria.
“Product development life cycle” is a series of sequential, non-overlapping phases comprised of iterative disciplines such as requirements, analysis and design, implementation, test and deployment implemented to build a product or develop a service.
Revision: 1.0DoIT-PMO-TEM-0201 of vi
Project Management Plan for SHARE Financials Upgrade Project
1.0 Project Overview
The Project Overview sets the stage for the details of the project and begins the “story” of the project and plan.
1.1Executive Summary- rationale for the Project
In order to ensure the reliability and maintainability of the State’s investment in
PeopleSoft the State needs to upgrade to and maintain the most current release level of the software. Since the software is a Commercial Off-The-Shelf (COTS) product it is important to upgrade to current release and patch levels to facilitate support from the vendor. In addition, significant increases in functionality contained in the new release will allow the state to implement efficiencies, streamline processes, reduce system complexity, improve performance, and increase the effectiveness of the system in the areas of Department of Transportation support for FHWA reporting, web services functionality, general ledger processing, asset management compliance, purchasing, enhanced chartfield reporting and to improve the State’s return on its investment.
1.2 funding and sources
Source / Amount / Associated restrictions / ApproversDoit / $1,000,000 / NA / David Holmes
DOT / $800,000 / NA / Eva campos
1.3 constraints
Constraints are factors that restrict the project by scope, resource, or schedule.
Number / Description1 / The work of the upgrade is limited to the functionality that is currently implemented and live in version 8.8.
2 / The project will have to be “Live” either prior to or after the two month legislative session beginning in January 2014.
3 / The project will require a two week period after UAT to allow for FHWA Billing certification.
4 / Resources – SHARE team is small and may require reliance on contracted resources to perform the upgrade.
5 / Current procedures and processes are such that it is very difficult to obtain consulting resources in a timely manner.
1.4 dependencies
Types include the following and should be associated with each dependency listed.
- Mandatory dependencies are dependencies that are inherent to the work being done.
- D- Discretionary dependencies are dependencies defined by the project management team. This may also encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.
- E-External dependencies are dependencies that involve a relationship between project activities and non-project activities such as purchasing/procurement
Number / Description / Type M,D,E
1 / Dot fhwA Billing & Reporting / M
2 / Oracle planned release date of PeopleSoft v9.2 / M
3 / oracle upgrade lab execution of scripts / m
4 / share university design / e
5 / Portal ready for production. / D
1.5 ASSUMPTIONS
Assumptions are planning factors that, for planning purposes, will be considered true, real, or certain.
Number / Description1 / The business need of the project is clear.
2 / The infrastructure to support the project is in place.
3 / Management will act positively towards the project.
4 / A description of the project has been developed.
5 / The boundaries of the scope have been identified.
6 / Staff will be available when required.
7 / Deliverables will be reviewed and approved in a timeframe to not adversely impact the project.
8 / A realistic budget has been approved for the project.
9 / Competent staff with required expertise will be available.
10 / Purchases and contracts will be executed in time to meet the plan.
11 / Agencies/departments will be responsible for the cleanup of their data
12 / DOT will take responsibility (Functional, Technical & Training) during upgrade activities for their business processes associated with FHWA Billing, Asset Management & Inventory.
13 / The SHARE upgrade team has ownership and responsibility of the “technical upgrade” for all state agencies.
1.6 Initial Project Risks Identified
In this section identify and describe how each risk will be managed. Include the steps that will be taken to maximize activity that will result in minimizing probability and impact of each risk.
FHWA Billing Certification
Description –Dept. of Transportation not receiving the FHWA Billing Certification will prevent project from going live. / Probability - Medium / Impact- HighMitigation Strategy: DOT is contracting with specialist in implementing FHWA Billing. Project schedule will include two weeks for certification between UAT and go-live of the upgrade.
Contingency Plan: SHARE will have to remain on version 8.8 until the certification is received.
Version 8.8 Data Integrity
Description –Existing data in PeopleSoft 8.8 environment may be corrupt and create issues with the upgrade. / Probability Medium / Impact MediumMitigation Strategy
Contingency Plan
PeopleSoft 9.2 Release Date
Description – There is a risk of Oracle not releasing version 9.2 by April, 2013. / Probability - Low / Impact- HighMitigation Strategy: SHARE management is in communication regarding the availability of the new release.
Contingency Plan: If Oracle delays the release of 9.2 the schedule will need to be adjusted to accommodate the new release date.
PeopleSoft Upgrade Scripts
Description – Being one of the first organizations to upgrade to version 9.2 increases the risk of encountering issues with the scripts. / Probability – Medium / Impact - MediumMitigation Strategy: SHARE will utilize the Oracle Upgrade Lab to execute the upgrade scripts.
Contingency Plan: Hold Oracle accountable to successfully execute the upgrade.
Project Scope Creep
Description – There is the potential that users will want to access the new functionality available with the new release. / Probability - High / Impact- HighMitigation Strategy: Scope is limited to the functionality implemented in version 8.8.Any requirement ambiguity or introduction of new requirements will be reviewed by the project governance team.
Contingency Plan: Any new functionality identified for implementation will be logged, prioritized and planned to be implemented in future projects.
Resource Commitment & Allocation
Description – Will the required resources be available to perform the upgrade. / Probability - High / Impact- HighMitigation Strategy: Implemented a strategy of early and thorough project planning.
Contingency Plan: Rely more on contracted services.
Project Budget
Description – Is the project budget adequate for the upgrade. / Probability - Medium / Impact- HighMitigation Strategy: Implemented a strategy of early and thorough planning.
Contingency Plan: Request agencies to contribute funding for the project.
Database Size
Description – The size of the database may impact the time to execute the upgrade scripts. / Probability - Medium / Impact- HighMitigation Strategy: Project is underway to archive data.
Contingency Plan: Expand the window of time to execute the scripts.
Portal Implementation
Description – Portal may not be ready for production when the upgrade is going live. / Probability - Medium / Impact- LowMitigation Strategy: Have begun early implementation of the portal.
Contingency Plan: Go live without the Portal and access PeopleSoft Financials as we currently do with 8.8.
Other SHARE Projects
Description – Other projects running parallel that may potentially impact the Upgrade Project. / Probability - Medium / Impact- MediumMitigation Strategy: Changes to production will be frozen in the August timeframe.
Contingency Plan: De-prioritize other efforts and possibly postpone until after the upgrade is complete.
2.0 Project Authority and Organizational Structure
The Project Organization describes the roles and responsibilities of the project team. It also identifies the other organizational groups that are part of the project and graphically depicts the hierarchical configuration of those groups. It exists to clarify interaction with the project team.
2.1 Stakeholders
List all of the major stakeholders in this project.. Stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results. This list of stakeholders also represents the member of the SHARE Advisory Board which is further explained in the Project Governance section of the PMP.
name / Stake in Project / Organization / TitleDavid Holmes / Primary Agency / DoIT / SHARE Systems Manager
Ricky Bejarano / Primary Agency / DFA
Gene Moser / Primary Agency / SPO
TBD / Primary Agency / STO
Karen Baltzley / Primary Agency / GSD
Eva Campos / Primary Agency / DOT / Acting CIO
TBD / Primary Agency / HSD
TBD / Primary Agency / DOH
Christine Boerner / Observing Agency / LFC
TBD / Observing Agency / AOC
TBD / Observing Agency / AODA
2.2 Project Governance Structure
2.2.1 Project Governance - Overview
ThepurposeoftheGovernancePlanistodescribethespecificrolesandresponsibilitiesoftheprojectparticipants,focusingprimarilyonauthoritylevelsanddecision-makingstructures.TheProjectGovernanceobjectivesareto:
•ClearlydefineGovernancerolesandresponsibilities.
•CommunicateGovernanceprocessesthroughouttheorganization.
•Enabledecisionstobemadebytherightpeopleattherightlevelwiththerightknowledge.
•Provideaframeworkthatfacilitatesatimelyturnaroundofissues.
•DefinedGovernanceproceduresminimizewaittimes,risksandcosts.
2.2.1 Project Governance – Participants
Participants / RoleSHARE Executive Leadership Team / The SHARE Executive LeadershipTeam provides policy guidance for policy issues, monitors progress and ensures project goals are achieved. The Leadership team will provide strategic direction for the project. The team approves and supports the overall upgrade program governance structure.Level 5 decisions in chart 2.2.3.
State CIO/Sponsor / The State CIO/Sponsor has overall authority for the project. The Project Sponsor provides vision and direction for the project, provides policy leadership, assists in removing barriers and supports change management initiatives. The Project Sponsorparticipates and with the Share Systems Manager communicates project decisions to the SHARE Executive Leadership Team.Level 4 decisions in chart 2.2.3.
SHARE Systems Manager / The SHARE Systems Manager will provide guidance to the Project Mangers on policy, functional and technical issues.The SHARE Systems Manager will also build consensus between the Project Managers, Project Team before escalating issues to the State CIO/Sponsor. The SHARE Systems Manager is responsible for approving changes in project scope, costs, schedules and resources, as well as ensuring that stakeholders are satisfied. Level 3 decisions in chart 2.2.3.
SHARE Advisory Board / The Advisory committee will provide guidance to the SHARE Systems Mangers on policy, processes, functional and technical issues. Provide input to Level 3 decisions in the chart 2.2.3.
Project Managers / The Project Manger works closely with Project Sponsor, SHARE Systems Manager and Project Team to complete the project schedule as well as coordinates the overall project delivery and management. Level 2 decisions in the chart 2.2.3.
Project Team / The Project Teams Leads and the Subject Matter Expert's (SME’s) will interact regularly. The Project Team Leads will develop recommendations for business processes and will communicate their decisions to the Project Manager.
General Stakeholders / The State has several other stakeholder groups including the Governor’s Office, Legislature, not-for-profits, current vendors, potential vendors, banks, financial institutions, federal agencies, Department of Information Technology (DoIT), StateAgencies and employees as well as the public. These stakeholders are expected to have been kept abreast of the project appropriate. How and when communications will be sent will be part of the Communication Plan. Level 1 decisions in the chart 2.2.3.
2.2.2 Project Governance
TheProjectGovernanceModelisdisplayedbelow.Itismadeupoffivepotentiallevelsdependingonthenatureoftheimpactoftheissue/decision/changeinquestion,andprovidesfortieredresolutionwhennecessary.
TheProject memberswillmakeeveryefforttoresolveissuesasswiftlyaspossible,andenvisionsthatmostissueswillrequireanaverageoffive(5)daystoresolve.In casesinvolvingparticularlycomplexissues,itshouldbeexpectedatleasttwo(2)roundsoffollow-upquestionsresultingfromaninitialrecommendationwillbenecessary.
Adecisiondoesnotneedtopasssequentiallythroughtheentiregovernancestructureinordertogettothefinaldecision-maker.Thefivelevelsinclude:
- Project Team: Govern items that impact Customers (agencies) and business process
- Project Managers: Govern integration and overall success
- SHARE Systems Manager: With the input of the SHARE Advisory Team is and escalation point in governing the integration and overall success of the project
- STATE CIO/Sponsor: Governs items that impact the Project Team
- SHARE Executive : Governs items that impact the Project goals and/or benefits
2.2.3 the organizational structure – Org Chart
2.2.4Project Decision/Issue Escalation Process
Throughoutthelifecycleofanyproject,therewillalmostalwaysbedecisionsorunexpectedproblemsand questionsthatarise.Inanefforttostayonschedule,andmeetprojectobjectives,aDecision/IssueManagementprocessmustbeestablished.