Project Plan
Project Name:
Shared Financial System (SFS)
8.8 Upgrade Project
Disclaimer
This example is based on a real project. However, this version is changed
to conform to the Project Plan components as described in the DoIT
Project Management Framework. This example is not a true
representation of the Project Plan for this project.
Prepared By: Project Manager
Title: Project Manager
Date: mm/dd/yy
Project Plan Approval Signatures
Project Name: Shared
Financial System (SFS) 8.8 Upgrade Project
Project Manager
_______________________________________
(Signature)
__________________
(Date)
Name:
Position:
Organization:
Project Sponsor
_______________________________________
(Signature)
__________________
(Date)
Name:
Position:
Organization:
Project Customer 1
_______________________________________
(Signature)
__________________
(Date)
Name:
Position:
Organization:
Project Customer 2
_______________________________________
(Signature)
__________________
(Date)
Name:
Position:
Organization:
mm/dd/yy
Example Project Plan
Page i
Document Change Control
The following is the document control for revisions to this document.
Version
Number
Date of
Issue
Author(s)
Brief Description of Change
Version 1.0
Version 1.1
mm/dd/yy
mm/dd/yy
Project Manager
Project Manager
Initial version for review and comment
Change to critical assumptions, added
status report template, changes to
leadership names
Definition
The following are definitions of terms, abbreviations and acronyms used in this document.
Term
Definition
CBO
CIO
DoIT
SFS
SFSUCG
Chief Business Officer
Chief Information Officer
Division of Information Technology
Shared Financial Systems
mm/dd/yy
SFS Upgrade Core Group
Example Project Plan
Page ii
Table of Contents
1. PROJECT PLAN OVERVIEW AND CRITICAL ASSUMPTIONS ................................................... 1
2. PROJECT WORK PLANS .................................................................................................................... 3
2.1 WORK BREAKDOWN STRUCTURE ...................................................................................................... 3
2.2 STAFFING PLAN .................................................................................................................................. 3
2.3 PROJECT SCHEDULE .......................................................................................................................... 4
2.4 PROJECT BUDGET .............................................................................................................................. 5
3. PROJECT CONTROL PLANS ............................................................................................................. 6
3.1 COMMUNICATIONS PLAN .................................................................................................................... 6
3.2 QUALITY M ANAGEMENT PLAN ........................................................................................................... 6
3.3 ISSUE MANAGEMENT PLAN ................................................................................................................ 6
3.4 RISK M ANAGEMENT PLAN .................................................................................................................. 8
3.5 PROCUREMENT PLAN ......................................................................................................................... 8
APPENDIXES .............................................................................................................................................. 9
APPENDIX A – WORK BREAKDOWN STRUCTURE .................................................................................... 9
APPENDIX B – STAFFING PLAN ...............................................................................................................10
APPENDIX C – BASELINE MILESTONE CHART ........................................................................................13
APPENDIX D – BASELINE PROJECT SCHEDULE ......................................................................................14
APPENDIX E – SFS UPGRADE COMMUNICATIONS PLAN .......................................................................14
APPENDIX F – SFS UPGRADE PROJECT ISSUE LOG..............................................................................14
mm/dd/yy
Example Project Plan
Page iii
1. Project Plan Overview and Critical Assumptions
The purpose of the SFS Upgrade Project Management Plan is to provide an understanding of
how the project plan for the SFS 8.8 Upgrade was developed, how the project will be executed
and how performance to plan will be monitored.
Project Phases
The SFS 8.8 Upgrade Project was developed by segmenting the project into four phases. The
phases are described below:
-
Fit / Gap Verification Phase
This phase involves assessing the capabilities of PeopleSoft Version 8.8 in comparison
to the current business practices used by the sites with Version 7.5 of the software. This
verification of the software’s functionality is achieved through execution of test scripts for
each module. The overarching goal of the SFS Upgrade project is to minimize
customizations to the software and to leverage the delivered functionality.
It is also during this phase that the strategies and management approaches for the
project will be defined, reviewed and approved.
-
Realization Phase
In this phase of the project the PeopleSoft Version 8.8 system is transformed to operate
for the business processes of the SFS user community. This realization of the software’s
potential is achieved by getting the interfaces, bolt-ons and limited customizations to
perform as well as they do in the current software environment.
-
Final Preparation Phase
In the Final Preparation Phase the system is readied for use in a production environment.
Changes to the current, production system are no longer allowed and dual entry of many
activities must take place in preparation for this final move to the new system.
-
Post Go-Live and Support
During this phase the SFS Upgrade Core Group and associated operations staff monitor
the system and address any issues or concerns raised by the user community. A post
project review of the upgrade project is conducted to capture lessons learned.
Critical Assumptions
The project plan was developed based upon certain key assumptions. Any change to these
assumptions may impact the project schedule, the project scope and/or the project quality.
-
The implementation date for the SFS 8.8 Upgrade is mm/dd/yy. The selection of this
date is critical for two reasons. First, in order to perform the upgrade a span of several (to
be defined in more detail later) days is required for the system to be down. A poll of the
sites / campuses indicated that mm/dd/yy was the earliest and most preferred date for the
upgrade to occur. Second, the selection of an implementation date implies that the
project schedule must be planned backward from that point in time. The components that
factor into the development of a project plan are: scope, schedule, quality and resources.
Therefore, by defining the schedule for the upgrade the scope, quality and resources
must be adjusted accordingly to achieve that date.
-
The SFS 8.8 Upgrade is the first priority project for SFS after fiscal year end
readiness. It is imperative that the SFS Upgrade be considered a priority project in order
to achieve the scheduled upgrade date. This means that no other projects can be
introduced which require the same resources, from this point forward, without negatively
impacting the schedule.
mm/dd/yy
Project Plan Example
Page 1
-
Customizations of the PeopleSoft software will be kept to a minimum. All existing
modifications will be scrutinized by the SFS Upgrade Core Group to determine if the
functionality delivered within the Version 8.8 software mitigates the need for the
customization. All new customizations must be documented, justified and presented to
the SFS Upgrade Project Manager for approval. Any customization in excess of twenty
hours of effort must be presented with a business case to the Executive Advisory Group.
-
There will be no new interfaces, into or out of SFS, as part of the upgrade project.
All existing inbound and outbound interfaces to SFS are included in scope. No
accommodations to the schedule have been made for any new interfaces. Any new
interface must be documented and the business case presented to the Executive
Advisory Group.
-
All SFS Upgrade Core Group members allocated to the upgrade project must
remain allocated at the planned level. Any changes to resources either through attrition
or reassignment to other projects will impact the SFS Upgrade project negatively.
mm/dd/yy
Project Plan Example
Page 2
2. Project Work Plans
2.1 Work Breakdown Structure
The work breakdown structure, including the project’s tasks providing a framework for
organizing and managing the work of the project, is included in Appendix A.
2.2 Staffing Plan
The staffing plan for this project is fairly complex and involves coordination among staff from
different units. For an overview, see the organization chart below. See Appendix B for details of
the responsibilities and membership of each role.
Executive Sponsors
Steering Committee
Executive Advisory Group
Project Office
(Project Manager)
SFS Upgrade Core Group
Site Leaders
mm/dd/yy
General Ledger
Payables
Purchasing
Accounts Receivable / Billing
EDI
Asset Management
WISDM / Brio
Query / nVision
Interfaces, Bolt-ons, Customizations
Security
Training
Commitment Control
Project Plan Example
Page 3
2.3 Project Schedule
High Level Milestone Chart
The high level milestone chart identifies the key deliverables by phase for each track of work. The
chart will be updated bi-weekly and those milestones that have been completed will be so noted.
The chart serves as a high level view of the project from today until the project completes. The
high level milestone chart facilitates general communication on the project status but should not
be construed as being a representation of the detailed status of the upgrade project. See
Appendix C for the baseline milestone chart.
Detail Project Schedule
The detailed project schedule follows the four phases of the SFS Upgrade Project. Within each
phase of the project the detail tasks/activities for each track of work are identified. The detailed
schedule was developed and will be maintained in MS Project. To facilitate the tracking of
progress each task will be designated as either 0%, 50%, or 100% complete. If a task has not
been started it will be considered 0% complete. If a task has been started, but is not complete, it
will be considered 50% complete. Only tasks that are complete will be designated with 100%.
This method of tracking progress is a standard project management process which helps to limit
the subjectivity associated with individuals reporting their progress on a task. See Appendix D for
the baseline project schedule.
There are seven tracks of work for the SFS 8.8 Upgrade Project. These tracks of work were
developed as a method to categorize similar activities to ease in the development, execution and
management of the project. The tracks of work and a brief description follow:
-
Environment
The tasks on this track of work deal with preparing the environment i.e. the databases,
operating processes, servers, etc. for the upgrade of SFS.
-
Site Readiness
The tasks on this track of work revolve around the sites preparing for the upgrade of SFS.
The tasks fall into three categories: system readiness, user readiness and support
readiness.
-
Project Management
The tasks within this track of work are focused upon the management of the project.
-
Training and Security
The tasks on this track of work revolve around the training of the SFS users and the
establishment of the necessary security for these users.
-
Testing
The tasks on this track of work deal with the four iterations of testing of the system by an
extended team, as well as, the execution of a parallel test.
-
Reporting
The tasks on this track of work deal with the migration of the existing SFS reports and
reporting systems to the upgraded SFS environment.
-
Business Process Readiness
The tasks on this track of work revolve around the identification, development, testing
and implementation of the interfaces, bolt-ons and customizations to SFS.
mm/dd/yy
Project Plan Example
Page 4
2.4 Project Budget
The project budget describing costs to complete the project tasks is as follows:
Cost Type
Planning / Approval
Time
Materials
Phase I: Fit/Gap Verification
Time
Materials
Phase II: Realization
Time
Materials
Phase III: Final Prep
Time
Materials
Phase IV: Post Go-Live & Support
Time
FY YY-YY
$XX,XXX
-$X,XXX
-$XXX,XXX
$X,XXX
$XX,XXX
$X,XXX
$XX,XXX
Materials
$X,XXX
Post-project Review
$X,XXX
Total Budget
mm/dd/yy
$XXX,XXX
Project Plan Example
Page 5
3. Project Control Plans
Project Control Plans provide the basis to control and monitor the progress of the project.
3.1 Communications Plan
Project status reports will be provided to the SFS Upgrade Project Office on a bi-weekly basis by
the leaders of the SFS Focus Groups. A monthly project status report, including key metrics, will
be distributed to all concerned parties as described in the SFS Upgrade Communication Plan.
Internal project team meetings will be held weekly, which will include the SFS Upgrade Project
Office, technical team members and business area representatives. Full project meetings will be
held on a monthly basis and will include the SFS Upgrade Project Office and members of the
SFS Upgrade Core Group. See Appendix E for the detailed SFS Upgrade Communication Plan.
Project progress and status will be communicated to the following groups by the SFS Project
Office:
- Executive Sponsors
- Executive Advisory Group
- Steering Committee
- Controllers
- SFS Users
- WISDM Users
- Site Leaders
- Project Staff
3.2 Quality Management Plan
The concept of a quality gate control methodology as a method to provide better and earlier
control of project quality was first introduced by John Aaron et al in 1993 at the PMI International
Symposium. The methodology has been modified slightly to facilitate its application to the SFS
Upgrade. In this context the SFS Upgrade has four Quality Gates which have been placed at
strategic points in the upgrade timeline.
As defined in the quality gate control methodology the criteria for each gate will be defined before
work begins on that gate. As progress on the project is tracked and reported, so too will the
sufficiency of each criterion be monitored and reported to the Executive Advisory Group. It is the
Executive Advisory Group who will make the recommendation to the Executive Sponsors, based
upon the quality gate exit criteria and the counsel of the SFS Upgrade Project Office, as to
whether or not to move into the next Quality Gate.
3.3 Issue Management Plan
The purpose of an issue management plan is to establish effective procedures to manage and
resolve a wide range of ongoing issues and open problems that occur throughout an upgrade
project. Open issues must be documented, reviewed and (more importantly) resolved in a timely
manner. Open issues that cannot be resolved by the SFS Upgrade Core Group (project team)
must be escalated to project management or the leadership team so that decisions can be made
quickly. Timely issue resolution allows the project effort to continue to move forward.
Issues that must be resolved for the successful completion of a successful project are identified in
each phase of the project process. Typically, issues must be resolved before phase completion
and before beginning the next phase.
mm/dd/yy
Project Plan Example
Page 6
Issues are items that are identified during a project and may influence the success of the project.
Typically, they fall into one of three areas:
-
They were not anticipated.
They are normal tasks that cannot be completed.
They are external factors that need to be overcome.
Issue Management Procedures
An issue is anything that may impede the progress of the SFS Upgrade. Once the issue is
identified, typically by a team member, it must proceed through a resolution process. The
resolution process starts with the Project Office who is responsible for the following tasks:
- Categorize issue
- Define issue priority
- Review issues and status
- Assign issue to an owner
Typically, issues fall into one of the following four categories:
-
Software bug (PeopleSoft, Crystal, Tivoli, etc.)
Configuration issues
Project issues
Resource issues
The prioritization of each issue should be defined in one of the following ways:
-
High Definite impact on upgrade target date
Medium Possible impact on upgrade project
Low No impact on upgrade (requires more resources for investigation)
The issues identified during the SFS Upgrade will be reviewed at a minimum weekly with the SFS
Upgrade Core Group and the SFS Upgrade Project Office. The status of the issues and the
progress made on resolution of the issues will be discussed in detail at that time. In addition, the
SFS Upgrade Project Issue Log will be incorporated into the monthly status report. See Appendix
F for a copy of the SFS Upgrade Project Issue Log format.
Issue Resolution Process
Below are the steps involved in the issue resolution process:
-
-
Submitting An Issue form must be submitted by the person who identifies the issue.
Logging A member of the Project Office records every issue in the log and updates the
status of issues.
Screening* The Project Office must review the submitted issues forms and determine if
the issue is relevant to the scope of the project.
Accepting* The Project Office accepts the issue if it may impede the progress or
success of the project
Deferring* The Project Office defers the issue if it is contingent on another issue that has
not been resolved.
Rejecting* The Project Office rejects the issue if it is not relevant to the project.
Prioritizing The Project Office prioritizes the issue based on its impact on other tasks or
phases.
Investigating and resolution determination The Project Office assigns the accepted
issue to a team member(s) for resolution determination. The team member(s) should
identify the appropriate resolution for the issue.
Deferring resolution The Project Office defers issue resolution if it is contingent on
another issue that has not been resolved. If necessary, the manager may consider
expediting the issue.
mm/dd/yy
Project Plan Example
Page 7
-
Monitoring or tracking The Project Office monitors the progress and the status of each
issue. In addition, the manager follows up on all open issues and identifies their
anticipated resolutions.
Escalation Management
- Expediting If an issue is not resolved by the forecasted date, and the lack of resolution
will affect other project steps, then the issue must be expedited. The Project Office
evaluates the reason the issue is not resolved and defines what must be done for the
issue to be resolved. Also, the Project Office identifies who is responsible for resolution,
attempts to put more people on the issue team (if this would help resolve the issue), and
ascertains whether or not the issue will be resolved in a timely manner. If need be, the
Project Office raises the priority and rearranges the project schedule to accommodate
issue resolution, keeping in mind the business and project goals.
-
Escalating If the issue is not resolved according to the project plan and this will
significantly affect the project timeline, then the Project Office may opt to escalate it to the
SFS Upgrade Executive Advisory Group.
-
Crisis mode If there is a crisis, for example, the system is down or a significant member
leaves the team, the Project Office should immediately review the project, its status, and
the impact of the crisis. Additionally, the Project Office should devise a workaround to
accommodate the change to the project plan. The Project Office will report any revisions
of the timeline in an emergency Executive Advisory Group meeting.
3.4 Risk Management Plan
The key risks identified for this project and the mitigation responses are identified below:
1. Continuation of the implementation of APBS. At the time of the publication of this
version of the Project Charter the APBS implementation is on indefinite pause. If the
APBS project is resumed within six months before or after the planned Upgrade of the
SFS system there will be an impact on resources. To mitigate this risk formal requests
have been made by UWSA management to be included in the planning of the APBS
project.
2. Determination of the ramifications of Commitment Control on existing interfaces
and bolt-ons. At the time of the publication of this version of the Project Plan we have
not had the opportunity to thoroughly test the functionality of Commitment Control to
determine its impact on our existing custom-built systems. To mitigate this risk the
upgrade project team will have several hands-on planning sessions to demonstrate the
flow of transactions through the system and have an impact analysis completed by the
end of mm/yy.
3. Additional unplanned SFS related work. Any changes to the existing workload for SFS
related projects by either the introduction of new projects or the revising of existing
timelines will have a negative impact on the Upgrade Project resources. To mitigate this
risk all requests for work will be reviewed and prioritized by the Executive Advisory
Group.
3.5 Procurement Plan
The upgrade software was purchased prior to the start-up of this project. Therefore, this project
does not require purchasing products or services from outside of the organization.
mm/dd/yy
Project Plan Example
Page 8
Appendixes
Appendix A – Work Breakdown Structure
SFS Upgrade
Phase I:
Fit/Gap Verification Phase
Environment
Site Readiness
Project Management
Training & Security
Testing
Reporting
Business Process Readiness
Phase II: Realization Phase
Environment
Site Readiness
Project Management
Training & Security
Testing
Reporting
Business Process Readiness
Phase III: Final Preparation Phase
Environment
Site Readiness
Project Management
Training & Security
Testing
Reporting
Business Process Readiness
Phase IV: Post Go-Live and Support
Environment
Site Readiness
Project Management
Training & Security
Testing
Reporting
Business Process Readiness
mm/dd/yy
Project Plan Example
Page 9
Appendix B – Staffing Plan
This appendix details the responsibilities and membership of the various roles described in the
SFS Upgrade project plan.
Executive Sponsors
Responsibilities:
- Review project status, budget, resources, issues and risks with the SFS Upgrade Project
-
Office on a regular basis via scheduled meetings
Oversight of the entire upgrade project
Signoff / acceptance of the capability of the upgraded system
Final acceptance responsibility
Support of the project team
Team Membership:
- Sponsor 1
- Sponsor 2
Steering Committee
Responsibilities:
- Review project status with Executive Sponsors, Executive Advisory Group and SFS
-
Upgrade Project Office on a regular basis via scheduled meetings and advise of impact
to campuses or on other initiatives underway
Work with campus leadership on the resolution of any issues that impact campuses
Review any new functionality or changes to business processes presented by the SFS
Upgrade Project Office and provide guidance in regard to the associated
recommendations and impact on campus resources
Liaisons to SFS campus constituents
Team Membership:
- Member 1, Controller UW Madison
- Member 2, CBO UW Whitewater
- Member 3, Controller UW Parkside
- Member 4, CIO UW Milwaukee
- Member 5, Controller UW Stevens Point
Executive Advisory Group
Responsibilities:
- Review project status, budget, resources, issues and risks with SFS Upgrade Project
-
Office on a regular basis via scheduled meetings
Address and resolve in a timely manner all issues presented by the SFS Upgrade Project
Office
Provide guidance and advice to the SFS Upgrade Project Office
Review any new functionality or changes to business processes presented by the SFS
Upgrade Project Office and provide guidance in regard to the associated
recommendations
Allocate resources as needed
mm/dd/yy
Project Plan Example
Page 10
-
Liaisons to Executive Sponsors
Review and signoff of project components including Quality Gate Exit Criteria
Support the upgrade team in all upgrade efforts
Team Membership:
- Advisory 1
- Advisory 2
- Advisory 3
- Advisory 4
- Advisory 5
SFS Upgrade Project Office
Responsibilities:
-
-
Prepare Project Plan and manage the entire upgrade effort
Monitor progress on the upgrade project plan and tasks and communicate to all
stakeholders on a regular scheduled basis
Facilitate meetings with the project team to discuss progress and issues
Evaluate enhancements and change requests and alter the scope of the upgrade or
obtain additional resources, as required, to ensure that the project is completed on
schedule
Actively encourage communication between the upgrade team members and the
functional users
Manage budget
Support the upgrade team in all upgrade efforts
Team Membership:
- Staff 1
- Staff 2
- Staff 3
- Staff 4
SFS Upgrade Project Manager
Responsibilities:
-
Single point of contact for project status, issue resolution and overall coordination of effort
Ensures requirements and scope are identified early on
Coordinates work planning meetings, work responsibility assignment, and ensures
scheduled objectives are agreed upon
Organizes the team, organizes meetings and makes the team a cohesive unit
Communicator for to do’s and issue resolution, ensures timely follow-up
Project Manager 1 is the SFS Upgrade Project Manager.
SFS Upgrade Site Leaders
Each site that currently uses SFS to conduct its business will designate a Site Leader for the SFS
Upgrade project. The Site Leader’s role is to provide leadership and facilitation of the SFS 8.8
Upgrade at the specified site. The Site Leader is responsible for determining whether or not the
site is ready for the upgrade by knowing the business practices of the site; the critical users of the
SFS based business processes; and ensuring that the SFS Upgrade will not negatively impact
the site. The Site Leader will evaluate the site’s readiness in three major areas: System
Readiness, User Readiness; and Support Readiness. The details of the role and responsibilities
of the Site Leader can be found in the SFS 8.8 Upgrade Project Readiness Checklist.
Not all Site Leaders have been identified at the time of issuance of this plan.
mm/dd/yy
Project Plan Example
Page 11
SFS Upgrade Core Group (SFSUCG)
The SFS Upgrade Core Group is comprised of twelve Focus Teams. Each Focus Team has a
person designated as the lead whose responsibility is to ensure that the members of the Focus
Team achieve their deliverables on schedule and within the defined quality standards. The Focus
Teams are responsible for leading the analysis of differences between 7.5 and 8.8 and
implementing appropriate solutions for each site that uses that SFS functionality to conduct
business. Team membership for these Focus Teams may change as the project progresses.
Responsibilities:
Each Focus Team of the SFSUCG, identified below, is responsible for the following general tasks
for their individual area. Additional area-specific tasks are identified in the associated team task
list section.
-
-
-
-
Develop list of functionality available in PeopleSoft Version 7.5 and in 8.8 for specific
functional area. Identify and document differences in functionality between the two
versions and present findings to SFS Core Leadership Team. Identify and document any
new functionality that may be required to keep the existing business processes
functioning. Any new functionality recommended must be accompanied by a documented
cost/benefit analysis.
Analyze functionality currently being used in each specific area. Determine and document
functionality to be included in upgrade.
Review Compare Reports for related module table changes.
Review business processes and identify recommendations for change.
Develop a strategy and timeline for testing the specific functional area business
processes. Review the strategy and timeline with all impacted campuses / business units,
document any concerns expressed by the campuses / business units and present
concerns to the SFS Core Leadership Team. Develop comprehensive test scenarios with
active participation from the SFS campuses business units. Execute test scenarios or
deploy to campuses for testing and analyze test results.
Evaluate the current customizations and interfaces to and from the SFS system for the
specific functional area to determine if they are still required. Prepare a document
indicating which customizations will remain and which if any require modification along
with the interfaces that will remain and those requiring modification.
Work with the Training / Communication / Outreach team to determine functional area
specific training requirements and user documentation.
Assist in upgrade deployment activities as required.
Document in SFS Upgrade Issues Log all issues discovered during project. Update
document as appropriate when status changes.
Develop and test any new reports required along with any modifications to existing
reports.
Coordination of upgrade cycle and patches to the system must include all focus groups
and DRMT.
mm/dd/yy
Project Plan Example
Page 12
Appendix C – Baseline Milestone Chart
Phase
Phase I:
Phase II:
Phase III:
Phase IV:
mm/dd/yy
Target Date
Fit/Gap Verification Phase
Realization Phase
Final Preparation Phase
Post Go-Live and Support
Project Plan Example
mm/dd/yyyy
mm/dd/yyyy
mm/dd/yyyy
mm/dd/yyyy
Page 13
Appendix D – Baseline Project Schedule
excluded from example
Appendix E – SFS Upgrade Communications Plan
excluded from example
Appendix F – SFS Upgrade Project Issue Log
excluded from example
mm/dd/yy
Project Plan Example
Page 14