Project Plan
Project Name:
Shared Financial System (SFS)
8.8 Upgrade 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:
Document Change Control
The following is the document control for revisions to this document.
Version Number / Date of Issue / Author(s) / Brief Description of ChangeVersion 1.0 / mm/dd/yy / Project Manager / Initial version for review and comment
Version 1.1 / mm/dd/yy / Project Manager / 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 / DefinitionCBO / Chief Business Officer
CIO / Chief Information Officer
DoIT / Division of Information Technology
SFS / Shared Financial Systems
SFSUCG / SFS Upgrade Core Group
Table of Contents
1. Project Plan Overview and Critical Assumptions
2. Project Work Plans
2.1 Work Breakdown Structure
2.2 Staffing Plan
2.3 Project Schedule
2.4 Project Budget
3. Project Control Plans
3.1 Communications Plan
3.2 Quality Management Plan
3.3 Issue Management Plan
3.4 Risk Management Plan
3.5 Procurement Plan
Appendixes
Appendix A – Work Breakdown Structure
Appendix B – Staffing Plan
Appendix C – Baseline Milestone Chart
Appendix D – Baseline Project Schedule
Appendix E – SFS Upgrade Communications Plan
Appendix F – SFS Upgrade Project Issue Log
mm/dd/yy Example Project Plan Page 1
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.
-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.
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.
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.
2.4 Project Budget
The project budget describing coststo complete the project tasks is as follows:
Cost Type / FY YY-YYPlanning / Approval
Time / $XX,XXX
Materials / --
Phase I: Fit/Gap Verification
Time / $X,XXX
Materials / --
Phase II: Realization
Time / $XXX,XXX
Materials / $X,XXX
Phase III: Final Prep
Time / $XX,XXX
Materials / $X,XXX
Phase IV: Post Go-Live & Support
Time / $XX,XXX
Materials / $X,XXX
Post-project Review / $X,XXX
Total Budget / $XXX,XXX
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 ManagementPlan
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.
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.
-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.4Risk Management Plan
The key risks identified for this project and the mitigation responses are identified below:
- 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.
- 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.
- 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.5Procurement Plan