SHARE ENTERPRISE LEARNING
MANAGEMENT PILOT PROJECT
P R O JE C T M A N A GEM E N T PLA N
(PMP)
EXECUTIVE SPONSOR – CASSANDRA HAYNE
BUSINESS OWNER – CLAUDIA BLAINE
PROJECT MANAGER – MICHAEL CHMURA
EXECUTIVE SPONSOR – CASSANDRA HAYNE
ORIGINAL PLAN DATE: NOVEMBER 20, 2014
REVISION DATE: DECEMBER 3, 2014
REVISION 2.0
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
REVISION HISTORY................................................................................................................................................ IV
PREPARING THE PROJECT MANAGEMENT PLAN .................................................................................................... V
ABOUT THIS DOCUMENT ....................................................................................................................................... V
PROJECT OVERSIGHT PROCESS MEMORANDUM – DOIT, OCTOBER 2014 ................................................................................ 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 ..............................................................................................................6
2.2.2 Project Governance .....................................................................................................................................7
2.2.3 the organizational structure – Org Chart ....................................................................................................9
2.2.4 Project Decision/Issue Escalation Process ...................................................................................................9
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 .............................................................................................................................................. 19
5.1 WORK BREAKDOWN STRUCTURE (WBS) ....................................................................................................................19
5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE ................................................................................................................22
5.4 PROJECT TEAM ......................................................................................................................................................23
5.4.1 Project Team Roles and Responsibilities ...................................................................................................23
5.6 PROJECT LOGISTICS ...........................................................................................................................................26
5.6.1 Project Facilities ........................................................................................................................................26
6.0 PROJECT MANAGEMENT AND CONTROLS ...................................................................................................... 27
6.1 RISK AND ISSUE MANAGEMENT.................................................................................................................................27
6.1.1 Risk Management .....................................................................................................................................27
REVISION: 0.0
DOIT-PMO-TEM-020
i OF vi
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
6.1.2 Project Risk Identification ..........................................................................................................................27
6.1.3 Project Risk Analysis ..................................................................................................................................28
6.1.4 Project Risk Response Strategies ...............................................................................................................29
6.1.5 Project Risk Roles & Responsibilities .........................................................................................................29
6.1.6 Project Risk Tracking Approach .................................................................................................................30
6.1.7 ISSUE MANAGEMENT ................................................................................................................................31
6.3 SCOPE MANAGEMENT PLAN ....................................................................................................................................33
6.4 PROJECT BUDGET MANAGEMENT..............................................................................................................................34
6.5 INDEPENDENT VERIFICATION &VALIDATION - QUALITY REVIEWS .....................................................................................34
6.5.1 Objectives ..................................................................................................................................................34
6.5.2 Project Quality Review Process .................................................................................................................35
6.5.3 Agency/Customer Satisfaction ..................................................................................................................38
6.5.2 READINESS ASSESMENT & SYSTEM ACCEPTANCE PROCESS......................................................................39
6.7 PROJECT REPOSITORY .............................................................................................................................................40
6.7.1 Project Management Documents .............................................................................................................40
6.7.2 Change Management & Technical Management .....................................................................................40
6.7.3 Phases One Through Five Work Products ..................................................................................................41
6.7.4 File Naming Convention ............................................................................................................................41
7. 0 CHANGE MANAGEMENT PLAN ...................................................................................................................... 41
7.1 CHANGE MANAGEMENT PLAN..................................................................................................................................41
7.1.1 Leadership .................................................................................................................................................41
7.1.2 Communications........................................................................................................................................42
7.1.3 Learning Strategies ...................................................................................................................................42
7.1.4 Terms .........................................................................................................................................................43
7.1.5 Change Management Strategy .................................................................................................................43
7.1.6 Stakeholder Expectations ..........................................................................................................................44
7.1.7 Role and Responsibility Changes ...............................................................................................................44
7.4.8 Change Management in the Project Lifecycle ...........................................................................................44
7.1.9 Change Management Team – Roles & Responsibilities ............................................................................47
7.2 COMMUNICATION PLAN ..........................................................................................................................................48
7.2.1 Communication Purpose & Objectives ......................................................................................................48
7.2.2 Communication Approach .........................................................................................................................49
7.2.3 Communication Success Factors ...............................................................................................................49
6.5.1 Communication Roles ................................................................................................................................49
7.2.4 Communication Process ............................................................................................................................50
7.2.5 Target Audiences .......................................................................................................................................51
7.2.6 Vehicles for Communication ......................................................................................................................52
7.2.7 Topics for Communication .........................................................................................................................53
7.2.8 Monitoring Communication Execution (Communication Matrix) .............................................................53
7.2.9 Status Meetings ........................................................................................................................................53
7.2.10 Project Status Reports .............................................................................................................................54
7.3 CHANGE LIAISON NETWORK .....................................................................................................................................54
7.3.1 Introduction & Objectives ..........................................................................................................................55
7.3.2 What is a Change Agent Network .............................................................................................................55
7.3.3 Why Institute a Change Network ..............................................................................................................55
7.3.4 Who Participates in a Change Agent Network ..........................................................................................56
7.3.5 How Will the Change Agent Network Work ..............................................................................................56
7.4 KNOWLEDGE TRANSFER PLAN...................................................................................................................................57
7.4.1 Overview ...................................................................................................................................................57
7.4.2 Project Team Structure ..............................................................................................................................58
7.4.3 Team Meetings..........................................................................................................................................58
REVISION: 0.0
DOIT-PMO-TEM-020
ii OF vi
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
7.4.4 Documentation Strategy & Guidelines ......................................................................................................58
7.4.5 Change Management and Communication Plans .....................................................................................58
7.4.6 Delta Analysis ............................................................................................................................................58
7.4.7 Design Reviews ..........................................................................................................................................59
7.4.8 Testing .......................................................................................................................................................59
7.4.9 Training .....................................................................................................................................................59
8. 0 TESTING ........................................................................................................................................................ 60
8.1 TESTING STRATEGY .................................................................................................................................................60
8.1.1 Overview ...................................................................................................................................................60
8.1.2 Purpose & Objectives ................................................................................................................................60
8.1.3 Types of Testing .........................................................................................................................................60
8.1.3.1 Unit Testing ............................................................................................................................................61
8.1.3.2 System & Integration Testing .................................................................................................................61
8.1.3.3 User Acceptance Testing ........................................................................................................................62
8.1.4 Participants ...............................................................................................................................................62
8.1.4.1 SHARE Upgrade Team Technical Members ............................................................................................63
8.1.4.2 SHARE Upgrade Team Functional Members ..........................................................................................63
8.1.4.3 Agency End Users/Functional Testers ....................................................................................................63
8.1.5 Testing Procedures ....................................................................................................................................63
8.1.6 System Test Team......................................................................................................................................64
8.1.6.1 Test Coordinator .....................................................................................................................................64
8.1.6.2 SHARE Upgrade Team – Functional and End User/Functional Testers ..................................................65
8.1.6.3 SHARE Upgrade Team - Technical ..........................................................................................................65
8.1.6 Testing Infrastructure ................................................................................................................................65
8.1.7 Test Requirements .....................................................................................................................................65
8.1.8 Creating Test Data and Writing Test Scripts .............................................................................................66
8.1.9 Testing Database.......................................................................................................................................66
8.1.10 Checking Test Results ..............................................................................................................................66
8.1.11 Special Security Considerations ...............................................................................................................66
8.1.12 Special Forms and Tools ..........................................................................................................................67
8.1.13 Testing Assumptions ...............................................................................................................................67
9. 0 REPORTING & ANALYSIS................................................................................................................................ 68
10. 0 PROJECT CLOSE ........................................................................................................................................... 68
10.1 Administrative Close ...................................................................................................................................68
10.2 Contract Close ............................................................................................................................................68
REVISION: 0.0
DOIT-PMO-TEM-020
iii OF vi
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
REVISION HISTORY
REVISION NUMBER
DATE
COMMENT
1.0
November 20, 2014
Creation
2.0
December 3, 2014
Revision for PCC
REVISION: 0.0
DOIT-PMO-TEM-020
iv OF vi
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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, October 2014
“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: 0.0
DOIT-PMO-TEM-020
v OF vi
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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
The State of New Mexico (SONM) owns the licensing for the PeopleSoft Enterprise
Learning Management (ELM) product suite. Multiple agencies in the SONM, including but
not limited to SPO, DOT, HSD, MVD and GSD, have identified a business need for an
enterprise level solution to managing employee learning, which is integrated with the
existing SHARE HCM employee records and provides for learning history which follows an
employee throughout their career with the State.
DOT is spending approximately $70,000 per year for a learning management package
(GYRUS AIM) which does not meet their expanding business requirements, with annual
renewal due in June of each year. As a result, DOT has agreed to pilot an implementation
of ELM as a full replacement solution for GYRUS AIM.
Implementation of ELM will not only satisfy the global requirements for learning
management and reduce costs for DOT; it will increase the ROI on existing PeopleSoft
licenses.
1.2 FUNDING AND SOURCES
SOURCE
AMOUNT
ASSOCIATED
RESTRICTIONS
APPROVERS
DOT
$200,000
NA
TOM CHURCH
1.3 CONSTRAINTS
Constraints are factors that restrict the project by scope, resource, or schedule.
NUMBER
DESCRIPTION
1
DOT staff and funding is the cornerstone of the pilot project.
2
The project will have to be “Live” prior to June 1, 2015.
3
Concurrence with the coalition of multiple state agencies that the
configuration meets global business requirements.
PAGE | 1
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
NUMBER
DESCRIPTION
4
Resources – SHARE team is small and may require reliance on contracted
resources to implement the product suite.
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
PEOPLESOFT RELEASE 9.2 IS NEW TECHNOLOGY FOR
THE STATE OF NEW MEXICO.
M
2
CONSULTANT FUNDING AND AVAILABILITY
M
3
TIMELY RESPONSE FROM STAKEHOLDERS
M
4
TIMELY DECISION MAKING WITH ADVISORY PANEL
M
5
TIMELY CONTRACTING PROCESS
E
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.
4
A description of the project has been developed.
PAGE | 2
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
NUMBER
DESCRIPTION
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.
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.
HCM Data Integrity
Description – Existing data
in PeopleSoft HCM which
is utilized to build ELM
must be complete and
accurate.
Probability MEDIUM
Impact MEDIUM
Mitigation Strategy: Early identification of key fields, with follow-up
to update as required.
Contingency Plan: Allow for manual update of employee profile
information that is not available via HCM data values
Project Scope Creep
Description – There is the
potential that discovery of
ELM features will cause
press for inclusion of more
than foundation
functionality in PHASE I.
PAGE | 3
Probability – MEDIUM
Impact - HIGH
Mitigation Strategy: Define initial scope with specific boundaries and
adhere to those boundaries. 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.
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
New Technology for State of New Mexico
Description – The State of
New Mexico does not have
PeopleSoft 9.2 deployed.
Bringing up ELM as a
more current release is a
learning curve for DoIT
staff.
Probability - MEDIUM
Impact - HIGH
Resource Commitment & Allocation
Description – Will the
required resources be
available to work on the
project
Probability - MEDIUM
Impact - HIGH
Mitigation Strategy: Implemented a strategy of early and thorough
project planning.
Contingency Plan: Rely more on contracted services.
Project Budget
Description – Is the project
budget adequate for the
upgrade.
Probability - MEDIUM
Impact - HIGH
Mitigation Strategy: Clear definition and limit of contractor scope
early on.
Contingency Plan: If additional assistance is required, agree with
stakeholders to have SONM resources assume larger role or acquire
additional funding for increased consulting resources.
Other SHARE Projects
Description – Other
projects running parallel
that may potentially impact
the Project.
PAGE | 4
Probability - MEDIUM
Impact - MEDIUM
Mitigation Strategy: Timeline allows for consideration of conflicting
priorities.
Contingency Plan: De-prioritize other efforts and possibly postpone
until after the upgrade is complete.
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
2.0 PROJECT AUTHORITY AND ORGANIZATIONAL
STRUCTURE
The Project Organization describes the roles and responsibilities of the project team. It also identifies the other
organizational groups that are part of the project and graphically depicts the hierarchical configuration of those
groups. It exists to clarify interaction with the project team.
2.1 STAKEHOLDERS
List all of the major stakeholders in this project.. Stakeholders are individuals and organizations that are actively
involved in the project, or whose interests may be positively or negatively affected as a result of project execution or
project completion. They may also exert influence over the project and its results. This list of stakeholders also
represents the member of the SHARE Advisory Panel which is further explained in the Project Governance section
of the PMP.
NAME
STAKE IN PROJECT
ORGANIZATION
TITLE
Cassandra Hayne
Primary Agency
DoIT
SHARE
Deputy
Director
Michael Chmura
Primary Agency
DoIT
Project
Manager,
Consultant
Pat Byrd
Primary Agency
DoIT
Business
Analyst
Claudia Blaine
Primary Agency – Business Owner
DOT
Training
Director
Yvonne Encinias
Primary Agency – Agency SHARE
Support
DOT
IT Apps
Dev II
Gilbert Archuleta
Primary Agency
DOT
HR
Director
Larry Viarreal
Primary Agency
DOT
CFO
Julia Lanham
Observing Agency
SPO
Vanessa Readwin
Observing Agency
SPO
PAGE | 5
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
NAME
STAKE IN PROJECT
ORGANIZATION
Cheryl Thompson
Observing Agency
HSD
Kimberly
Hamerdinger
Observing Agency
MVD
Zela Cox
Observing Agency
GSD
TITLE
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.
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.
PAGE | 6
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
PARTICIPANTS
ROLE
SHARE Deputy Director
The SHARE Deputy Director will provide guidance to the
Project Mangers on policy, functional and technical issues.
The SHARE Deputy Director will also build consensus
between the Project Managers, Project Team before
escalating issues to the State CIO/Sponsor. The SHARE
Deputy Director 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 Deputy Director and Project Team to complete the
project schedule as well as coordinates the overall project
delivery and management. Level 2 decisions in the chart
2.2.3.
Project Team
The Project Teams Leads and the Subject Matter Expert's
(SME’s) will interact regularly. The Project Team Leads will
develop recommendations for business processes and will
communicate their decisions to the Project Manager.
General Stakeholders
The State has several other stakeholder groups including
DOT, SPO, HSD, MVD and GSD. These stakeholders are
expected to have been kept abreast of the project as
appropriate. How and when communications will be sent
will be part of the Communication Plan. Level 1 decision 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.
PAGE | 7
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 Deputy Director: 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 ENTERPRISE LEARNING MANAGEMENT PILOT
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 Deputy Director
Level 3 Decisions
Share Systems Management
SHARE Deputy
Director
SHARE Project
Manager
DOT HR Director
Contractor Project
Manager
Level 2 Decisions
Project Management
DOT SHARE Support
and DOT Training
Manager
SHARE & Contractor
Technical Leads
DOT Functional Consultant
SHARE & Contractor
Change Management
Leads
Level 1 Decisions
Project Team
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.
PAGE | 9
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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
DESCRIPTION
Configure ELM foundation tables for courses, classes, and learners.
Bus. Objective 2
Load SHARE HCM employee information into ELM.
Bus. Objective 3
Prepare the SHARE ELM environment and infrastructure for the
State agencies to enter course and learner information.
Enter data into the ELM tables for courses, classes, schedules, and
learners and test the features and functions.
Enroll learners in classes, establish learning plans and learner
history. Test features and functions.
Engaging additional agency participation to ensure that the
implementation will meet the state-wide business needs.
Convert existing training history information into ELM.
Bus. Objective 4
Bus. Objective 5
Bus. Objective 6
Bus. Objective 7
Bus. Objective 8
PAGE | 10
Use the development model to build a production ELM instance for
state-wide use.
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
3.1.2 TECHNICAL OBJECTIVES
NUMBER
Tech. Objective 1
Tech. Objective 2
Tech. Objective 3
Tech. Objective 4
DESCRIPTION
Build a development ELM environment in the latest release.
Establish the linkage between SHARE HCM and ELM for
synchronizing the employee data.
Establish test migration environments for ELM, including
Development, Test and Quality Assurance.
Establish a production ELM environment.
Tech. Objective 5
Establish a training database and training security profiles.
Tech. Objective 6
Provide the user community with the training and knowledge
transfer necessary to perform their jobs.
Develop and implement security schema.
Tech. Objective 7
Tech. Objective 8
Tech. Objective 9
Tech. Objective 10
Tech. Objective 11
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 ELM Pilot project includes the following application products:
PRODUCT
PeopleSoft Enterprise Learning Management
(ELM)
PAGE | 11
MODULES
 Courses
 Learners
 Classes
 Scheduling
 Learning History
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
3.3 PROJECT EXCLUSIONS
This project will not configure ELM features not considered foundation. The primary objective
of the Pilot is to replace GYRUS AIM, while creating a foundation that can be utilized by
additional state agencies. Examples of features not to be considered are:

The product is able to manage external learners. This feature is not a DOT business
requirement.

The product is capable of interfacing with external software such as Blackboard. This
feature is not a high priority DOT business requirement.
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

Change Management

Communications

Risk & Issue Management
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
Phase
Deliverables
Description
Phase 1- Plan & Discover
Kickoff Meeting
Summarizes team structure,
roles and responsibilities,
scope, timeline, and
methodology
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.
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.
PAGE | 13
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
4.1.2 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS
DELIVERABLE
NUMBER
DELIVERABLE
APPROVERS (WHO
CAN APPROVE)
PRJ-DEL-001
Project Management Plan
Cassandra Hayne
PRJ-DEL-002
Kickoff Meeting
Cassandra Hayne
PRJ-DEL-004
Change Management Plan
Cassandra Hayne
PRJ-DEL-005
Communication Plan
Cassandra Hayne
PRJ-DEL-006
High Level Project Schedule
Cassandra Hayne
PRJ-DEL-006
Technical Charter
Cassandra Hayne
PRJ-DEL-007
Detailed Project Schedule &
Assumptions
Cassandra Hayne
PRJ-DEL-008
User Training Plan
Cassandra Hayne
PRJ-DEL-009
Test Plan
Cassandra Hayne
PRJ-DEL-010
Cutover Plan
Cassandra Hayne
PRJ-DEL-011
Readiness Assessment
Cassandra Hayne
DATE
APPROVED
4.2 PRODUCT LIFE CYCLE
4.2.1 PRODUCT LIFE CYCLE DELIVERABLES
Phase
Key Deliverables
Description
Phase 2 – Analyze & Design
System Design
The System & Configuration
Design document will contain
the recommended system
configuration change interface
inventory and changes, and
report inventory.
PAGE | 14
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
Phase
Key Deliverables
Description
Phase 2 – Analyze & Design
Security Plan & Matrix
The Security Plan & Matrix
will outline the recommended
Security configuration
changes to apply to the
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 ELM 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
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.
PAGE | 15
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
Phase
Key Deliverables
Description
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
and responsibility.
Phase 5 – Deployment
Cutover to Production
Execution of the Cutover Plan
placing the upgraded
environment into production.
PAGE | 16
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
Phase
Key Deliverables
Description
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
ELM will be deployed based on the existing SHARE architecture.
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
Cassandra Hayne
PRD-DEL-002
Security Plan & Matrix
Cassandra Hayne
PRD-DEL-004
Configuration Document
Cassandra Hayne
PRD-DEL-005
Updated Functional Specifications
Cassandra Hayne
PRD-DEL-006
Test Plan Matrices, Scenarios and
Scripts
Cassandra Hayne
PRD-DEL-007
Technical Specs
Cassandra Hayne
PRD-DEL-008
Training Materials
Cassandra Hayne
PRD-DEL-009
Code/Unit Test
Cassandra Hayne
PRD-DEL-010
Completed System/Integration
Testing
Cassandra Hayne
PRD-DEL-011
Completed Acceptance Testing
Cassandra Hayne
PRD-DEL-012
Training Delivery
Cassandra Hayne
PRD-DEL-013
Cutover Plan
Cassandra Hayne
PRD-DEL-014
Cutover to Production
Cassandra Hayne
PAGE | 17
DATE
APPROVED
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
DELIVERABLE
NUMBER
DELIVERABLE
APPROVERS (WHO
CAN APPROVE)
PRD-DEL-015
Production Support
Cassandra Hayne
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.
PAGE | 18
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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
DEFINITION/OBJECTIVE
DELIVERABLE/MILESTONE


Project Management Plan
PHASE 1 – PLAN & DISCOVER
1.01
Project Planning






1.02
Technical
Preparation

1.03
Install &
Configure


PAGE | 19
Develop project plan
Work with SHARE
management and ELM
Advisory Committee to
confirm and evaluate existing
strategies and plans for:
Managing project scope
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 a copy of current
release DEMO database, and
PS_HOME code line.
Build a PeopleSoft ELM
release 9.2 demo environment
and applies any patches and
fixes that are required for
installation and/or upgrade
Verify/Certify the install
Pre-Installation Complete
Certified PeopleSoft Install
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
PHASE/TASKS
DEFINITION/OBJECTIVE
DELIVERABLE/MILESTONE
Load the PS-delivered
product, which contains the
menus and pages required for
ELM, along with all
interfaces, search engines and
technical linkages required for
the product suite.
Establish system defaults and
rules which will govern the
system features and
functionality
Review and understand the
business processes that will be
required in support of ELM.
Configuration Technical
Setup
Determine the application of
Learning Environments,
Learner Groups and the
categories which will govern
the structure for learners,
courses and class events.
Define the standards and
naming conventions
Create a TST environment
based on the Design
Perform Install Verification
Test
ELM Foundation Design
Functional team validates
setup tables and transaction
tables for completeness and
accuracy
Apply functional setups in the
test environment
Test Environment Validated
Create learner and course
tables and use ELM features
to enroll students, process
deliveries of courses and
evaluate learning histories
Retrofit and modify security.
Assist in troubleshooting any
security related issues in the
Test Database
PHASE 2 – ANALYZE & DESIGN
2.01
Configuration
Technical Setup

2.02
Configuration
Functional
Setup

2.03
Assess Business
Processes

2.04
Design the ELM
structure


2.06
Create Test
Environment


Configuration Functional
Setup
Business Process Flows
Test Environment Created
PHASE 3 – CONFIGURE & DEVELOP
3.01
Data Validation
and Testing

3.02
Functional
Setup in Test
Environment
Database Build

Update Security
Setup

3.03
3.04
PAGE | 20

Configured Test Environment
Security Schema
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
PHASE/TASKS
DEFINITION/OBJECTIVE
3.05
Data Validation
and Testing

3.06
Readiness
Assessment
Checklist

DELIVERABLE/MILESTONE
environment
Validated Test System
Validate setup tables and
transaction tables for
completeness and accuracy
and confirm that data is
successfully upgraded.
Go Live Criteria Defined
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.
PHASE 4 – TEST & TRAIN
4.01
Unit & System
Testing


4.02
Training


4.03
System &
Integration
Testing


4.04
Go-live
Checklist

4.05
Acceptance
Testing

PAGE | 21
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.
Develop and deliver test team
training
Utilize feedback from team
training to finalize community
training and deliver.
Conduct system testing,
integration testing,
troubleshooting, and issue
resolution
Evaluate test results and
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
System & Integration Testing
Cutover Plan
User Acceptance Testing
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
PHASE/TASKS
DEFINITION/OBJECTIVE
DELIVERABLE/MILESTONE
acceptance and parallel tests
in TST
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.
Go Live Assessment
Cutover to Production
Production Ready
Environment
System Live
Postproduction Support
5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE
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.
1
October-14
Planning / Requirements
Infrastructure
Design
Configuration
Conversion Development
Report Development
SIT
UAT
Conversion / Cut-over
Support / Closeout
PAGE | 22
2
3
November-14 December-14
4
January-15
5
February-15
6
March-15
7
April-15
8
May-15
9
June-15
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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.
Michael Chmura DoIT
NA
Functional
Analyst 1
Functional Analysts are the primary
Pat Byrd - DoIT
business process experts who are
responsible for leading the design and
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.
PAGE | 23
HCM/ELM
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
ROLE
RESPONSIBILITY
NAME
Business Lead
Agency business lead with expertise and
experience with establishment, delivery
and management of employee training.
Claudia Blaine - DOT
ELM
Consultant
Contractor with expertise and experience
in ELM deployment. The Consultant
will oversee and advise State of New
Mexico project team with regard to ELM
features and functions; as well as system
design and configuration decisions.
Ingrid Brown
ELM
Advisory Panel
Agency training liaisons 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 experts will fill the role of the
End User/Functional tester for User
Acceptance Testing. An optional role of
Agency experts is to become end-user
trainers.
Julia Lanham – SPO
Cheryl Thompson –
HSD
Zela Cox – GSD
All
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.
Patti Ponder
DoIT Technical
Support
PAGE | 24
FUNCTIONAL
AREA
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
ROLE
RESPONSIBILITY
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
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
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.
Diana Pena
DoIT Security
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.
Michael Chmura DoIT
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
PAGE | 25
NAME
FUNCTIONAL
AREA
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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
Co-located team space for the core project team. Preferably a
working desk with Virtual Machines & access per on-site
resource.
Conference Rooms
At least one shared 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.
PAGE | 26
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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:
"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:
PAGE | 27
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT



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:
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%
PAGE | 28
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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.

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


PAGE | 29
Schedules and facilitates planning meetings to develop
the Risk Management Plan
Schedules and facilitates Risk Identification sessions to
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
RESOURCE ROLES AND RESPONSIBILITIES





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
Project Team






Participates in the Risk Management Planning
Participates in the Risk Identification process
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
Project Sponsor, Advisory Panel,
Key Stakeholders


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
PAGE | 30
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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.
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.
PAGE | 31
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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.
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.
PAGE | 32
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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.
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.
PAGE | 33
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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.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 SHARE
manager who has knowledgeable in project management methodology and procedures will
conduct Independent Verification & Validation (IV&V).
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.
PAGE | 34
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
6.5.2 PROJECT QUALITY REVIEW PROCESS
PROJECT QUALITY
REVIEW PROCESS
STEP
1. Schedule Review
2. Assign Reviewer
3. Prepare for Review
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
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
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.
PAGE | 35
RESPONSIBILITY
Project Manager
SHARE Systems Manager
Project Reviewer
Project Manager
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
PROJECT QUALITY
REVIEW PROCESS
STEP
4. Determine interviewees
5. Schedule interviews
PAGE | 36
DESCRIPTION
 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)
 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 Reviewer
Project Manager
Project Manager
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 37
 Prepare Project Quality Review
Reports
 Review draft main report with
Project owners Finalize Project
Quality Review Reports
Project Reviewer
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 38
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 ELM implementation 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 | 39
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 40
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 41
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 42
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 43
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 44
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 45
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT

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 | 46
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 47
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 ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 48
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 49
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 50
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 51
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT



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 | 52
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 53
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 54
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 55
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT


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 | 56
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 57
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 58
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT






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 | 59
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 60
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 61
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 62
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 63
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 64
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 65
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 66
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT
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 | 67
PROJECT MANAGEMENT PLAN FOR SHARE ENTERPRISE LEARNING MANAGEMENT PILOT







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
The project management team will report on budget, schedule and resource utilization.
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
10.2 CONTRACT CLOSE
Contract close is similar to administrative close in that it involves product and process
verification for contract close.
PAGE | 68