SHARE FINANCIALS UPGRADE PROJECT
P R O JE C T M A N A GEM E N T PLA N
(PMP)
EXECUTIVE SPONSOR – DARRYL ACKLY
BUSINESS OWNER – DAVID HOLMES
PROJECT MANAGER – STEVEN RUPP
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
REVISION HISTORY................................................................................................................................................ IV
PREPARING THE PROJECT MANAGEMENT PLAN .................................................................................................... V
ABOUT THIS DOCUMENT ....................................................................................................................................... V
PROJECT OVERSIGHT PROCESS MEMORANDUM – DOIT, JULY 2007 ....................................................................................... V
1.0 PROJECT OVERVIEW ......................................................................................................................................... 1
1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT ..................................................................................................1
1.2 FUNDING AND SOURCES .............................................................................................................................................1
1.3 CONSTRAINTS ..........................................................................................................................................................1
1.4 DEPENDENCIES .........................................................................................................................................................2
1.5 ASSUMPTIONS.....................................................................................................................................................2
1.6 INITIAL PROJECT RISKS IDENTIFIED..............................................................................................................................3
2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE .............................................................................. 5
2.1 STAKEHOLDERS ........................................................................................................................................................5
2.2 PROJECT GOVERNANCE STRUCTURE .............................................................................................................................6
2.2.1 Project Governance - Overview ...................................................................................................................6
2.2.1 Project Governance – Participants ..............................................................................................................7
2.2.2 Project Governance .....................................................................................................................................8
2.2.3 the organizational structure – Org Chart ....................................................................................................9
2.2.4 Project Decision/Issue Escalation Process .................................................................................................10
3.0 SCOPE ............................................................................................................................................................ 10
3.1 PROJECT OBJECTIVES ..............................................................................................................................................10
3.1.1 Business Objectives ...................................................................................................................................10
3.1.2 Technical Objectives ..................................................................................................................................11
3.2 APPLICATION PRODUCTS IN SCOPE .............................................................................................................................11
3.3 PROJECT EXCLUSIONS ..............................................................................................................................................12
4.0 PROJECT DELIVERABLES AND METHODOLOGY ............................................................................................... 12
4.1 PROJECT MANAGEMENT LIFE CYCLE ..........................................................................................................................12
4.1.1 Project Management Deliverables ............................................................................................................12
4.1.2 Deliverable Approval Authority Designations ...........................................................................................14
4.2 PRODUCT LIFE CYCLE .........................................................................................................................................14
4.2.1 Product Life Cycle Deliverables ..................................................................................................................14
4.2.2 Technical Strategy .....................................................................................................................................17
4.2.3 Deliverable Approval Authority Designations ...........................................................................................17
4.2.4 Deliverable Acceptance Procedure ............................................................................................................18
5.0 PROJECT WORK .............................................................................................................................................. 18
5.1 WORK BREAKDOWN STRUCTURE (WBS) ....................................................................................................................18
5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE ................................................................................................................24
5.4 PROJECT TEAM ......................................................................................................................................................25
5.4.1 Project Team Roles and Responsibilities ...................................................................................................25
5.6 PROJECT LOGISTICS ...........................................................................................................................................29
5.6.1 Project Facilities ........................................................................................................................................29
6.0 PROJECT MANAGEMENT AND CONTROLS ...................................................................................................... 30
6.1 RISK AND ISSUE MANAGEMENT.................................................................................................................................30
6.1.1 Risk Management .....................................................................................................................................30
REVISION: 1.0
DOIT-PMO-TEM-020
i OF vi
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
6.1.2 Project Risk Identification ..........................................................................................................................30
6.1.3 Project Risk Analysis ..................................................................................................................................31
6.1.4 Project Risk Response Strategies ...............................................................................................................32
6.1.5 Project Risk Roles & Responsibilities .........................................................................................................33
6.1.6 Project Risk Tracking Approach .................................................................................................................34
6.1.7 ISSUE MANAGEMENT ................................................................................................................................35
6.3 SCOPE MANAGEMENT PLAN ....................................................................................................................................36
6.3.1 Change Control ..........................................................................................................................................36
6.4 PROJECT BUDGET MANAGEMENT..............................................................................................................................37
6.4.1 Budget Tracking ........................................................................................................................................37
6.5 INDEPENDENT VERIFICATION &VALIDATION - QUALITY REVIEWS .....................................................................................38
6.5.1 Objectives ..................................................................................................................................................38
6.5.2 Project Quality Review Process .................................................................................................................38
6.5.3 Agency/Customer Satisfaction ..................................................................................................................42
6.5.2 READINESS ASSESMENT & SYSTEM ACCEPTANCE PROCESS......................................................................43
6.7 PROJECT REPOSITORY .............................................................................................................................................44
6.7.1 Project Management Documents .............................................................................................................44
6.7.2 Change Management & Technical Management .....................................................................................44
6.7.3 Phases One Through Five Work Products ..................................................................................................45
6.7.4 File Naming Convention ............................................................................................................................45
7. 0 CHANGE MANAGEMENT PLAN ...................................................................................................................... 45
7.1 CHANGE MANAGEMENT PLAN..................................................................................................................................45
7.1.1 Leadership .................................................................................................................................................45
7.1.2 Communications........................................................................................................................................46
7.1.3 Learning Strategies ...................................................................................................................................46
7.1.4 Terms .........................................................................................................................................................47
7.1.5 Change Management Strategy .................................................................................................................47
7.1.6 Stakeholder Expectations ..........................................................................................................................48
7.1.7 Role and Responsibility Changes ...............................................................................................................48
7.4.8 Change Management in the Project Lifecycle ...........................................................................................48
7.1.9 Change Management Team – Roles & Responsibilities ............................................................................51
7.2 COMMUNICATION PLAN ..........................................................................................................................................52
7.2.1 Communication Purpose & Objectives ......................................................................................................52
7.2.2 Communication Approach .........................................................................................................................53
7.2.3 Communication Success Factors ...............................................................................................................53
6.5.1 Communication Roles ................................................................................................................................53
7.2.4 Communication Process ............................................................................................................................54
7.2.5 Target Audiences .......................................................................................................................................55
7.2.6 Vehicles for Communication ......................................................................................................................56
7.2.7 Topics for Communication.........................................................................................................................57
7.2.8 Monitoring Communication Execution (Communication Matrix) .............................................................57
7.2.9 Status Meetings ........................................................................................................................................57
7.2.10 Project Status Reports .............................................................................................................................58
7.3 CHANGE LIAISON NETWORK .....................................................................................................................................58
7.3.1 Introduction & Objectives..........................................................................................................................59
7.3.2 What is a Change Agent Network .............................................................................................................59
7.3.3 Why Institute a Change Network ..............................................................................................................59
7.3.4 Who Participates in a Change Agent Network ..........................................................................................60
7.3.5 How Will the Change Agent Network Work ..............................................................................................60
7.4 KNOWLEDGE TRANSFER PLAN...................................................................................................................................61
7.4.1 Overview ...................................................................................................................................................61
REVISION: 1.0
DOIT-PMO-TEM-020
ii OF vi
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
7.4.2 Project Team Structure ..............................................................................................................................62
7.4.3 Team Meetings..........................................................................................................................................62
7.4.4 Documentation Strategy & Guidelines ......................................................................................................62
7.4.5 Change Management and Communication Plans .....................................................................................62
7.4.6 Delta Analysis ............................................................................................................................................62
7.4.7 Design Reviews ..........................................................................................................................................63
7.4.8 Testing .......................................................................................................................................................63
7.4.9 Training .....................................................................................................................................................63
8. 0 TESTING ........................................................................................................................................................ 64
8.1 TESTING STRATEGY .................................................................................................................................................64
8.1.1 Overview ...................................................................................................................................................64
8.1.2 Purpose & Objectives ................................................................................................................................64
8.1.3 Types of Testing.........................................................................................................................................64
8.1.3.1 Unit Testing ............................................................................................................................................65
8.1.3.2 System & Integration Testing .................................................................................................................65
8.1.3.3 User Acceptance Testing ........................................................................................................................66
8.1.4 Participants ...............................................................................................................................................66
8.1.4.1 SHARE Upgrade Team Technical Members ............................................................................................67
8.1.4.2 SHARE Upgrade Team Functional Members ..........................................................................................67
8.1.4.3 Agency End Users/Functional Testers ....................................................................................................67
8.1.5 Testing Procedures ....................................................................................................................................67
8.1.6 System Test Team......................................................................................................................................68
8.1.6.1 Test Coordinator .....................................................................................................................................68
8.1.6.2 SHARE Upgrade Team – Functional and End User/Functional Testers ..................................................69
8.1.6.3 SHARE Upgrade Team - Technical ..........................................................................................................69
8.1.6 Testing Infrastructure ................................................................................................................................69
8.1.7 Test Requirements .....................................................................................................................................69
8.1.8 Creating Test Data and Writing Test Scripts .............................................................................................70
8.1.9 Testing Database.......................................................................................................................................70
8.1.10 Checking Test Results ..............................................................................................................................70
8.1.11 Special Security Considerations ...............................................................................................................70
8.1.12 Special Forms and Tools ..........................................................................................................................71
8.1.13 Testing Assumptions ...............................................................................................................................71
9. 0 REPORTING & ANALYSIS................................................................................................................................ 72
10. 0 PROJECT CLOSE ........................................................................................................................................... 72
10.1 Administrative Close ...................................................................................................................................72
10.2 Contract Close ............................................................................................................................................73
ATTACHMENTS .................................................................................................................................................... 73
REVISION: 1.0
DOIT-PMO-TEM-020
iii OF vi
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
REVISION HISTORY
REVISION NUMBER
DATE
COMMENT
1.0
July 27th, 2007
DoIT Project Management Office Revision
2.0
2.1
2.2
REVISION: 1.0
DOIT-PMO-TEM-020
iv OF vi
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
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.0
DOIT-PMO-TEM-020
v 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.1 EXECUTIVE 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
APPROVERS
DOIT
$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
DESCRIPTION
1
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.
PAGE | 1
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
NUMBER
DESCRIPTION
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 nonproject 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
DESCRIPTION
1
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.
PAGE | 2
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
NUMBER
DESCRIPTION
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 - HIGH
Mitigation 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
PAGE | 3
Probability MEDIUM
Mitigation Strategy
Impact MEDIUM
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
environment may be
corrupt and create issues
with the upgrade.
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 - HIGH
Mitigation 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 - MEDIUM
Mitigation 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 - HIGH
Mitigation 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.
Project Budget
PAGE | 4
Probability - HIGH
Impact - HIGH
Mitigation Strategy: Implemented a strategy of early and thorough
project planning.
Contingency Plan: Rely more on contracted services.
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
Description – Is the project
budget adequate for the
upgrade.
Probability - MEDIUM
Impact - HIGH
Mitigation 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 - HIGH
Mitigation 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 - LOW
Mitigation 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 - MEDIUM
Mitigation 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
PAGE | 5
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
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
TITLE
David 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
TBD
Primary Agency
HSD
TBD
Primary Agency
DOH
Christine Boerner
Observing Agency
LFC
TBD
Observing Agency
AOC
TBD
Observing Agency
AODA
Acting CIO
2.2 PROJECT GOVERNANCE STRUCTURE
2.2.1 PROJECT GOVERNANCE - OVERVIEW
The purpose of the Governance Plan is to describe the specific roles and
responsibilities of the project participants, focusing primarily on authority levels
and decision-making structures. The Project Governance objectives are to:
• Clearly define Governance roles and responsibilities.
• Communicate Governance processes throughout the organization.
• Enable decisions to be made by the right people at the right level with the right
knowledge.
• Provide a framework that facilitates a timely turnaround of issues.
• Defined Governance procedures minimize wait times, risks and costs.
PAGE | 6
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
2.2.1 PROJECT GOVERNANCE – PARTICIPANTS
PARTICIPANTS
ROLE
SHARE Executive Leadership
Team
The SHARE Executive Leadership Team 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 Sponsor participates 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.
PAGE | 7
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
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), State Agencies 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
The Project Governance Model is displayed below. It is made up of five potential levels
depending on the nature of the impact of the issue/decision/change in question, and provides for
tiered resolution when necessary.
The Project members will make every effort to resolve issues as swiftly as possible, and
envisions that most issues will require an average of five (5) days to resolve. In cases involving
particularly complex issues, it should be expected at least two (2) rounds of follow-up questions
resulting from an initial recommendation will be necessary.
A decision does not need to pass sequentially through the entire governance structure in order to
get to the final decision-maker. The five levels include:

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
PAGE | 8
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
2.2.3 THE ORGANIZATIONAL STRUCTURE – ORG CHART
SHARE Executive
Leadership Team
Contractor
Executive/CFO
Level 5 Decisions
SHARE Executive Leadership
Contractor VP of
Services
State CIO/Sponsor
Level 4 Decisions
Project Sponsorship
SHARE Advisory
Board
Contractor Service
Director
SHARE Systems Manager
Level 3 Decisions
Share Systems Management
DOT FHWA
Project Manager
SHARE Project
Manager
Contractor Project
Manager
Level 2 Decisions
Project Management
DOT & Contractor
FHWA Team
SHARE & Contractor
Functional Leads
SHARE & Contractor
Technical Leads
Level 1 Decisions
Project Team
PAGE | 9
SHARE & Contractor
Change Management
Leads
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
2.2.4 PROJECT DECISION/ISSUE ESCALATION PROCESS
Throughout the life cycle of any project, there will almost always be decisions or unexpected
problems and questions that arise. In an effort to stay on schedule, and meet project objectives, a
Decision /Issue Management process must be established.
Project Decision /Issue Management refers to the processes involved in planning, identifying,
measuring, and assessing the events that are effecting some aspect of completing the project, and
the actions taken to proactively mitigate these.
Issues are not necessarily bad; early and often identification allows the project manager/team to
eliminate potential problems. The Project Manager is responsible for tracking Issues/Decisions
that need to be made throughout the project. Decisions may include, but are not limited to,
business process changes, team management changes, and legislative changes. Any stakeholder
I/end-user may raise a project issue. The Project Manager will regularly review and evaluate the
list of issues and develop a plan for resolution including assigning the appropriate resource(s) for
ownership and resolution.
The project may enlist the assistance of its stakeholders in the resolution of a decision/issue to
ensure the resolution represents the best interests of the project, and its stakeholders. The purpose
of the escalation process is to raise an issue to a higher-level of management for resolution,
particularly when resolution cannot be reached at the project level. The project should always
strive to make decisions and address items at the lowest level possible, however when a
resolution cannot be reached, the item should be escalated to ensure a decision is made before it
causes impacts to the project.
3.0 SCOPE
3.1 PROJECT OBJECTIVES
3.1.1 BUSINESS OBJECTIVES
NUMBER
Bus. Objective 1
Bus. Objective 2
Bus. Objective 3
Bus. Objective 4
PAGE | 10
DESCRIPTION
Upgrade to PeopleSoft v9.2 as quickly as possible allowing
SHARE to operate on the latest release level of the PeopleSoft
software.
Provide all functionality to the agencies and users in the 9.2
environments that is currently implemented and available in the 8.8
environments.
Prepare the SHARE environment and infrastructure for the State
government and agencies to improve processes by taking
advantage of the functionality available in the PeopleSoft
applications.
Reduce and replace existing customizations where the PeopleSoft
application provides the functionality to perform the process.
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
NUMBER
Bus. Objective 5
Bus. Objective 6
DESCRIPTION
Partner with DOT to successfully implement and certify the FHWA
billing functionality on the delivered PeopleSoft application.
Use this project as a model to facilitate increased Agency
participation and partnering on SHARE projects.
3.1.2 TECHNICAL OBJECTIVES
NUMBER
Tech. Objective 1
Tech. Objective 2
Tech. Objective 3
Tech. Objective 4
Tech. Objective 5
Tech. Objective 6
Tech. Objective 7
Tech. Objective 8
Tech. Objective 9
Tech. Objective 10
Tech. Objective 11
DESCRIPTION
Upgrade to the latest release of the Oracle PeopleSoft software.
Actively look to replace 8.8 customizations with the delivered 9.2
functionality whenever possible.
Retrofit the required customizations and reports to PeopleSoft 9.2.
Update and develop the UPK training materials to support this and
subsequent SHARE projects.
Establish a training database and training security profiles.
Provide the user community with the training and knowledge
transfer necessary to perform their jobs.
Develop and implement updated security schema.
Confirm that the upgraded system performs as designed through
Unit, System & Integration testing.
User Acceptance Test to validate that the process, data and
expected results from the scripts work as designed.
Performance tuning of the database to achieve optimum
performance.
Cutover to production with minimum downtime and disruption to
the business and user community.
3.2 APPLICATION PRODUCTS IN SCOPE
The scope of SHARE Financials upgrade includes the following application products:
PRODUCT
PeopleSoft Enterprise Financial Supply Chain
Management (FSCM)
PAGE | 11
MODULES
 Asset Management
 General Ledger
 Payables
 Purchasing
 Cash Management
 Receivables
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
PRODUCT
MODULES
 Grants Management
 Billing
 Contracts
 Projects
 Inventory
3.3 PROJECT EXCLUSIONS

This project will not include the gathering of new requirements.

Implementing new functionality is excluded from the scope of this project. Requests for
new functionality, whether currently available or new in PeopleSoft 9.2, will be logged
and deferred until after Go-Live of this project.

Additional modules beyond what is implemented and currently live in version 8.8 are not
included in the scope of this project.
4.0 PROJECT DELIVERABLES AND METHODOLOGY
4.1 PROJECT MANAGEMENT LIFE CYCLE
4.1.1 PROJECT MANAGEMENT DELIVERABLES
Phase
Deliverables
Description
Phase 1 – Plan & Discover
Project Management Plan
Create, maintain and present a
plan for the overall
implementation. The plan
includes but is not limited to:
PAGE | 12

WBS

Deliverables

Configuration
Management

Testing

Knowledge Transfer
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT

Change Management

Communications

Risk & Issue Management
Phase 1- Plan & Discover
Kickoff Meeting
Summarizes team structure,
roles and responsibilities,
scope, timeline, and
methodology
Phase 1- Plan & Discover
Knowledge Transfer Plan
Defines knowledge transfer
approach.
Phase 1- Plan & Discover
High Level Project Schedule
Details tasks, timeline,
dependencies, and
assignments.
Phase 1 – Plan & Discover
Technical Charter
Environment Strategy – Lists
database environments
required.
Development Standards –
Details standards for
developing custom code.
Migration/Version Control
Strategy – Defines process for
migrating objects.
Patch and Fix Strategy –
Defines guidelines and
approach for applying patches
and fixes.
Batch Processing Strategy –
Summarizes approach and
method for batch processing.
Phase 2 – Analyze & Design
Detailed Project Schedule &
Assumptions
Details tasks, timeline,
dependencies, and
assignments.
Phase 2 – Analyze & Design
User Training Plan
Defines the user training
approach.
Phase 3 – Configure &
Develop
Test Plan
Details testing approach and
procedures, for each test cycle.
PAGE | 13
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
Phase 5 - Deploy
Cutover Plan
Outlines tasks to complete
prior to go live.
Phase 5 - Deploy
Readiness Assessment
Items to assess readiness for
go live.
4.1.2 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS
DELIVERABLE
NUMBER
DELIVERABLE
APPROVERS (WHO
CAN APPROVE)
PRJ-DEL-001
Project Management Plan
David Holmes
PRJ-DEL-002
Kickoff Meeting
David Holmes
PRJ-DEL-003
Knowledge Transfer Plan
David Holmes
PRJ-DEL-004
Change Management Plan
David Holmes
PRJ-DEL-005
Communication Plan
David Holmes
PRJ-DEL-006
High Level Project Schedule
David Holmes
PRJ-DEL-006
Technical Charter
David Holmes
PRJ-DEL-007
Detailed Project Schedule &
Assumptions
David Holmes
PRJ-DEL-008
User Training Plan
David Holmes
PRJ-DEL-009
Test Plan
David Holmes
PRJ-DEL-010
Cutover Plan
David Holmes
PRJ-DEL-011
Readiness Assessment
David Holmes
4.2 PRODUCT LIFE CYCLE
4.2.1 PRODUCT LIFE CYCLE DELIVERABLES
PAGE | 14
DATE
APPROVED
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
Phase
Key Deliverables
Description
Phase 2 – Analyze & Design
System & Configuration
Design (Delta Analysis)
The System & Configuration
Design document will contain
the recommended system
configuration change
recommendations (per
module), customization
disposition (upgrade/retain,
retrofit, re-apply, or drop),
interface inventory and
changes, and report inventory.
Phase 2 – Analyze & Design
Security Plan & Matrix
The Security Plan & Matrix
will outline the recommended
Security configuration
changes to apply to the 9.2
environment. It will contain
the initial security matrix of
roles and access levels
required.
Phase 3 – Configure &
Develop
Configuration Document
A document itemizing the
system configuration of the
PeopleSoft 9.2 environment
will be created. The document
will list the control tables
being used and the functional
configuration such to provide
a basis for understanding how
PeopleSoft has been set up
and screenshots.
Phase 3 – Configure &
Develop
Updated Functional
Specifications
Update the preliminary
functional specifications for
development items.
Phase 3 – Configure &
Develop
Test Plan Matrices, Scenarios
and Scripts
Test Matrices outlining the
script types and functional
testing required will be built
as outlined by the Test Plan.
Phase 3 – Configure &
Develop
Technical Specs
From the Custom inventory, a
tracking spreadsheet will be
created listing the items to be
retrofitted. Technical
PAGE | 15
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
resources will complete the
update of Technical
Specifications for which they
are assigned retrofitting.
Phase 3 – Configure &
Develop
Training Materials
Materials to support the Train
the Trainer and End-User
sessions.
Phase 3 – Configure &
Develop
Code/Unit Test
Technical resources will
complete the coding and unit
test of assigned development
items as assigned.
Phase 4 – Test & Train
Completed System/Integration
Testing
System has been tested and
Integration testing has been
completed and documented.
The System Integration Test
Plan outlines the
characteristics of the particular
test phase and plans the
breadth and depth of the
testing effort.
Phase 4 – Test & Train
Completed Acceptance
Testing
Stakeholders have defined
acceptance criteria and testing
results achieve desired
outcomes. The User
Acceptance Test Plan outlines
the characteristics of the
particular test phase and plans
the breadth and depth of the
testing effort.
Phase 4 – Test & Train
Training Delivery
End users in the use of the
system to perform their
business processes.
Phase 5 – Deployment
Cutover Plan
The Cutover Plan outlines
tasks to be completed prior to
go-live. Typically, it includes
the detailed Go-live Checklist.
The Cutover Plan outlines a
comprehensive list of tasks for
the final cutover to
production, including timing
PAGE | 16
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
and responsibility.
Phase 5 – Deployment
Cutover to Production
Execution of the Cutover Plan
placing the upgraded
environment into production.
Phase 5 – Deployment
Production Support
Provide functional support
services to end users,
technical support services as
needed and project
management support to
resolve issues as needed.
4.2.2 TECHNICAL STRATEGY
A full technical charter will be prepared for this project.
4.2.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS
Complete the following table to identify the deliverables this project is to produce, and to name
the person or persons who have authority to approve each deliverable.
DELIVERABLE
NUMBER
DELIVERABLE
APPROVERS (WHO
CAN APPROVE)
PRD-DEL-001
System & Configuration Design
David Holmes
PRD-DEL-002
Security Plan & Matrix
David Holmes
PRD-DEL-004
Configuration Document
David Holmes
PRD-DEL-005
Updated Functional Specifications
David Holmes
PRD-DEL-006
Test Plan Matrices, Scenarios and
Scripts
David Holmes
PRD-DEL-007
Technical Specs
David Holmes
PRD-DEL-008
Training Materials
David Holmes
PRD-DEL-009
Code/Unit Test
David Holmes
PRD-DEL-010
Completed System/Integration
Testing
David Holmes
PAGE | 17
DATE
APPROVED
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
DELIVERABLE
NUMBER
DELIVERABLE
APPROVERS (WHO
CAN APPROVE)
PRD-DEL-011
Completed Acceptance Testing
David Holmes
PRD-DEL-012
Training Delivery
David Holmes
PRD-DEL-013
Cutover Plan
David Holmes
PRD-DEL-014
Cutover to Production
David Holmes
PRD-DEL-015
Production Support
David Holmes
DATE
APPROVED
4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE
The assigned “Approvers” will either approve or reject deliverables. Deliverables will be
considered approved when authorized signatures are affixed to the Deliverable Approval Form.
If a deliverable is rejected, specific reasons will be stated and the project team will work
expeditiously to revise the deliverable. If after three (3) iterations of the Deliverable having been
submitted for approval, and rejected, it will be escalated via the Decision Resolution Process.
Approvers will have five (5) business days to review and take action on submitted final
deliverables. If Approvers do not approve the deliverable, they must provide in writing the
deficiencies in the deliverable. The team will then have three (3) business days to take corrective
action on the deliverable and resubmit for approval. If the Approvers do not take any action on
submitted deliverables after a period of five (5) working days, project management will escalate
the situation via the Decision Resolution Process.
5.0 PROJECT WORK
5.1 WORK BREAKDOWN STRUCTURE (WBS)
A WBS is a deliverable-oriented grouping of project elements that organizes and defines the total
work scope of the project. Describe the work activities that comprise the work breakdown
structure (WBS) or the work packages within the WBS. Identify the WBS element or other work
package identifier and provide a general description of the tasks or activities, the definition or
objectives, and the milestones and deliverables of each work package.
Use the chart below for highest level presentation, and provide a more detailed WBS as an
attachment to this project plan.
PHASE/TASKS
PHASE 1 – PLAN & DISCOVER
PAGE | 18
DEFINITION/OBJECTIVE
DELIVERABLE/MILESTONE
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
1.01
PHASE/TASKS
DEFINITION/OBJECTIVE
DELIVERABLE/MILESTONE
Project Planning

Project Management Plan







1.02
Technical
Preparation


1.03
Install &
Configure



Develop project plan, upgrade
documentation
Work with SHARE
management to confirm and
evaluate existing strategies
and plans for:
Customization (bolt-ons,
queries, interfaces,
integration, reporting)
Testing
Production Support
Establish and document
project expectations for
management and project team
Review proposed project team
and level of time
commitments
Plan and conduct Kickoff
Meeting
Get a copy of current
production database (UPG), a
copy of current release
DEMO database, and
PS_HOME code line.
Freeze PeopleTools changes
on current production
database from this point
forward; any changes to
production will have to be
manually retrofitted into the
upgraded database.
Build a PeopleSoft new
release demo environment
and applies any patches and
fixes that are required for
installation and/or upgrade
Verify/Certify the install
Create copy of production
(UPG) upgrade environment
Pre-Installation Complete
Certified PeopleSoft Install
PHASE 2 – ANALYZE & DESIGN
2.01
PAGE | 19
Pre-Upgrade
Technical
Setup

Load the PS-delivered project, Pre-Upgrade Technical Setup
which contains the menus and
pages required for preupgrade data entry and
reporting
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
PHASE/TASKS
DEFINITION/OBJECTIVE
DELIVERABLE/MILESTONE
2.02
Pre-Upgrade
Functional
Setup

Pre-Upgrade Functional Setup
2.03
Upgrade
Business
Delta
Analysis

Compare
Process

2.04



2.05
Complete Initial
Pass




2.06
PAGE | 20
Create Test
Environmen
t


Obtain and run any data
cleansing scripts as required
per the functional data audit
reports run during the project
preview.
Review and understand the
business processes that may
be affected by the upgrade.
Review current
customizations.
Run the Upgrade Compare
process between PS_DEMO
and COP1 and generates the
full database compares.
Review the compares and
updates the “Take Action”
flags, which determine the
customizations to be retained,
dropped, or scheduled for
retrofit.
Enter take action flag
decisions into the compare
project(s) and runs the
Upgrade Copy process to
migrate objects from the new
release demo database to
Client copy of production.
Execute the steps to alter the
PeopleSoft application, such
as creating new tables,
altering tables without deletes,
Application Engine data
conversion programs, altering
tables with deletes, and
rebuilding views
Run final audits and table row
counts
Perform any patching
Create steps and objects to
resolve problems encountered
in Initial Pass
Create a TST environment
from the upgraded UPG
Perform Install Verification
Test
Delta Analysis
Compare Reports & Analysis
Initial Upgrade Complete
Test Environment Created
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
PHASE/TASKS
DEFINITION/OBJECTIVE
DELIVERABLE/MILESTONE

Test Environment Validated
PHASE 3 – CONFIGURE & DEVELOP
3.01
Data Validation
and Testing
3.02
Functional

Setup in Test
Environmen
t
3.03
Develop
Technical
Specification
s

3.04
Update Upgrade
Scripts

3.05
Apply Patches
and Fixes

3.06
Create DEV
Environmen
t


3.07
Reapply
Customizati
ons



PAGE | 21
Functional team validates
setup tables and transaction
tables for completeness and
accuracy after the initial
upgrade pass and confirm that
data is successfully upgraded
Completing post-upgrade
functional setup in the Test
Environment corresponding to
exercises in PeopleSoft
Upgrade Guide
Assist development team as
they work on technical
specifications to reapply
existing customizations or
develop new customizations.
Modify the delivered
Application Engine upgrade
programs or writes SQL
scripts to correct the data
based on results of data
validation and testing.
Research, download, and
apply the most current
available set of maintenance
packs and bundles to the TST
database
Create a DEV environment
from the upgraded and
patched TST. Since TST is
patched, the DEV
environment includes the
patches before any retrofitting
begins.
Perform Install Verification
Test.
Reapply customizations.
Incorporate production
changes made since the 1st
copy of production was taken
into the upgraded database.
Develop data conversion
scripts to migrate custom
tables.
Configured Prototype
Technical Specifications
Updated Upgrade Scripts
Patched Environment
Development Environment
Created
Migrated Objects & Data
Files
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
PHASE/TASKS
DEFINITION/OBJECTIVE
DELIVERABLE/MILESTONE
3.08
Update Security
Setup

Security Schema
3.09
Prepare for First 
Test Move to
Production
3.10
Test Move 1


3.11
Data Validation
and Testing

3.12
Readiness
Assessment
Checklist

PHASE 4 – TEST & TRAIN
PAGE | 22
Retrofit and modify security.
Assist in troubleshooting any
security related issues in the
environment
Create a second copy of the
production database (COP2)
that will be used for system
and user testing and for
testing the move to production
process.
Complete a “test move to
production” (MTP), reexecuting the upgrade scripts
on COP2 with the upgraded
PeopleTools from COP1. This
process will be replicated
during the final move to
production. The test MTPs
confirm the process and
scripts are error-free, and also
demonstrate that the MTP can
be accomplished in the
specified cutover timeframe.
Copy the upgraded COP2 to
the TST environment.
Validate setup tables and
transaction tables for
completeness and accuracy
and confirm that data is
successfully upgraded.
Prepare and review a
readiness assessment checklist
– list of criteria that must be
met in order to go live with
new release. This includes
functional, technical,
organizational, and user
readiness.
Prepare for First Test Move to
Production
Test Move 1 Complete
Validated Test Move
Go Live Criteria Defined
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
4.01
PHASE/TASKS
DEFINITION/OBJECTIVE
DELIVERABLE/MILESTONE
System &
Integration
Testing for
TM1

System & Integration Testing

4.02
Test Move 2


4.03
Unit & System
Testing for
TM2


4.04
Go-live
Checklist

4.05
Acceptance
Testing

4.06
Test Move 3

PAGE | 23
Conduct system testing,
integration testing,
troubleshooting, and issue
resolution
Evaluate test results and
adjusting system (programs,
configuration, procedures)
until retested satisfactorily.
Provide a third copy of the
production database (COP3)
that is used for test move 2 to
validate the upgrade scripts
after the application of fixes
and any further Client recustomization work. Test
move 2 provides another
opportunity to tune the
upgrade processes and
provides a more current set of
data of user testing.
Complete test move 2 upgrade
processes and refreshes TST
with the upgraded COP3
Conduct unit testing,
integration testing,
troubleshooting, and issue
resolution
Evaluate test results and assist
functional team in adjusting
system (programs,
configuration, procedures)
until retested satisfactorily.
Create go-live checklist – list
of tasks required to make the
system fully functional after
the upgrade processes have
been run.
Support and clean-up
environment as users perform
acceptance and parallel tests
in TST
Within 3-4 weeks of the
planned go-live date, conduct
a final test move. Testing
should be stabilized and final
database and batch changes
Cutover Plan
User Acceptance Testing
Final Test Move
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
PHASE/TASKS
DEFINITION/OBJECTIVE






DELIVERABLE/MILESTONE
are migrated to the TST db.
Create a new copy of
production (COP4) to use for
the final test move
Deliver an upgraded database
to Client
Conduct final test move to
confirm complete
environment readiness.
Complete test move 3 upgrade
processes and refreshes TST
with the upgraded COP4
Freeze PeopleTools in the
upgrade environment (e.g.
TST) once the final test move
to production begins.
During this freeze period,
track any changes made to the
tools tables so they can be
reapplied after the final move
to production occurs.
PHASE 5 – DEPLOYMENT
5.01
Go / No Go
Decision


5.02
5.03
Move to
Production
Final Testing



5.04
Go Live

5.05
Production
Support

Verify PeopleSoft
environment and a final
verification test is performed.
Conduct a “go/no go” meeting
after the final test move and
just prior to the move to
production
Execute the final move to
production.
Complete post-upgrade setup
and go-live checklist tasks
Conduct final go/no-go
testing
Run in production on
PeopleSoft’s latest version.
Following go-live, provide
assistance to help resolve any
issues.
5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE
PAGE | 24
Go Live Assessment
Cutover to Production
Production Ready
Environment
System Live
Postproduction Support
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
The project timeline is a high-level view of project activities with a focus on project milestones.
The project timeline does not replace the need for a detailed project schedule and it is to
highlight key events such as deliverable due dates and when go/no-go decisions are made.
The table below should provide a high level view of the project time line, or a summary-level
Gantt chart can be used to meet the timeline requirement.
Please provide a more detailed project schedule as an attachment to this plan
Identifier
Task/Activity
Name
Resource
Name
Milestone Effort/
(Y/N)
Duration
Start
Finish
Dependent
Task
5.4 PROJECT TEAM
5.4.1 PROJECT TEAM ROLES AND RESPONSIBILITIES
ROLE
RESPONSIBILITY
NAME
FUNCTIONAL
AREA
Project
Manager
The Project Manager is responsible for
managing the project and all underlying
resources and has responsibility for
project budget, the Project Plan, and
personnel, for resolving issues, and for
achieving overall project success. The
Project Manager is also responsible for
ensuring that the structure of the project
and design of the ERP System reflects an
integrated business process orientation.
TBD
NA
Functional
Analyst 1
Functional Analysts are the primary
business process experts who are
responsible for leading the design and
TBD
GL/KK
PAGE | 25
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
ROLE
RESPONSIBILITY
NAME
FUNCTIONAL
AREA
Functional
Analyst 2
implementation of the System for a
specific functional area. They will also
assist with train-the-trainers planning and
support.
The Functional Analysts are
knowledgeable of the current business
processes and policies and are familiar
with the legacy systems and older
PeopleSoft application. They are
empowered to make decisions to
organize and lead Agency SMEs in
design, testing, and training.
Functional Analyst will have the role of
tester for the System & Integration
testing. Additionally, during the project
on of the analyst will be assigned the role
of Test Coordinator.
TBD
AP/PO
TBD
AR/BI/CM
TBD
PC/GM
Agency SMEs are project members with
expertise in specific business processes
or technical knowledge at State of New
Mexico, who are called on at various
times during the project to review and
redesign business processes, design
prototypes, and test specific
functionality. An additional area of
responsibility will be to coordinate with
the SHARE upgrade team to resolve data
issues during the upgrade process.
Agency SME’s will fill the role of the
End User/Functional tester for User
Acceptance Testing. An optional role of
SMEs is to become end-user trainers.
TBD
All
Functional
Analyst 3
Functional
Analyst 4
Agency
Subject Matter
Experts
(SME’s)
PAGE | 26
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
ROLE
RESPONSIBILITY
NAME
FUNCTIONAL
AREA
Tech Lead
The Technical Lead is responsible for
formulating technical and infrastructure
strategies for the project. They will lead
the development, data conversion,
system administration, database
management, and other technical
activities. The Technical Lead is a key
technical manager with experience
managing technical staff and systems.
TBD
NA
Upgrade Lab
The Upgrade Lab will execute the
upgrade scripts that will process the
initial move. Additionally, the Upgrade
Lab will be available to support the final
move to production.
Oracle
NA
DBA 1
The database administrators (“DBAs”) /
System Administrator (or “Sys Admin”)
will administer the PeopleSoft
environments for the upgrade and
implementation project, as needed.
TBD
NA
Admin/Upgrad
er
Along with Oracle Upgrade Lab these
individuals will perform the role of
Upgrade Specialists (or Upgraders) who
will execute the upgrade scripts that will
help process the test moves and testing
cycles.
TBD
NA
Developer 1
Technical Developers are the individuals
responsible for developing technical
specifications, programming
modifications, and reports and interfaces;
for mapping and converting data; and for
prototyping and integrating ERP System
modules and components.
TBD
NA
TBD
NA
TBD
NA
Developer 2
Developer 3
PAGE | 27
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
ROLE
RESPONSIBILITY
NAME
FUNCTIONAL
AREA
Security/Contr
ols
The Security lead will focus on security
needs (matrix, roles, workflow) and
controls around roles and processes. The
controls will help provide outlines to
help identify any conflicts.
Don Gleason
NA
Change
Management /
Training Lead
Project communications, scheduling,
coordination, feedback collection and
processing are key activities driven by
the Change Management Lead.
Training Lead is responsible for
developing the End User Training Plan,
training schedule, and training materials.
They conduct train-the-trainer training
sessions.
TBD
NA
Trainer 1
The Trainers support the Training Lead
in developing the End User Training
Plan, training schedule, and training
materials. The Trainers should have
excellent verbal and written
communication skills and familiarity
with the key business processes in one or
more targeted functional areas.
TBD
NA
TBD
NA
TBD
NA
TBD
NA
Trainer 2
Trainer 3
Trainer 4
DEPARTMENT OF TRANSPORTATION – THE ROLES DEFINED BELOW ARE PROVIDED TO REPRESENT THE
UNDERSTANDING OF THE AREAS OF RESPONSIBILITY BETWEEN SHARE AND DOT. THE ACTUAL STAFFING
LEVELS REQUIRED TO PERFORM THESE RESPONSIBILITIES WILL BE DETERMINED BY DOT.
ROLE
RESPONSIBILITY
NAME
FUNCTIONAL
AREA
FHWA
Functional
Analyst
Functional Analysts are the primary business
process experts who are responsible for
leading the design and implementation of the
TBD
PC/GM/BI/AR
PAGE | 28
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
ROLE
RESPONSIBILITY
NAME
FUNCTIONAL
AREA
System for a specific functional area. They
will also assist with train-the-trainers
planning and support.
The Functional Analysts are knowledgeable
of the current business processes and policies
and are familiar with the legacy systems and
older PeopleSoft application. They are
empowered to make decisions to organize
and lead SMEs in design, testing, and
training.
TBD
IN/AM
Technical
Developer
Technical Developers are the individuals
responsible for developing technical
specifications, programming
modifications, and reports and interfaces;
for mapping and converting data; and for
prototyping and integrating ERP System
modules and components. It is expected
this role will be of some significance in
the data cleanup activities.
TBD
PC/GM/BI/AR/
Trainer(s)
Will prepare materials and deliver
training for the Funds Distribution and
FHWA Billing processes.
TBD
Functional
Analyst
IN/AM
PC/GM/BI/AR
5.6 PROJECT LOGISTICS
5.6.1 PROJECT FACILITIES
The following are the minimum facility requirements the team needs to successfully deliver this
project. Facilities provided to the team will only be accessible to State employees and authorized
State personnel. To validate the confidentiality of the information collected, the office areas
provided will be fitted with locks, card key entry, and/or electronic security pads for security
purposes.
The project team requires the following facilities and equipment throughout the project:
FACILITY/TOOL/EQUIPMENT DESCRIPTION
Project Team Space
PAGE | 29
Co-located team space for the core project team. Preferably a
working desk with Virtual Machines & access per on-site
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
FACILITY/TOOL/EQUIPMENT DESCRIPTION
resource.
Conference Rooms
At least one dedicated conference room to conduct meetings
Network Access
Minimum of one network line for each enclosed office and
cubicle provided and/or wireless network access.
Telephone Lines w/ Phones
Minimum of one phone line with phone for each enclosed
office / cubicle provided.
Fax Machines
Access to fax machine.
Printers
Access to laser jet printer (or equivalent).
Copy Machines
Access to copy machine.
HVAC
Heating and air conditioning available and working in all work
areas being provided.
Lights and Temperature
Control
Lights and temperature control available and working in all
work areas.
6.0 PROJECT MANAGEMENT AND CONTROLS
6.1 RISK AND ISSUE MANAGEMENT
6.1.1 RISK MANAGEMENT
Project risk management includes managing the processes concerned with identifying, analyzing,
and responding to project risk. It focuses on maximizing the results of positive events and
minimizing the consequences of adverse events. It includes identifying both threats to the
project's objectives and opportunities to improve on those objectives. Its origins are in the
uncertainty that is present in all projects. A risk has a cause, and if it occurs, a consequence.
The process of managing risks begins in the Planning and Discovery phase but continues
throughout the rest of the project.
6.1.2 PROJECT RISK IDENTIFICATION
Risk identification is the process designed to identify risk events that pose a threat to the
successful completion of the project.
The Cause/Effect method is used to identify risk events for this project. To accomplish this, team
members are asked to complete the following sentence:
PAGE | 30
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
"If _(Risk Event)_ happens, then _(Consequence)."
Project risks will be assessed by the Project Management Team and the Development Team
independently following the following process:


Identify Risks
Classify by Category and Sub Category (See Risk Register for
details) Clarify terminology and descriptions

Rank Risks- Individually
o Probability of occurrence (High(3), Medium(2), Low(1))
o Impact (High(3), Medium(2), Low(1))
Consolidate rankings



Prioritize High I High Risks as a Group
Determine Risk Response (Mitigate, Accept, Transfer,
Watch)

Identify owners





Define triggers for all risks
For mitigation:
Brainstorm possible mitigating actions
Identify responsible persons for each action
Set target dates
6.1.3 PROJECT RISK ANALYSIS
When reviewing project risks, either during a project leadership meeting or during a formal risk
assessment, the team should determine the probability and impact of risks.
The probability (likelihood) of a risk occurring can typically be identified by answering the
question: "How likely is it, that (Condition) will impact the project?" Responses should fall
under three possible options:
High: The risk has either already occurred or you are pretty sure (+90%) that it will
Medium: The risk will most likely occur- probability is 51% to 90%
Low: It is possible that the risk will occur, but not likely. Probability is 10% to 50%
The impact of a potential risk on the project can typically be determined by answering the
question: "If (Condition) occurred, how significant would the impact on the project be?
Responses will fall under three possible options:
Low:
PAGE | 31
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
Overall project budget will not be impacted (that is, overrun can be absorbed
elsewhere)
Impact on schedule will be only on non-critical tasks
No noticeable degradation in quality
Benefits will not be impacted
No additional resources will be required
Overall chances of project success not significantly impacted
Medium:
May impact overall project budget by up to 10%
Dates on critical tasks are impacted, but can be recovered by
'tweaking' the plan
Noticeable, but acceptable degradation in quality
Benefit numbers and timing are impacted, but change is acceptable
Chance of project success is reduced, but still at an acceptable level
High:
Project budget impact of greater than 10%
Slippage of key dates-major re-planning exercise required
Unacceptable degradation in quality of work
Benefits are significantly impacted
Risk of failure on the project is unacceptably high
The project management team has determined that we will focus on those risks that have
medium probability with a high impact, high probability with a medium impact and a high
probability with a high impact
6.1.4 PROJECT RISK RESPONSE STRATEGIES
Risk response planning must be appropriate to the severity, probability and impact of the risk,
cost effective in meeting the challenge, timely to be successful, realistic within the project
context, agreed upon by all parties involved, and owned by a responsible person. Unknown
risks cannot be managed although project managers may address them by applying a general
contingency based on experiences with similar projects
The following strategies for responding to risks may be adapted, based on the nature of the risk:

Risk Avoidance- changing the project plan to eliminate the risk or condition or to protect
the project objectives from its impact.

Risk Transference- seeking to shift the consequence of a risk to a third party together
with ownership of the response. Simply gives another party responsibility for its
management; it does not eliminate the risk.
PAGE | 32
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT

Risk Mitigation- seeks to reduce the probability and/or consequences of an adverse risk
event to an acceptable threshold. Taking early action to reduce the probability of a risk
occurring or its impact effecting the project is more effective than trying to repair the
consequences after it has occurred.

Risk Acceptance - indicates that the project team has decided not to change the project
plan to deal with a risk or is unable to identify any other suitable response strategy. May
include developing a contingency plan to execute, should a risk occur.
6.1.5 PROJECT RISK ROLES & RESPONSIBILITIES
To successfully Manage Project Risk, the following resources are required to fill the process
roles and responsibilities:
RESOURCE ROLES AND RESPONSIBILITIES
ROLE
Project Manager
RESPONSIBILITY







Project Team
PAGE | 33


Schedules and facilitates planning meetings to develop
the Risk Management Plan
Schedules and facilitates Risk Identification sessions to
determine which risks might affect the project and to
document their characteristics
Schedules and facilitates Risk Analysis sessions to
assess the impact and likelihood of identified risks and
to prioritize risks according to their potential impact
Schedules and facilitates Risk Response Planning
sessions to develop options and determine actions to
enhance opportunities and reduce threats to the
project’s objectives
Incorporates Risk Management Plan activities into the
Project Plan
Monitors and controls risk by keeping track of the
identified risks, monitoring residual risks, identifying
new risks, ensuring the execution of risk response
plans, and evaluating their effectiveness in reducing
risk
Reports Risk Management activities and results to the
Project Team, Steering Committee, and Project Sponsor
Participates in the Risk Management Planning
Participates in the Risk Identification process
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
RESOURCE ROLES AND RESPONSIBILITIES
Project Sponsor, Steering
Committee, Key Stakeholders




Participates in the Risk Analysis process
Participates in the Risk Response Planning process
Executes Risk Response Action Plans as approved
Participates in ongoing risk monitoring and control


Participates in the Risk Management Planning
Determines the level of risk acceptable for the
organization
Reviews Risk Analysis results
Approves and provides support to Risk Response Plans
Reviews Risk Management Reports throughout the
project



6.1.6 PROJECT RISK TRACKING APPROACH
Risks will be documented in an Excel file named “Project Risk Register” following the
procedures outlined below.
DURING PHASE I – PLAN & PREVIEW
1. Conduct Risk Identification sessions to determine which risks might affect the project and
to document their characteristics.
2. Conduct Risk Analysis sessions to assess the impact and likelihood of identified risks and
prioritize them according to their potential effect on project objectives.
3. Conduct Risk Response Planning sessions to develop options and determine actions to
enhance opportunities and reduce threats to the project’s objectives.
4. Incorporate Risk Management activities, including Risk Response Plan items, in the Project
Plan.
DURING EACH PHASE
5. Execute Risk Response Plans.
6. Monitor and control risk by repeating the Risk Identification, Risk Analysis, and Risk
Response Planning processes, using the initial results as a starting point.
7. Report Risk Management activities and results to the Project Team and Steering Committee
and Project Sponsor.
PAGE | 34
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
6.1.7 ISSUE MANAGEMENT
6.1.7 .1 Issue Management
The purpose of this section is to establish procedures for managing various issues that arise
during implementation projects. Included are definitions of action items, project issues, and
problem incidents; along with methods of escalation and administration.
6.1.7.2 Administering Action Items
Action items are activities typically identified during a meeting or work session that require
follow-up work. Action items are managed through an Action Item Log. Action items identified
during a meeting are transferred from the meeting minutes onto the Action Item Log by the
project manager and are assigned a due date and a responsible party.
The Project Managers are responsible for monitoring action items to ensure that each is assigned
to the correct resource and that the resolution is obtained within the specified timeframe.
Open action items are discussed at team meetings. Action items are escalated by the project
manager to the Issue Log for management attention if not resolved in the specified timeframe.
6.1.7.3 Administering Project Issues
Issues are items that create an impediment to the current project activities. Issues can be
escalated from action items. Any project team member may also identify an issue at any time.
The team member documents the issue and submits the item to a Project Manager. The Project
Manager records the issue in the Issue Log. Issues are assigned a priority, due date, and person
responsible. The Project Manager maintains all updates to the status of issues.
The open issues that are due within the next week are discussed at Project Team and Project
Weekly Status meetings. Unresolved issues may be escalated to the Steering Committee if the
Project Managers believe that resolution will not occur in a timely manner without Committee
involvement.
Issue strategy sessions may be called by the Project Managers to discuss alternative solutions
with business resources. All affected parties, including the project team will be invited to attend
the meeting. Business managers will be notified of all scheduled strategy sessions so he/she can
attend at his/her discretion.
6.1.7.4 Administering Problem Incidents
Issues associated with testing, either the testing of the functionality or of the development of the
product solution, are defined as Problem Incidents.
PAGE | 35
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
Test scenarios and scripts have a pre-defined expected outcome. If in the course of executing the
scenario or script, a failure to meet the expectation occurs then the problem must be recorded so
that the failure can be corrected. Failure to meet the expected outcome can be sourced to one of
many points in the process. The documentation of the problem incident provides the detail of
events to determine the source of the problem, fix the problem or fix the scenario or script, or fix
the test data required to produce the desired result. The test participant documents the problem
incident and submits the item to the test coordinator. The test coordinator records the problem
incident in the Tracker tool. Problem incidents are classified and assigned a priority, due date,
and person responsible. The Tracker tool provides sorting and reporting so that problem
incidents can be distributed to the appropriate person responsible and give the statistical
perspective of the status of all problem incidents.
The open problem incidents that are due within the next week are discussed at Test Status
meetings. Unresolved problem incidents may be escalated to the Issues Log if the Test
Coordinator believes that resolution will not occur in a timely manner without Management
involvement.
6.1.7.5 Issue Escalation Procedure
An issue may be escalated to a change request after analysis of the alternative solutions
following change control procedures as documented in the Scope Management Plan. The Project
Managers and the Steering Committee must approve change requests.
6.3 SCOPE MANAGEMENT PLAN
6.3.1 CHANGE CONTROL
6.3.1.1 Change Control Process
Project change control will be an on-going task during the upgrade of the Oracle PeopleSoft
Financials Solution, which will include identifying and managing changes that positively or
negatively impact the project scope and/or schedule. Project change control includes
identification, analysis, control, and communication of proposed scope changes during all project
phases.
6.3.1.2 Change Control Strategy
The Share Management has expressed a desire to maintain as much of the delivered functionality
of the Oracle PeopleSoft Financials Solution as is practical while meeting the business
requirements of the Share community. Project Management endorses this commitment;
therefore, the project change control strategy is to keep changes to a minimum.
PAGE | 36
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
6.3.1.3 Change Control Procedure
Changes to the Project Scope may be requested at any time. Since a change could affect the
project cost or schedule, both Project Management and Steering Committee must review and
approve the change.
The Change Order Process will include:
 Initiating the request through a formal Change Request document.
 Documenting the business purpose of the requested change.
 Defining the work to be performed and the deliverables to be provided in implementing the
change.
 Outlining the acceptance criteria for the work and/or deliverables.
 Estimating the level of effort to implement the change.
 Providing the effect, if any, of implementing the change on all pertinent project schedules.
 Providing the total estimated cost of implementing the change.
 Requiring a final review and signature of approval to proceed.
 Ensuring that work will not begin on any proposed change until final approval is received.
The Change Request document with estimated effort and impact on the project will be delivered
to the Project Manager within five (5) business days of receipt of the original Change Request.
Additionally, the Project Manager will respond to change order requests within five (5) business
days of receipt of the written request for the change. Change Requests that must be presented to
and approved by the Steering Committee will follow the guideline of five (5) business days for
approval from the receipt of the Change Request document.
Change Requests will be entered as a type of issue into the Problem Incident Reporting tool
(Tracker), thereby providing the capability to track, route, and report on the Change Request.
Change Requests are also reported at the Monthly Steering Committee meeting.
6.4 PROJECT BUDGET MANAGEMENT
Costs estimates are the costs applied to an activity in a project by assigning resources with
associated rates or fees. Resources can include equipment, material, technology, processing
cycles, or people. The total cost is critical and should be consistent with the proposal; include
breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an
appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or
deliverable).
6.4.1 BUDGET TRACKING
PAGE | 37
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
6.5 INDEPENDENT VERIFICATION &VALIDATION - QUALITY
REVIEWS
Periodic project reviews are an important part of managing a project. The intent of the review is
to assist the project team by providing a fresh perspective on the project plan and the status of the
project as well as ensure that our work is of the highest quality. An experienced manager who
has knowledgeable in project management methodology and procedures will conduct
Independent Verification & Validation.
6.5.1 OBJECTIVES
The objectives of the Project Quality Review are to:





Review actual performance as it relates to timeline and budget;
Verify adherence to Project Management procedures and project standards and methodology;
Ensure the team has support and guidance to successfully carry out its mission;
Determine the client’s level of satisfaction with the project.
Make recommendations to help improve quality, client satisfaction, cost-effectiveness, and
timeline.
6.5.2 PROJECT QUALITY REVIEW PROCESS
PROJECT QUALITY
REVIEW PROCESS
STEP
1. Schedule Review
2. Assign Reviewer
PAGE | 38
DESCRIPTION
 Ideally, the project review
schedule will be built into the
Project Charter and Project Plan
 A Reviewer is assigned based on
timing, availability, and location
 If it is anticipated that this project
will undergo a series of reviews,
the reviewer is committed for the
duration
RESPONSIBILITY
Project Manager
SHARE Systems Manager
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
PROJECT QUALITY
REVIEW PROCESS
STEP
3. Prepare for Review
DESCRIPTION
Request documents from the
CedarCrestone Project Manager that
will be available on arrival to the
review:
 Project Management Plan
 Completed Project Change
Control Requests
 Current Project Schedule
 Minutes and or status
reports/presentations from the last
Steering Committee Meeting and
the last Team Meeting
 Deliverables Approval Matrix
RESPONSIBILITY
Project Reviewer
Project Manager
Based on the timing and status of the
project, the Reviewer prepares a set of
interview questions selected from the
Project Quality Review Inventory of
Questions.
4. Determine interviewees
PAGE | 39
 Project Reviewer and Project
Manager compile a list of
interviewees based upon the
Organization Chart
 Typically this will include the
Project Sponsor(s), Project
Managers, Functional and
Technical Leads, all
CedarCrestone consultants, key
users, and supporting vendor
contact (if applicable)
Project Reviewer
Project Manager
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
PROJECT QUALITY
REVIEW PROCESS
STEP
5. Schedule interviews
PAGE | 40
DESCRIPTION
 It is recommended that as many
interviews as possible be one-onone with the reviewer. When that
is not possible due to availability
or time constraints, try to group
folks by specialty area.
 If possible, reserve a conference
room or office for the reviewer to
use so that interviewees come to
one place and the reviewer’s time
is maximized
 It is important that the interviews
take place in an area that affords
privacy
RESPONSIBILITY
Project Manager
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
PROJECT QUALITY
REVIEW PROCESS
STEP
6. Conduct Review
DESCRIPTION
Project Reviewer comes onsite to:
 Meet with Project Team for
preliminary introductions
(Optional)
 Interview Project Sponsors,
Project Managers, Functional and
Technical Leads, team members ,
and supporting vendor contact (if
applicable)
 Review key project documents
- Project Team Briefing
Checklist
- Project Charter
- Completed Project Change
Control Requests
- Current Project Schedule
- Minutes and or status
reports/presentations from the
last Steering Committee
Meeting and the last Team
Meeting
- Deliverables Approval Matrix
RESPONSIBILITY
Project Reviewer
Project Reviewer may also conduct
phone interviews for any interviewees
who were not available onsite (such
as consultants who have rolled off,
team members on vacation during the
visit, or supporting vendor contact).
Again, a survey is also an option.
7. Document Findings
PAGE | 41
 Prepare Project Quality Review
Reports
 Review draft main report with
Project owners Finalize Project
Quality Review Reports
Project Reviewer
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
PROJECT QUALITY
REVIEW PROCESS
STEP
8. Document any
performance issues
uncovered
10. Present and/or Distribute
the final Project Quality
Review Reports
12. Execute recommended
actions
DESCRIPTION
 This is used to document any
issues requiring further
investigation by the project
manager, the employee’s
supervisor, and/or HR
 Enter information on the Project
Quality Review Performance
Form
 Send the completed form to the
checklist of parties outlined in the
form
RESPONSIBILITY
Project Reviewer
 Project Sponsor(s) and Steering
Committee
 Project Managers
 Project Team
 Director of Engagement
Project Reviewer
Execute recommended actions as
outlined in Project Quality Review
Report
Project Manager
6.5.3 AGENCY/CUSTOMER SATISFACTION
The following is a sample review. The exact schedule should be discussed and defined during
Phase I – Plan and Preview.
First Review
Two to three weeks after the Plan and Preview Phase is complete. While this is
normally a busy time for the team, it is important to have an independent
assessment of the project as early as practical to ensure that all the required plans
and communications are in place and functioning properly.
Second Review
The timing of the second review is dependent on the outcome of the first review.
If the reviewing manager found that all was well, the second review should be
scheduled two to three weeks into the Configure and Develop phase (after the
Analyze and Design phase and after the detailed project schedule has been
developed).
PAGE | 42
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
If the first review identified any issues that might jeopardize its success, a followup review should be scheduled to ensure that any recommended action plans have
been implemented. This follow-up review should be within six to eight weeks of
the first review.
Similarly, if any significant issues surface during the second review, a follow-up
review should be scheduled in a timeframe that will ensure that the issues are
being dealt with effectively. It is recommended that this follow-up review should
also take place within six to eight weeks of the prior review.
Post Review
A final project review should always be performed within a few weeks of the
completion of the major project deliverables (go-live). This review should
concentrate on identifying lessons learned, client satisfaction, and improvements
to the delivery of services.
6.5.2 READINESS ASSESMENT & SYSTEM ACCEPTANCE PROCESS
The project team will use a scorecard approach to review and document the Go-Live Decision.
The Go-Live Scorecard will facilitate a comprehensive review of the SHARE Financials upgrade
prior to the go-live date. It will be used to assess the readiness of the processes, data and business
applications. The scorecard will contain the list of areas to be evaluated, evaluation criteria and a
green/yellow/red status for the areas. The following descriptions outline the status levels:

Green: No Showstopper Issues, area appears to be ready for production or the area is
tracking on schedule for its needs

Yellow : Some known issues, further action is required, such as testing, analysis,
technical solution, change in business process, etc.

Red: Showstopper Issue is known that would prevent the system from going live in
addition to many open development requests and potential business changes .
The Go-Live scorecard will be generated at three decision points in the project:



Initial Decision Point: The initial evaluation of the Go-Live readiness will be conducted at
the end of User Acceptance Testing.
Pre-Cutover Decision Point: An evaluation of the Go-Live readiness will be conducted prior
to beginning cutover activities.
Final Decision Point: A final evaluation of Go-Live readiness will be conducted near the end
of cutover, before the upgraded system is rolled out.
PAGE | 43
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
Any potential showstopper issues will be documented as an outstanding issue and assigned for
resolution during the three reviews. Showstopper issues are being defined as any known issue
that is deemed to prevent the cutover process from completing successfully or an issue that
prevents a key business process from functioning as planned without an acceptable workaround.
An additional output of the readiness assessment will be a “post implementation list”. Contained
in this list will be known outstanding non-showstopper issues that are moved into production.
The listing will include the rationale and impact statement as to why the project can go live with
the issue outstanding along with a resolution plan for closing the issue.
6.7 PROJECT REPOSITORY
The Project Repository is an online file management process that is structured to encourage
accessibility and the sharing of information. This document includes information on the online
file management system set up and usage.
Additional information is available to assist in standardization of file names Information can be
found in the sections defined Document File Naming Conventions.
This material is prepared to assist the project team with document preparation, standardization,
sharing, and storing of documentation.
6.7.1 PROJECT MANAGEMENT DOCUMENTS
The Project Management (labeled “01-Project Management”) folder will serve as the repository
for all project management related deliverables, work products and supporting documents for the
life of the project. Additionally, it will contain the final accepted copies of all deliverables and
work products for the project.
The folders prefixed 01 - 49 will contain the working and development copies of the project
management deliverables and work products that have been identified in the statement of work.
At their discretion, the project management team may elect to create additional sub-folders
beneath each of these folders.
The “Final Deliverables” folder will be prefixed with a 50 and will contain the final accepted
version of all project deliverables and work products in a .pdf format.
6.7.2 CHANGE MANAGEMENT & TECHNICAL MANAGEMENT
The folders labeled 02-Change Management; 03-Technical Management will contain the related
documents for each of these respective areas for the life of the project. The first level of subfolder in each area will be the deliverables and work products associated to each area as
identified in the Deliverables and Work Breakdown Structure. At their discretion, the team leads
have the option of creating lower levels of sub-folders below the deliverables and subfolders.
PAGE | 44
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
6.7.3 PHASES ONE THROUGH FIVE WORK PRODUCTS
All remaining project documentation will be managed in folders that are identified by fivephased methodology as has been identified in the Deliverables and Work Breakdown Structure.
This first level of folders within each of the phases is the work area to store documents for each
of the modules being implemented. The second level of folders is the deliverable and work
products that have been identified in the statement of work for each respective phase of the
project. At their discretion, the team leads have the option of creating lower levels of sub-folders
below the deliverables and subfolders.
6.7.4 FILE NAMING CONVENTION
The following is the standard file name format. This file naming convention will be used for all
documents including contract deliverables and work products
Example format:
Name of File v1 MM-DD-YYYY
7. 0 CHANGE MANAGEMENT PLAN
7.1 CHANGE MANAGEMENT PLAN
The Change Management Strategy integrates communication, risk management, business
process analysis, and training. It focuses on managing changes associated with the SHARE
Financials Upgrade Project in the following key areas:
 Integration with the communication plan to ensure that change-related information is
identified and shared in a timely manner by key communicators
 Mitigation plan to address areas of resistance
 Assessment of the operational impacts on stakeholder groups to formally address
organizational changes, such as changes to business policies and procedures, or changes to
job specifications
 User education that delivers the necessary navigational and transactional knowledge required
to use PeopleSoft.
Activities aimed at helping the State successfully accept and adopt the upgraded PeopleSoft and
potentially redesigned business processes are comprised of three components: leadership,
management of organizational impacts through communication, and educational support.
7.1.1 LEADERSHIP
Because change oftentimes results in resistance, it needs a champion. The more powerful and
visible the champion, the more likely the change will be successful. The Executive Sponsor and
PAGE | 45
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
executive team (”leaders”) are perhaps the most effective communicators of the importance and
necessity for the Upgrade Project.
To gain buy-in from the State’s users, the commitment to change must flow down from the top.
Without active commitment of the leaders, it is impossible to disseminate the message of change.
By confirming the leaders are comfortable with the change, project management can expect
members of the leadership team to act as change leaders.
7.1.2 COMMUNICATIONS
Effective communication is the foundation of any successful project. Organizational change
often struggles because of a lack of priority to communicate the rationale, progress, and impact
of change. By developing a strategy for communication, the State can reduce the risk of
resistance. Communications are a vital tool in managing the change issues tied to this
implementation. The Upgrade Project team’s goal is to minimize the natural resistance people
experience when faced with change by providing project information describing system changes,
process improvements, and new business practices.
Ambiguities that arise are more pronounced during the early stages of a system project. At the
outset, most people do not fully comprehend how the project solutions affect them or why they
are necessary and that may result in a high level of apprehension. Consequently, communications
designed to rationalize changes and reduce uncertainty are appropriate. Publicizing successes and
“quick wins” are especially important as the project progresses.
It is equally important to develop a means of resolving problems. A communication structure to
encourage the disclosure of issues and the discussion of solutions will be developed. As the
system is institutionalized, significant operational problems may occur that are to some degree,
based on misinformation and lack of clarity. In such situations, face-to-face communication is
warranted so that misunderstandings can be cleared up quickly and efficiently.
The Communication Plan may be referred to for additional information regarding the Upgrade
Project’s methods, timelines, and roles and responsibilities for communication.
7.1.3 LEARNING STRATEGIES
Learning strategies cover a wide array of activities designed to set the tone and lay the
foundation for how Oracle is received and used by the user community. Many change
management issues arise because improperly trained users cannot execute their business tasks.
Most users characterize project failure as a system problem while it is possible the failure is a
training issue.
Education and training of users should serve two broad purposes: it should enhance the user’s
understanding of the business so they comprehend both where and why change is necessary, and
it should provide users with the necessary skills to use Oracle. In order to ensure that planned
changes affecting business processes are successful, a Training Strategy will be developed
PAGE | 46
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
during the latter timeframe of the Analyze & Design phase (tentative March 2012). The strategy
will identify:




Which groups (or individuals) require training
The training requirements for each group (or individual)
How, where and when training will be delivered, and
Who will deliver training
7.1.4 TERMS
 Organizational Change Management (OCM) or Change Management – oftentimes,
organizational change management is a term that causes confusion in project management
circles because it has other possible interpretations.
It can refer to the formal policy, method, and procedures of managing change requests that
may affect the scope of the project. In the IT environment, “change management” refers to
specialized procedures for managing and archiving technical change.
In the context of this document, “change management” encompasses activities directed
towards helping the State successfully manage the adoption of new technology and
potentially business process redesign.

Policy – policy are rules (not laws) that mandate actions or constraints and require specific
procedures for compliance.

Procedure – procedures are the means by which policy enforcement occurs. Procedures,
supplemented by instructions, ensure policies are straightforward and simple to carry out.
7.1.5 CHANGE MANAGEMENT STRATEGY
The State’s upgrade vision is to upgrade to a system that meets the following goals:





Upgrade to the most current version of the PeopleSoft software
To not implement or roll-out any new functionality with the upgrade
To adequately train, educate and prepare the State’s user community for the upgraded
software.
Facilitate collaboration and coordination of activities between all involved departments
Improve customer satisfaction.
Widely sharing this vision and its translation is important for managing the expectations of the
software and of the project’s intent. Unrealistic expectations of the project’s outcomes can lead
to negative impressions of what the PeopleSoft software and the project team are capable of
accomplishing. Plans for sharing this vision and the project’s impact are included in the
communication plan.
PAGE | 47
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
Managing stakeholder expectations and potential changes to roles and responsibilities are major
factors that contribute to the need for leveraging OCM for the Upgrade Project. The following
sections discuss these factors.
7.1.6 STAKEHOLDER EXPECTATIONS
Part of managing change is managing expectations at an individual level. Information technology
projects typically face expectation issues and take time (including post go-live time) to stabilize.
Factors that contribute to mismatched expectations are:

Functionality rollout – The State users currently works in a PeopleSoft environment in which
no new functionality has been implemented or rolled out since the initial go-live in 2006.
Additionally, the state remains on the 8.8 version of the software that they went live with in
the initial implementation of the software. With the upgrade the state will be rolling out
PeopleSoft Financials 9.2 which has much increased functionality and potential process
improvements over 8.8. The scope of the upgrade is not to introduce any new functionality.
In any event, the outcome may result in disappointment by some users because there is an
expectation of increased or improved functionality as a result of the upgrade to then new
version.

The factors above may contribute to resistance. To ease the users into the upgraded system and
ensure a smooth transition, the change management strategy must address these factors
continually throughout the project.
7.1.7 ROLE AND RESPONSIBILITY CHANGES
Another typical reason for apprehension and resistance is a change in roles and responsibilities.
The potential changes in business processes may lead to confusion and resistance.

New or changed roles and responsibilities – If a re-design occurs, it may introduce re-defined
roles and associated responsibilities that result in tasks being completed differently. It may
also mean that users acquire new responsibilities or relinquish existing ones.
Changing roles and responsibilities is a critical soft factor that requires attention. The primary
cause of business redesign and IT project failure (assuming product design and configuration
meets user needs) is not limited to the users’ inexperience or lack of knowledge. It could also
mean that they do not know what is expected from them, or expectations are not clearly defined.
7.4.8 CHANGE MANAGEMENT IN THE PROJECT LIFECYCLE
The ERP Project uses a formal methodology to drive the project from start to finish. Within each
methodology phase of the project, the change management events focus on providing
information and assisting individuals through the various states of transition on the commitment
curve (Figure 1).
PAGE | 48
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
TABLE 1: COMMITMENT CURVE
7.1.8.1 Plan & Discover - Awareness
During this phase of the project, change management assessment and planning activities are
undertaken. Most notably, an analysis is completed to gather necessary information in areas such
as:





Identification of key project stakeholders
Assessment of existing change leadership infrastructure
Clarification of the change leadership objectives, approach, and deliverables—overall as well
as for each identified stakeholder group
Identification of key change leadership-related resources
Clarification of the roles and responsibilities for key change leadership-related resources
PAGE | 49
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT

Development of strategies to get the most effective support possible for the project and
reduce any obstacles to successful implementation of the project
Orientation and knowledge transfer to the project team is another key focus during this initial
phase of the project. Project team members are subject to most, if not all, of the impacts of
change that will be managed for the project.
7.1.8.2 Analyze & Design - Awareness
In this phase of the project, most of the change issues are general in nature. Execution of the
communication plan formally begins. Communication events will use the following guidelines:








All communication is managed through the Communication Plan (align internal, external and
transition communication)
Communication will be open, honest and two-way
Communication will always be delivered as soon as is practicable to stop any rumors
Communication will be conducted on a regular basis
Messages will be customized to meet the needs of the audience
Existing communication methods will be leveraged
Communication will be conveyed through a variety of channels to effectively reach targeted
stakeholders
Feedback will be solicited and evaluated in order to monitor, check, and improve
communications
Towards the end of this phase, the project team will have a great deal more information on the
organizational impacts associated with the specific upgrade effort. The impact analysis effort
begins in this phase and focuses on the changes associated with specific day-to-day job activities
of State staff.
7.1.8.3 Configure & Develop - Understanding
The intent of this phase is to communicate and clarify the magnitude of change at all levels of the
State with the intent to provide users a view of how the upgraded PeopleSoft system is going to
influence day-to-day job activities. Communications regarding specific impacts on people,
process, policy, and infrastructure are distributed. The Change Management team, functional
leads, and Executive Sponsor are key conduits for the distribution of this information.
Training development activities, which began earlier in the phase, are winding down late in this
phase. The anticipated impacts associated with training end users are communicated to the
appropriate stakeholders, including management employees so plans can be set to account for
training requirements as the work plan transitions to a deployment mode.
7.1.8.4 Test & Training - Acceptance
As the last rounds of testing are wrapping up, training is being completed, and the project team is
preparing to cut over to the upgraded PeopleSoft. The Change Management team helps facilitate
a transitional period that begins in this phase and carries over to the Deploy & Optimize phase.
PAGE | 50
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
During this transitional period, management of training-related impacts becomes the primary
focus.
Management of go-live and production support issues are a key focus in this phase. Information
outlining the variety of end user support services is the primary communication event.
7.1.8.5 Deploy & Optimize - Commitment
In this final phase, management of change associated with cutting over to the upgraded system
becomes the primary focus. A variety of activities are undertaken to help users adapt to the use
of PeopleSoft, including:


Targeted end user support for specific work tasks, such as entering and submitting
requisitions
Consultant support to continue knowledge transfer to functional leads who will be
responsible for support after the consultants leave
Management of training-related impacts continues to be a focus in this last phase. Employees
who were unable to attend or complete training prior to go-live will be trained during this phase.
7.1.9 CHANGE MANAGEMENT TEAM – ROLES & RESPONSIBILITIES
Change management cannot be done by one person. Effectively leading the project through this
time of change requires actions by anyone involved with moving the organization from its
current state – how business is done – to its future state – how business will be done. Executives,
senior managers, the project team, and change management resources must all work together to
make the SHARE Financials Upgrade Project successful at the organizational and individual
level.
RESOURCE ROLES AND
RESPONSIBILITIES
ROLE
Leadership
Change Management Team
PAGE | 51
RESPONSIBILITY

Acts as a change leader and final escalation point for issue and
resistance resolution

Champions the initiatives by providing visible, active support

Advocates the change to peers and other stakeholders

Demonstrates the adoption of change – “walk the talk”

Understands and communicates business reasons for and benefits of
the change

Authors and distributes project communications

Champions the redesigned business processes and a new system
throughout the State
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
RESOURCE ROLES AND
RESPONSIBILITIES
Project Team

Attends design sessions to understand business process changes

Assesses and understands the organizational impact of business
process changes – (policy, process, procedures, communication,
education, training)

Supports and encourages employees during the change process

Provides feedback to the Executive Leadership team on areas of
resistance, communication needs, and visibility requirements

Champions the redesigned business processes and a new system
throughout the State

Understands and communicates business reasons for change

Participates in an active, positive manner

Facilitates design sessions for business processes

Supports employees through the change in area(s) of responsibility

Provides feedback to the Change Management and Executive
Leadership teams
7.2 COMMUNICATION PLAN
7.2.1 COMMUNICATION PURPOSE & OBJECTIVES
The purpose of the Communication Plan is to inform the leaders and staff - as well as vendors,
citizens and many other stakeholders- about the project in the right way, in the right time, using
the most effective media. This plan defines the goals, methods, timelines, roles, and
responsibilities for communicating information about the Upgrade project to the entire
community
The objectives of the communication plan are to:



Manage employees’ expectations
Coordinate the Projects activities with all communication activities
Communicate events, status, process changes and the like to stakeholder groups
PAGE | 52
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
7.2.2 COMMUNICATION APPROACH
Enterprise-wide communication depends heavily on the contributions of Functional Team Leads
and project leadership. Communications begin with Key Messages which are generated by the
leadership, with facilitation by the change management team. Key Messages are designed to
convey that Leadership has a plan for, and commitment to, project success and all the changes in
processes and duties that come along with the project implementation.
Functional leads and Subject Matter Experts (SMEs) will be the primary change and
communication agents with end users in their respective departments. The change management
team will provide them with standardized communications.
Because of the differences of the individual target audiences, each will require a different type
and frequency of communication. Each target audience has mechanism for providing feedback
and records of these communications are maintained to verify action items have been addressed.
Continual assessment (formal and informal), structured customer feedback, and user forums help
ensure that stakeholders are getting the information they need. These needs will change and
evolve during the course of the project. The Change Management Team will proactively assess
these needs and recommend communication activity to the Project Management and Steering
Committee.
7.2.3 COMMUNICATION SUCCESS FACTORS
The following conditions are critical to the successful execution of this Communication Plan:

The Project Sponsor, SHARE Systems Manager and Advisory Board understand the
importance of communication and play an active role in key communication events
(visible, consistent, and communicative project sponsorship)

Financial support (budget) and resources are provided to design, develop, and deliver
effective communication materials and events

Feedback is kept confidential and used constructively to improve communication
effectiveness

Creativity is recognized and innovation through technology (which is the cornerstone of
this project) is encouraged
6.5.1 COMMUNICATION ROLES
RESOURCE ROLES AND
RESPONSIBILITIES
ROLE
RESPONSIBILITY
Leadership
The Project will result in changes to documents, processes and
procedures, due to both new system tools and transaction steps.
PAGE | 53
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
RESOURCE ROLES AND
RESPONSIBILITIES
Successfully implementing these changes will require visible buyin and support from the Executive Sponsor, members of the
Steering Committee, and business process owner directors.

Participate in team meetings, key communication events, and
training sessions, as appropriate

Contribute to newsletters and other internal communications

Communicate the goals and benefits of the project within
their spheres of influence
Change Management Team
Change Management Leads share primary responsibility for
planning and delivery of the communication effort. For creation of
messages and strategies, they will partner with a number of State
resources, which may include the Training Team, Labor Relations
department and others. These partnerships, with input from the
project team, will produce the following deliverables:
Project Team

Articles and updates regarding the project, for internal
communications and for external outreach, for example, to
vendors

Creation and dissemination of project media treatments for
use at promotional events, presentations, and special
meetings

Planning and coordination of meetings to share the project
vision and goals
The Change Management Team has completed the foundational
work with the project Advisory Team to identify stakeholder
audiences and where they are in the change management process.

Refine information needs for each audience.

Identify communication vehicles, meetings, events, and other
communication opportunities

Create and disseminate messages

Solicit feedback and monitor effectiveness of communication
7.2.4 COMMUNICATION PROCESS
The Communication Plan is executed through a Communication Matrix, which segments the
organization’s audience into specific targeted audiences with specific information needs. The
Communication Matrix will also determine the form and media through which these audiences
PAGE | 54
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
should receive the information they need, when, how often, and from whom. Finally, feedback
loops will be identified for each target audience to monitor the effectiveness of our
communications. Although the matrix is designed to cover the life of the project, it will be
updated throughout the project as required. This will ensure the incorporation of lessons learned
from feedback and realign change and communication activities to better support future stages of
the project.
Following are a few techniques to best position communication efforts and sustain desired
behavior:









Develop a plan that is dynamic and interactive
Integrate communication initiatives with key project events
Develop a clear, expeditious approval process
Deliver messages in a style that underscores the new direction, behaviors and results
Focus on change “stories” and on behaviors needed for business results
Utilize the power of leadership by communicating a unified message from the top
Ensure organizational acceptance through delivery of all messages by internal staff as
opposed to consultants
Address concerns about the impact of the project on the user community
Include consistently-worded key messages in all communication efforts that explain:
- What the project is about;
- Why the organization is implementing the change and cannot continue with the status quo;
- Benefits of the new process;
- When key events will occur;
- Whom to contact with questions and
- How the change will happen and be implemented
7.2.5 TARGET AUDIENCES
Target audiences for this plan include all stakeholders who will be impacted by the project. The
following target audiences have been identified:










Citizens of State of New Mexico
Advisory Board
Project Team
Business Process Owner (BPO) Managers
Department/Agency Heads
Critical Users
Business Process Owner (BPO) Staff
Department Subject Matter Experts (SMEs)
End Users
Partner Organizations
PAGE | 55
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT



External Stakeholders
Vendors
Third Party Interface Organizations (Banks, etc.)
The logistics of communicating with each of these target audiences will be addressed in the
Communication Matrix. This is one of the first responsibilities of the Change Management
Team. The matrix will identify what information is to be communicated, when, how often, how,
and by whom for each of the target audiences listed above.
In addition, the Change Management Team must work with the project team and business
process owner managers to develop contact information and identify distribution vehicles for all
members of each target audience.
7.2.6 VEHICLES FOR COMMUNICATION
This section lists the various media and vehicles that will be used for communications.
Print
 Organizational publications
 Memos
 Posters
 Bulletin boards
 Direct mail and inserts, e.g. for Vendors
 and others tools as the plan is refined
Face-To-Face
 Demonstrations or “Road Shows”
 Liaison education sessions
 Standing meetings
 User forums and “brown bag” sessions
 Testing and Training Sessions
Electronic
 Email
 Webpage
 Videotaped messages
 Videoconferencing
 Webinars (live and recorded)
 UPK demonstrations
PAGE | 56
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
7.2.7 TOPICS FOR COMMUNICATION
The following topics will be included in communications:














Project essentials: project name, goals and expectations, case for change
Executive commitment and expectations
Management commitment and expectations
Key metrics to measure success
Implementation milestones and timelines
Project status and progress
Project team
Impact of implementation effort on operations
Software functionality (what will the software do, overall and area specific)
Glossary of new terms
Preview of business process changes – area specific
Policy and procedure changes / implications
Training strategy and plans
Testing results
The Communication Matrix, which will provide a framework for specific planning,
development, and distribution of communications on the topics listed above, and others as they
arise.
7.2.8 MONITORING COMMUNICATION EXECUTION (COMMUNICATION MATRIX)
The Communications Matrix in Appendix A of this document is essential to execution because it
tracks each communication element’s assignment, timing and approval status, all of which are
necessary for follow-through on this undertaking.
7.2.9 STATUS MEETINGS
There are several meetings that will be held on a regular basis throughout the duration of the
project.
All meetings are guided by an agenda prepared before the meeting. Notes will be kept during the
meeting and documented as minutes which will be reviewed by attendees and corrected as
needed. Typically the minute taker is assigned at each meeting and the responsibility is shared by
all.
Throughout the course of the project various meetings will be held. Some of the meetings
include, but are not limited to, the following:
PAGE | 57
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
PROJECT TEAM MEETINGS
TYPE/NAME
FREQUENCY DAY/TIME
DURATION
Project Status Meeting
Weekly
TBD.
1 Hour
Project Team Meeting
Weekly
TBD
1 Hour
Communication Team
Meeting
Weekly
TBD
1 Hour
7.2.10 PROJECT STATUS REPORTS
Weekly Status Reporting
Status Reporting describes where the project stands as the status is recorded. The Status Report is
a document that is produced on a weekly basis by the project manager consolidating the weekly
reports submitted by individual project team members. The status reports will cover activities
and deliverables completed during the reporting period or that will begin during the next
reporting period, and issues that may have been raised or resolved during the reporting period.
Executive Status Reporting (Progress Reporting)
In addition to weekly status reporting, an executive level Progress Report will be produced
monthly. Progress Reporting involves collecting and disseminating information in order to
provide stakeholders and SHARE management with information about how resources are being
used to achieve project objectives. The Progress Report will generally include at least the
following information in relation to key project indicators:
 Milestones
 Accomplishments
 Next Steps
 Risks
Overall it will provide the executive with an overview of the current progress of the project.
7.3 CHANGE LIAISON NETWORK
This document is a guide to starting and managing a Change Agent Network. The targeted
audience is change leaders throughout the organization who will initiate and help manage change
management and communication efforts.
In addition to describing a change agent network, the document will also delineate the process
for starting and managing a change agent network, and detail the roles and responsibilities of
those involved in the change agent network.
PAGE | 58
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
7.3.1 INTRODUCTION & OBJECTIVES
Leadership and employee understanding of the State’s upgrade is critical to implementation
success at “Go-Live” and beyond. This involves aligning leaders and employees across the State
and making them aware of the upgrade project’s goals, its importance, and their role in preparing
the State for change. This alignment is crucial in gaining “buy-in” for the project goals, ensuring
key messages are carried throughout the State and ensuring ownership of the upgraded system.
The Change Agent Network is critical in involving employees in the upgrade process.
7.3.2 WHAT IS A CHANGE AGENT NETWORK
A Change Agent Network is:
 A two-way communication channel to ensure rapid and accurate communications to the
business
 A cross-functional network of people outside the project team who will serve as advocates
for the upgrade and system or process related process/policy changes
 A group of people who influence positive change
 A formal network to leverage peer to peer communication (in addition to traditional
communication methods)
A Change Agent Network is NOT:
 A replacement for existing communication mechanisms. Change Agent Network
communications are more tailored to specific employee groups, less formal, and typically
more engaging than traditional communications
 A substitute for the existing management structure
 A substitute for line management’s accountability in achieving upgrade goals
 A decision-making body
7.3.3 WHY INSTITUTE A CHANGE NETWORK
 To Minimize Upgrade Complexity - communication is most effective when it is face-toface. People want an opportunity to be heard and give their opinion. With a project of this
size it is impossible for the project team to communicate individually without assistance.
 To Build Accountability and Ownership - include formal mechanism for gathering
feedback regarding the integration and monitoring employee impact. Enable Change Agents
to resolve concerns without waiting for “formal, official” communications.
 To Enhance Speed - Quickly disseminate accurate upgrade information and minimize
rumors that can derail the effort.
 To Maximize Productivity – free employees from random communications and noise and
allow them to focus on their current responsibilities (e.g. curtail rumors and speculation and
focus on “what does this mean to me” issues).
 To Promote Understanding - provide front-line resources to assist people in dealing with
uncertainty and ambiguity as the State progresses through the upgrade.
PAGE | 59
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT


To Advocate Positive Change - enable face-to-face and informal communications that are
required to change behaviors and attitudes.
To Explain “What’s in it for me?” - tailor communications language, messages, and
methods to employees who will be impacted by changes due to the upgrade.
7.3.4 WHO PARTICIPATES IN A CHANGE AGENT NETWORK
A Change Agent Network is specifically facilitated by the efforts of two categories of employees
who are “credible messengers” of information regarding the upgrade project.


Change Leaders – leaders are senior level, experienced managers who are well respected
within the organization. They take a visible and active role in demonstrating support and
driving the integration at the executive level. They will also:
o Lead communication efforts in their department/division – update executive peers on
implementation status and issues, consistently distribute messages to their areas of
influence
o Aid in engaging employees and in managing the Change Agent Network in their
areas of influence
o Assist in planning for and supporting any workforce transitions
o Understand impacts and integrate the project into their planning
o Communicate key project messages formally and informally
o Support project infrastructure and overall direction
o Provide feedback and suggestions to project management
Change Agents – use informal peer networks to communicate and gather information from
the business.
o Identify members of the peer network
o Communicate to peer groups and provide feedback and suggestions to the project
team
o Assist in identifying potential problems, issues and sources of resistance at an
employee level and help to resolve them
o Engage in learning about new functionality
o Change Agents will be composed of super users who are technologically adept and
after system and process training, can serve as experts to transfer knowledge to their
peers
o Change Agents will also be composed of individuals who comprehend policy and
process changes, possess effective presentation and communication skills and thus
can transfer key messages and knowledge to their peers
7.3.5 HOW WILL THE CHANGE AGENT NETWORK WORK
The Change Management Team, as the initiators and manager of the Change Agent Network,
prepare communication material, and provide end-user training. The Training Lead may also
provide assistance with this effort as communications become focused on the end-user training
program later in the project.
PAGE | 60
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
Communications, which are initiated by the State’s Change Management Team, will be shared
with Change Leaders and/or the Change Agents so that they may deliver key messages to
Change Agents and their respective departments/divisions. These individuals may then tailor
these communications, again with help from the State’s team, to meet the needs of employees in
their departments/divisions. Change Leaders should monitor these interchanges and measure the
effectiveness of the Change Agent Network. Change Leaders should also communicate at
regular intervals with the State’s Change and Training Teams to provide feedback and discuss
salient issues.
Change Agents (key front line employees) will receive communications briefings and reviews
from the Change Leader and/or the Change Management Team and will formally and informally
disseminate them to their peers. They will be expected to informally share implementation
information with their peers as frequently as possible (e.g. weekly). Some examples of Change
Agent communication “sessions” include lunch conversations, existing staff meetings, and
hall/elevator/break room conversations. Additionally, several Change Agents may act as
PeopleSoft “super-users,” providing desk-side training and coaching as the system is rolled out.
Feedback from these sessions will be gathered by the Change Agents and funneled back to
Change Leaders (optionally directly to the Change Management Team); the Change Leaders
will, in turn inform the State’s Change and Training teams of progress and issues. In areas where
the communication appears scattered, the Change Leader will encourage increased Change
Agent support.
Communication events and materials to be disseminated by the Change Agent Network should
be engaging and varied in order to capture the attention of all State users, especially those
affected by the new features/functionality that will be implemented. For best results, methods
will need to be formal and informal, one-way and two-way.
The Change Agent Network is premised on the cascading of information to all employees or at
least those affected by the upgrade project. Ideally, State PeopleSoft users should understand the
objectives and importance of the upgrade; those affected will understand how their jobs have
changed as they relate to accessing PeopleSoft for daily transactional activity and what they must
do to succeed.
7.4 KNOWLEDGE TRANSFER PLAN
7.4.1 OVERVIEW
When expertise and information are passed from one person to another person, knowledge
transfer is occurring. During the course of the SHARE Financials Upgrade Project the
knowledge transfer will be incorporated into many aspects of the project through the use of
proven methodologies and processes, and project infrastructure. A foundational element of our
project infrastructure will be collaborative teams with shared responsibility for design,
documentation, testing and training activities. This approach will support and facilitate ongoing
information sharing and team member collaboration and will provide for immediate and
continuous knowledge transfer in both directions.
PAGE | 61
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
7.4.2 PROJECT TEAM STRUCTURE
Particular attention will be paid to pairing State of New Mexico staff with consulting resources.
Collaborative teams and pairings will be defined, team-building and communication activities
will be conducted, and the physical location of consultants in relation to their State of New
Mexico counterparts will be taken into consideration. This structure supports a collaborative
approach to analysis and decision-making that ensures team members are involved, not just
informed, which builds an understanding of the implications of our decisions. In most cases,
consultants and State of New Mexico staff share responsibility for key activities, decisions, and
deliverables.
7.4.3 TEAM MEETINGS
Regularly scheduled meetings will be held to provide opportunities for group communications
and information sharing. Weekly project team meetings are led by the Project Managers and
used to provide status updates, share information, and manage issues.
Similar standing meetings will be held by the Technical Lead and Functional Lead and will
include the State of New Mexico and consultant leads. These meetings generally have an
emphasis on task assignment, issue resolution and skill building.
Within individual modules, such as AR, AP or Billing, meetings are not required because there
will be on-going daily communications between State of New Mexico and consultant
counterparts.
When appropriate, State of New Mexico employees who have been designated as Subject Matter
Experts (SMEs) will be included in meetings, problem resolution and code walkthroughs.
7.4.4 DOCUMENTATION STRATEGY & GUIDELINES
A repository has been developed to facilitate access to documentation for the project. The
creation of deliverables will use a collaborative approach. This approach will serve to gather
input from multiple sources and to provide a pre-submission checkpoint for the deliverable.
Once drafted, deliverables go through a formal review process. The specific reviewers for each
document depend on the content of the document to be reviewed. The use of a shared drive for
documentation storage makes it easy for any team member to access information.
7.4.5 CHANGE MANAGEMENT AND COMMUNICATION PLANS
The Change Management Plan includes the use of assessment techniques and a stakeholder
analysis that will facilitate the identification of knowledge transfer and training issues as part of
the ongoing readiness analysis. Communications media will be tailored to facilitate information
sharing to stakeholders outside of the primary team.
7.4.6 DELTA ANALYSIS
The Upgrade Business Delta Analysis Workshop is intended to help the State review and
understand the business processes that may be affected by an upgrade. The purpose of the
Business Delta Analysis is to review:
PAGE | 62
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT






Current functionality used.
Current business processes.
New software features to improve business processes.
Review additional business process improvements for subsequent phases.
Review major customizations and potential impact.
Provide impact analysis of new features as they pertain to current customizations .
7.4.7 DESIGN REVIEWS
Both functional and technical designs are reviewed and approved by technical leaders. These
detailed reviews provide State of New Mexico team members and staff the opportunity to
contribute input to the design while they gain insight into the planning and execution of the
designs at a key point in the project life cycle.
7.4.8 TESTING
The testing phase of the project provides the opportunity for team members to develop a deep
understanding of their new system, its customizations and associated business processes. To
follow are the knowledge transfer highlights of testing; a full Testing Plan will be developed in
Phase III of the project.
System Test: This phase is iterative, so the State of New Mexico functional team will have high
volume, hands-on experience with the system, including valuable exposure to behind-the-scenes
processing, troubleshooting and problem resolution.
Similarly, the State of New Mexico technical team will learn more troubleshooting techniques
through hands-on work and by shadowing their consultant counterparts.
User Acceptance Testing (UAT): This phase provides an opportunity for additional SMEs and
department end users to have exposure to the system when it is close to its finished state. This
step expands knowledge transfer activities beyond the project team.
7.4.9 TRAINING
Training is a cornerstone of knowledge transfer. A full Training Plan for the project will be
created in a preliminary state in Phase II and a finalized state in Phase IV. A high level summary
of end user training is as follows:
1. If needed, during the project, State of New Mexico team members or SMEs may receive
classroom training in required skills such as query writing or test participation.
2. In preparation for go-live, selected State of New Mexico employees will participate in a
Train the Trainer course, where they will be taught the content of the formal training
classes as well as sound adult learning principles and techniques.
3. During go-live, end users can attend classroom training and utilize training topics built
with the User Productivity Kit (UPK) tool. A detailed plan of UPK topics will be
included in the Finalized Training Plan in Phase IV.
PAGE | 63
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
8. 0 TESTING
8.1 TESTING STRATEGY
8.1.1 OVERVIEW
This strategy defines the approach, processes, resources and procedures for setting up and
executing the test plan. The credibility and success of the project initiatives are based on the
ability to achieve a quality upgrade. The test phase of the project will demonstrate that
PeopleSoft Financials application is functioning according to the design and performance
specifications and that the data has been upgraded correctly.
8.1.2 PURPOSE & OBJECTIVES
The objectives of a Test Plan Strategy are as follows:



To define a structured testing approach that ensures nothing is overlooked during testing
To create a plan which provides an orderly method to meet the three main goals of testing:
o That requirements have been met
o Ensure day to day operations function correctly and as expected
o Ensure customizations work correctly and as expected
To provide managers a working document for managing the test process
8.1.3 TYPES OF TESTING
There are three types of system tests that are required for a system upgrade are outlined below
The Testing types are:



Unit testing
System testing
User Acceptance testing
The types of Testing are described as follows:
PAGE | 64
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
8.1.3.1 UNIT TESTING
Unit testing occurs throughout setup, development, (including interfaces and reports) and
modification of the PeopleSoft system. Its purpose is to affirm at the lowest possible level of
data volume and/or variability that the configuration and/or process supports the functional
requirements, runs/performs without error and produces the desired data outputs. Functional
users will test the setup table and security configuration. Unit testing is done by a technical
resource on a modification, conversion, report, or interface that has been developed. This testing
is done as soon as the modification has been completed. Unit testing also occurs throughout the
development of the modification by the technical resource if the modification has multiple steps.
Unit testing is done in a controlled environment in a Development Database where the data is
static and controlled by the technical resource. The Technical Specification for each
modification may include a section describing sample unit tests to be performed for the
modification including testing edits, translations, error conditions and formatting for reports and
interfaces. The functional resource that developed the Functional Specification must approve all
unit test results before the modification is moved from the development environment to a system
testing environment. Unit testing is an iterative process, which is performed until the
modification is correct.
Unit testing will be performed by the SHARE Upgrade project team.
8.1.3.2 SYSTEM & INTEGRATION TESTING
System testing is the functional and technical testing of each major system component, while
integration testing focuses on testing processes between PeopleSoft modules and between
PeopleSoft and other systems. During system testing, the team verifies that the system is stable
and accessible, delivered processes run without error, performance is acceptable and all setup
and transactional data has converted over successfully. Integration testing focuses on the
integration of all functions used in the business processes. Integration can be tested by
sequentially executing functions that are dependent on data created in a prior step. This testing is
performed across all modules. Prior to beginning System/Integration Testing, the individual
parts or system modules must have been exhaustively tested by the during the Unit Testing stage
of program development.
System/Integration testing may require its own environment (databases, tables and data), and it is
generally the joint responsibility of the functional and technical staff.
Functional resources using scripts/scenarios with desired results of all modifications, business
processes, and functionality perform this testing with technical support where required. Each
test script must contain an objective and a desired result. Each test script must be signed off by a
designated functional resource when it is completed and the desired result has been achieved.
Test scripts/scenarios, supporting forms and the role of the Test Coordinator in managing the
System/Integration, User Acceptance and Parallel testing phases will be described in subsequent
sections of this documentation.
System and Integration will be performed by the SHARE Upgrade project team.
PAGE | 65
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
8.1.3.3 USER ACCEPTANCE TESTING
In User Acceptance Testing (UAT), the agency end-users of the system are responsible for
validating the product and new processes. Full functionality and business processes and
procedures should be tested, not just customizations. User Acceptance testing consists of
multiple cycles that allow for both testing of incremental changes from one cycle to the next and
also individual test cases within each cycle. In planning UAT a Test Scenario form is developed
to identify each test case at a high level and in which cycle it is to be tested, a script or multiple
scripts are developed for each scenario with detailed data to be used and expected results. The
Test Coordinator and Functional resources work with the Users to develop the Test Scenarios
and Scripts, and Users will execute each of the tests. If a test fails, a Problem Report will be
created and the Test Coordinator will assign it to the appropriate resource for resolution. User
Acceptance testing, like Unit Testing, is an iterative process that is performed until the system
works as intended. Ideally, a resolution for failed tests will be found and applied within the same
test cycle but the test may be moved into the next cycle if implementation of it will delay moving
forward with testing.
8.1.4 PARTICIPANTS
Different sets of participants will be required for different phases, and participants will take on
different roles at different times. However, the participants can be divided into basic groups
according to the timing of their involvement and training requirement for testing.
Here are the basic testing groups:
 Core Team – Technical
 Core Team – Functional
 Functional Testers
 DBA
 System Administrator
 Testing Coordinator
PAGE | 66
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
8.1.4.1 SHARE UPGRADE TEAM TECHNICAL MEMBERS
SHARE upgrade team technical members are participants who ‘unit test’ their own work on an
ongoing basis. Their role also involves fixing technical “bugs” and errors identified produced by
their own or other’s testing (including those during System/Integration, User Acceptance and
Parallel testing). They are expected to consult informally with core team functional members on
testing difficulties and obtain formal approval signoff from core team functional members before
moving modifications from the development environment into other test environments.
8.1.4.2 SHARE UPGRADE TEAM FUNCTIONAL MEMBERS
Functional members also perform ‘unit tests’ on their own work on an ongoing basis to validate
set-up tables, standard calculations and processing. In preparation for System/Integration and
User Acceptance testing employees are also involved with preparing data for data verification.
Upgrade team functional members are responsible for the identification of test scenarios and
development of correspond test scripts for those scenarios.
For System/Integration testing SHARE upgrade team functional members will be executing the
test scripts and the reporting of test issues encountered. They will consult informally with
upgrade team technical members to resolve difficulties. When problems are resolved, their role
is then performing the re-testing the script to achieve success.
During User Acceptance testing they will assist End Users/Functional Testers in executing test
scripts and recording problems with tests on Problem reports for the Test Coordinator to assign
to the appropriate resource for resolution. Again, they will consult informally with upgrade team
technical members to resolve difficulties. When problems are resolved, their role is then
assisting with re-testing the script to achieve signoff.
8.1.4.3 AGENCY END USERS/FUNCTIONAL TESTERS
Agency End Users/Functional Testers include end users assigned to perform User Acceptance
testing. During UAT, End User/Functional Testers will execute test scripts that cover the full
spectrum of the users’ business processes and procedures identified in the Test Scenario matrix.
With the support of the SHARE Upgrade Functional team they will be responsible for
identifying problems during testing and creating Problem reports.
8.1.5 TESTING PROCEDURES
The approach for testing consists generally of the following steps:
 Assign Testing Coordinator and develop testing infrastructure (schedules, forms...)
 List every program/function/business event that needs to be tested
 Develop guidelines and train staff for preparing test scripts
 Prepare test scripts
 Prepare test environment
 Execute the tests
 Review results
o Analyze expected results
PAGE | 67
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
o
o
o
o

Complete Test Script form with notes on actual results; sign off if acceptable
Complete Problem report, if applicable
Update Test Script Log
If the expected results are unacceptable and result in a change from the original
design and technical specifications, complete a Change Request and submit it to the
Project Manager for review
Re-test and repeat the above steps as required
8.1.6 SYSTEM TEST TEAM
The System/Integration, User Acceptance Test and Parallel Test Teams are comprised of the
following roles:
8.1.6.1 TEST COORDINATOR
 Oversees and coordinates all aspects of the testing process
 Develops all system test forms, templates, and information flows
 Identifies and schedules all project tasks related to the system testing effort
 Builds the detailed test plans for each system testing effort
 Tracks all test scripts with dependence relationships to ensure that they are scheduled and
completed at the appropriate time
 Coordinates user testing activities
 Identifies and tracks all problems encountered during testing and their resolution
 Maintains test success and failure metrics
 Leads daily status meetings with the test teams during UAT and Parallel testing
 Coordinates approvals and sign-off of each testing effort
The Test Coordinator is the “traffic cop” for all system testing activities. The Test Coordinator
must know the status of each test step, where testing stands relative to the test plan, what
outstanding problems have been reported, what changes have been requested, and what needs to
be done next. The Test Coordinator must communicate information in a timely and judicious
manner.
The test plan, like any project upgrade or implementation plan, is the baseline against which
progress is measured and is the primary vehicle for communicating a precise status of testing
activities. The Test Coordinator will provide daily updates and will escalate issues that impact
the overall testing schedule to the Project Manager.
The Test Coordinator will also serve as the central point for submission of problem reports and
change requests related to system testing. Tracking of problem reports and change requests is as
important as tracking progress against the test plan. The Test Coordinator is responsible for
PAGE | 68
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
shepherding problem reports and change requests, ensuring that their impact on system testing is
assessed and resolved in a timely manner.
It is essential that the Test Coordinator responsibilities have the highest priority.
8.1.6.2 SHARE UPGRADE TEAM – FUNCTIONAL AND END USER/FUNCTIONAL TESTERS
 Develops test scripts with expected results
 Tests the online system components, reports and interfaces
 Analyzes and reviews results
 Prepares Problem reports for failed tests
8.1.6.3 SHARE UPGRADE TEAM - TECHNICAL
 Facilitates establishment of test environment including backups and security
 Coordinates transfers of corrected software to test system
 Executes batch runs
8.1.6 TESTING INFRASTRUCTURE
In addition to setting up the Testing Team, the following steps will be taken to establish the rest
of the testing infrastructure and ensure an organized and systematic testing phase:
 Set up a Testing Schedule (time frame and hours)
 Establish Status Reporting Mechanism
 Agree on Testing Deliverables
 Develop Testing Materials/Forms
 Prepare Testing Plans
 Create Testing Environments and data
 Establish testing venue (computers, dedicated workspace)
8.1.7 TEST REQUIREMENTS
Prior to creating any test scripts, the team must identify what needs to be tested and the
acceptable test tolerance levels and/or criteria for testing to be considered a success. Testing will
be organized around business processes, customizations, reports and interfaces. This Test
Scenario matrix will be used to ensure that Test Scripts for each scenario are developed.
 Modules to be used in Production
 Customizations
 What needs to be tested:
o Online (Data entry, Security, Navigation)
o Business Processes
PAGE | 69
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
o Batch (Interfaces, Reports)
o Performance (Online response time, batch duration
8.1.8 CREATING TEST DATA AND WRITING TEST SCRIPTS
A reliable set of test data, called the "test script" is created for testing procedures. The test script
defines the scope of each test by providing program data that is expected to yield a certain result
or group of results. The more detailed the test script, the greater the chances of finding
problems. Test scripts are developed for every process that will be used in production.
Also, test scripts are written to assist testers in the proper set up, execution and validation of test
results. In addition, test scripts are a convenient mechanism for recording comments and signoff for each step in the test plan.
The test results will define which online pages and which reports to look at to verify the results.
The actual data values expected from the successful execution of each test script will be
explicitly documented.
8.1.9 TESTING DATABASE
All tests will be performed in the identified database with necessary test data, as per the agreed
test data scope timeline, which is as close to “real” as possible.
The test team members will request specific records and data required for the identified database
for each major testing cycle. This will provide complete data except for the new elements.
Should any records need updating, the actual entry of the data will be considered part of testing.
8.1.10 CHECKING TEST RESULTS
A timeline indicating the scope of necessary data needed to adequately support testing at each
major testing cycle (System/Integration and UAT) should be created and agreed upon by project
participants and management.
Each tester will be responsible for checking the results of their test by checking the online pages
and reports to verify the data values are what were expected. The user will then sign and date the
test script noting that the desired result was obtained. In the event of a test failing to provide the
expected result(s) the tester will complete a Problem Report for the Test Coordinator to have
resolved.
8.1.11 SPECIAL SECURITY CONSIDERATIONS
Should there be a concern regarding the use of real data for certain phases of testing, special
procedures will be created to “scramble” or change uniquely identifiable data. Examples of such
PAGE | 70
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
data may include employee/dependent names, social security numbers, or compensation
amounts.
8.1.12 SPECIAL FORMS AND TOOLS
Development of special forms for documenting test conditions, expected results, problem
identification and resolutions are to be implemented to ensure quality assurance testing.
Test Script
The tester completes the Test Script in order to define the steps required to execute the test and to
indicate the results they hope to achieve in a specific test. The test information is completed
prior to processing the tests.
A status section is used to indicate the results they actually achieved. The information is entered
after the output from the process is reviewed.
Problem Report
A Problem Report is used to define perceived errors, which occur during the testing process. It
tracks problems through the test process to their final resolution and user acceptance of the
results. This form is completed by the tester and submitted to the Test Coordinator for
disposition; e.g., discussion with the Project Manager or appropriate Functional team member
and submission to the technical staff or functional staff for resolution, as required.
Test Log
A Test Log provides a mechanism for tracking test scripts through testing. Test script items are
listed on the logs prior to testing. They are used as a record to ensure that all transactions and
special processes have been tested and have been processed successfully before each test phase is
approved. The Test Log is also the source of metrics for daily status meetings.
Problem Log
A Problem Log provides the team with a list of those problems that have been identified by the
testing team. The log is used to track any Problem Reports through submission to final
resolution. This is to ensure that any identified problems have been assigned for resolution and
have come to successful resolution. The log consists of the date the problem was submitted, who
has been assigned the task of resolving the problem, the final disposition and associated date. As
Problem Reports are resolved the Test Coordinator will submit the test for re-testing.
8.1.13 TESTING ASSUMPTIONS
 The Test environment is stable and is as close to Production as possible.
 No changes will be made to the Test environment while a test cycle is in progress, unless the
change is necessary to move the testing forward.
 All system problems will be resolved as if they were in production.
 All security roles and permission lists are in place.
PAGE | 71
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT







Testing of interfaces will include sending files to the external vendor(s).
All scripts are complete and entered into testing database including prerequisite information.
All completed customizations are in place.
Test scripts will be assigned among the testers associated with the project team. Testers will
allow an adequate amount of time in their work schedule to perform the tests required.
During testing other databases are available for development and reworking of ‘issues’.
All testers will have sufficient training in PeopleSoft/EBS navigation and functionality to
perform the tests with minimum to moderate supervision.
All testers will have some knowledge of the core business process being tested.
9. 0 REPORTING & ANALYSIS
10. 0 PROJECT CLOSE
Project Close will always consist of administrative project activities and possibly contractual
project activities and an external vendor is employed. Completing both sets of activities is a
mandatory step in the project life cycle. Administrative activities complete the internal needs for
the Agency/Unit that is responsible for managing the project, such as lessons learned, recording
the last hours against the project, and providing transition for the staff to other assignments.
Contractual activities meet the contractual needs, such as executing a procurement audit and
formal acceptance of the project work products.
10.1 ADMINISTRATIVE CLOSE
Administrative Close occurs at both the end of phase and end of project. This closure consists of
verification that objectives and deliverables were met. Acceptance is formalized and phase
activities are administratively closed out. Administrative closure occurs on a “by-phase” basis in
accordance with the WBS and should not be delayed to project end. At that point, the burden of
closing is too great and audits inaccurate. The specific project close activities for a given project
are contingent on the project’s complexity and size. Project managers should work with the
project’s project management consultant to tailored Project Close procedures to compliment the
project’s objectives
PAGE | 72
PROJECT MANAGEMENT PLAN FOR SHARE FINANCIALS UPGRADE PROJECT
10.2 CONTRACT CLOSE
Contract close is similar to administrative close in that it involves product and process
verification for contract close.
ATTACHMENTS
PAGE | 73