project plan - university of wisconsin–madison templates_examples/more/2... · web...

Project Plan

Project Name:

Shared Financial System (SFS)

8.8 Upgrade Project

Prepared By: Project ManagerTitle: Project Manager

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.

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


Project Customer 2


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 mm/dd/yy Project Manager Initial version for review and commentVersion 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 OfficerCIO Chief Information OfficerDoIT Division of Information TechnologySFS Shared Financial SystemsSFSUCG SFS Upgrade Core Group

mm/dd/yy 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.......................................................................................................32.2 STAFFING PLAN....................................................................................................................................32.3 PROJECT SCHEDULE............................................................................................................................42.4 PROJECT BUDGET................................................................................................................................5

3. PROJECT CONTROL PLANS...............................................................................................................6

3.1 COMMUNICATIONS PLAN......................................................................................................................63.2 QUALITY MANAGEMENT PLAN.............................................................................................................63.3 ISSUE MANAGEMENT PLAN.................................................................................................................63.4 RISK MANAGEMENT PLAN...................................................................................................................83.5 PROCUREMENT PLAN...........................................................................................................................8

APPENDIXES................................................................................................................................................9

APPENDIX A – WORK BREAKDOWN STRUCTURE....................................................................................9APPENDIX B – STAFFING PLAN...............................................................................................................10APPENDIX C – BASELINE MILESTONE CHART........................................................................................13APPENDIX D – BASELINE PROJECT SCHEDULE.....................................................................................14APPENDIX E – SFS UPGRADE COMMUNICATIONS PLAN.......................................................................14Appendix 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 PhasesThe SFS 8.8 Upgrade Project was developed by segmenting the project into four phases. The phases are described below:

- Fit / Gap Verification PhaseThis 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 PhaseIn 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 PhaseIn 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 SupportDuring 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.


2. Project Work Plans

2.1 Work Breakdown StructureThe 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

Project Office (Project Manager)

Site Leaders

Steering Committee Executive Advisory Group

SFS Upgrade Core Group

General Ledger Payables

Purchasing Accounts Receivable / Billing

EDI Asset Management

WISDM / Brio Query / nVision

Interfaces, Bolt-ons, Customizations Security

Training Commitment Control

2.3 Project Schedule

High Level Milestone ChartThe 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 ScheduleThe 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:

- EnvironmentThe 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 ReadinessThe 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 ManagementThe tasks within this track of work are focused upon the management of the project.

- Training and SecurityThe tasks on this track of work revolve around the training of the SFS users and the establishment of the necessary security for these users.

- TestingThe 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.

- ReportingThe 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 ReadinessThe 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 BudgetThe project budget describing costs to 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,XXXPhase III: Final Prep Time $XX,XXX Materials $X,XXXPhase IV: Post Go-Live & Support Time $XX,XXX Materials $X,XXXPost-project Review $X,XXXTotal 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 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.


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 ProceduresAn 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 ProcessBelow 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.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.


Appendixes

Appendix A – Work Breakdown Structure

SFS UpgradePhase I: Fit/Gap Verification Phase

EnvironmentSite ReadinessProject ManagementTraining & SecurityTestingReportingBusiness Process Readiness

Phase II: Realization PhaseEnvironmentSite ReadinessProject ManagementTraining & SecurityTestingReportingBusiness Process Readiness

Phase III: Final Preparation PhaseEnvironmentSite ReadinessProject ManagementTraining & SecurityTestingReportingBusiness Process Readiness

Phase IV: Post Go-Live and SupportEnvironmentSite ReadinessProject ManagementTraining & SecurityTestingReportingBusiness Process Readiness


Appendix B – Staffing Plan

This appendix details the responsibilities and membership of the various roles described in the SFS Upgrade project plan.

Executive SponsorsResponsibilities:

- 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 CommitteeResponsibilities:

- 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 GroupResponsibilities:

- 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- 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 OfficeResponsibilities:

- 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 LeadersEach 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.

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.


Appendix C – Baseline Milestone Chart

Phase Target Date

Phase I: Fit/Gap Verification Phase mm/dd/yyyyPhase II: Realization Phase mm/dd/yyyyPhase III: Final Preparation Phase mm/dd/yyyyPhase IV: Post Go-Live and Support mm/dd/yyyy


Appendix D – Baseline Project Scheduleexcluded from example

Appendix E – SFS Upgrade Communications Planexcluded from example

Appendix F – SFS Upgrade Project Issue Logexcluded from example


project plan - university of wisconsin–madison templates_examples/more/2... · web...

Documents