PMO_Handbook_for_Oracle 11i ERP Project.doc

oracle 11i erp projectpmo handbookversion: 1.011 april 2005author:distribution:for information:pmoamendment historyissuedateamendments1.0a03/03/05first draft1.0b05/03/05pmo review comments incorporated1.011/04/05first issueda9b9ccc47c600b650c172651faf0d3a.pdfcontents1.pmo objectives1figure 1a: pmo key activities12.project reporting structure22.1.checkpoint reports22.2.highlight reports22.3.stage end reports23.communications33.1.objectives33.2.meeting schedule3figure 3a: meeting schedule33.3.ad hoc meetings34.project planning44.1.planning overview44.2.maintenance44.3.variance4figure 4a: plan variance process55.document control65.1.introduction65.2.tools65.3.version control6figure 5a: document reference data65.4.file naming76.product management86.1.purpose86.2.product management process8figure 6a: product management process87.change control process97.1.purpose97.2.change control steps97.3.change control flow9figure 7a: change management process107.4.change control roles107.4.1.change control board (as part of programme board)107.4.2.project manager107.4.3.team lead117.4.4.project members & user community117.4.5.pmo117.5.method for assessing change requests117.5.1.procedure for identifying and documenting changes117.5.2.procedure for analysing the impact of change requests117.5.3.procedure for classifying and recording change requests127.5.4.procedure for approving change requests127.5.5.procedure for resolving change requests127.5.6.change request forms128.issue management process138.1.purpose of issues management138.2.issues defined138.3.issues management process flow13figure 8a: issue management process148.4.issues identification148.4.1.issues documentation148.4.2.issues log148.4.3.issue type148.4.4.issue priority148.5.issues management procedures159.risk management169.1.risk process169.2.risks defined169.3.risk roles16figure 9a: risk management roles179.4.risk management process flow17figure 9b: risk management process179.5.risk identification179.5.1.risk documentation189.5.2.risk log189.6.risk evaluation189.6.1.risk probability189.6.2.risk impact189.7.risk response189.8.risk owners199.9.risk management199.10.risk management procedure1910.financial control2010.1.financial control process20figure 10a: financial management process2010.2.process overview2010.2.1.time recording process2011.project repository2111.1.eroom address2111.2.using the eroom2111.2.1.logging on2111.2.2.eroom structure2111.2.3.eroom navigation2211.2.4.adding & editing items & folders23a.appendix a team checkpoint reporta-1b.appendix b project highlight reportb-1c.appendix c project stage end reportc-1d.appendix d - production description & sign off formd-1e.appendix e - request for changee-1f.appendix f issue submission formf-1g.appendix g risk submission formg-1da9b9ccc47c600b650c172651faf0d3a.pdfpmo objectives1. pmo objectivesthe main objectives of the pmo are to:co-ordinate delivery of the project on time, within agreed budgets and to specified quality;create processes to help manage and ensure quality without creating an un-necessary overhead to teams;create the “big picture” and effective communication channels;help manage stakeholder risk and issues through encouraging openness and visibility;support development of strong and effective supplier relationships;drive accountability throughout the programme.the key activities of the pmo include:activitydetailsscope managementmonitoring key milestones by teammonitoring of budgetsconfiguration managementreportingcreating meeting and progress reportsconsolidating team checkpoint reportsco-ordinating end-stage reportscreating the product checklist and processadministrating the product checklist implementing a quality management sign-off processmaintaining the risk and issue logsconsolidating risks & issues using respective templatesescalation processproviding structured approach to risk, issue, and change managementcommunicationensuring escalation process is followed providing structured communications schedulefacilitate communications activitiesfigure 1a: pmo key activitiesda9b9ccc47c600b650c172651faf0d3a.pdf1project reporting structure2. project reporting structurethe project reporting structure outlines the communications and information-sharing processes that will operate to ensure that the project is managed successfully. this process is initiated at the team level through the checkpoint report and this information is filtered up to the sponsors via the following process:2.1. checkpoint reportseach team will hold a status meeting on a weekly basis and complete a checkpoint report for submission to the pmo. the pmo will check that all risks, issues and changes have been added to the appropriate log. the template for the checkpoint report is provided at appendix a.2.2. highlight reportsteam leads will meet with the project manager on a weekly basis to discuss status and review risks, issues and changes. the output of this meeting will be the highlight report which will consolidate the overall status of the project. the template for the highlight report is provided at appendix b.a summary of this report will be prepared by the pmo for communication to the senior stakeholder group.2.3. stage end reportsat the end of each project stage a stage-end review will be held. this involves a review of the impact of the stage on the project plan, the business case and the identified risks. the objective of this process is to decide whether to authorise the next stage of work and hence commit the required resources, based on:a view of the current status of the project;a detailed forecast of the commitment of resources required by, and the products to be created from, the next stage of the project;a reassessment of the likely project end date;a reassessment of the risk situation;a reassessment of the business case and the chances of achieving the expected benefits.the results of the stage are presented in the end stage report. the template for the end stage report is provided at appendix c.g-2communications3. communications3.1. objectivesthe objectives of the communications processes are:to help co-ordinate programme activities;to manage effective & timely decision making;to facilitate risk mitigation and issue resolution;to facilitate knowledge management and sharing.3.2. meeting schedulethe weekly meeting schedule is set out in figure 3-a.mondaytuesdaywednesdaythursdayfridaya.m.project update (weekly)programme board (bi-monthly 1st & 3rd tuesday)team status meeting (weekly)p.m.stakeholder update (weekly)project status meeting (weekly)figure 3a: meeting schedule3.3. ad hoc meetingsin addition to the main project meeting schedule (see figure 3-a), the pmo will co-ordinate all cross-team meetings. in order to incorporate all meeting requests the pmo must receive the list of needed meetings by end of business each thursday (please note that meetings within a team are organised internally). the meeting request should include:topic;agenda;participants;date and duration;location.project planning4. project planning4.1. planning overviewthe project plan will exist at both a high and detailed level. the high level plan will contain major milestone products, dependencies and the critical path. it will aim to provide a single view of the project and provide the progress information required to make decisions. the project manager will own this plan. each team will own a version of the plan containing a detailed breakdown of their tasks, plus the major milestone products from all other teams. team managers will own their respective plan and be responsible for planning and meeting each milestone.4.2. maintenancethe high level plan will be maintained at a project level. the pmo will update progress in the plan on a regular basis, and add changes approved by the project board. the pmo will also communicate any impact across teams. the high level plan will be available (read only) to all project team members. team plans will be maintained by the teams themselves.changes made to detailed plans that do not affect the contents of the high level plan will be communicated by team managers to the programme planner, and will submit an updated detailed plan to the pmo. 4.3. variancea variance is defined as any change made to a plan that will impact the milestones represented in the dependent plan/s. a variance may cause a backward or forward movement in the delivery of work packages. issues that cause variances to the plan may occur in both an upward (generated at team level) and downward direction (generated at project board level). upward variance: will be reported as an issue, and therefore the escalation procedure for variance is the issue procedure.downward variance: the project manager will communicate the validated variance (i.e. checked with each team) during the weekly stream leaders meeting, and the stream leaders will need to update their stream plans accordingly. if the issue is a high priority, the project manager will communicate changes as necessary. figure 4a: plan variance processdocument control5. document control5.1. introductionthis section sets out the standards to be used when producing and changing key documented products for the project.5.2. toolsthis section defines the standard software tools to be used on the project:word processing - microsoft word;graphics and presentation material - microsoft powerpoint;flowcharts & architectural diagrams microsoft visio;spreadsheets - microsoft excel;project planning and progress tools - microsoft project;databases - microsoft access.5.3. version controlproducts will be subject to version control. version numbering will adopt the following convention:. for example:1.1bversion: varying from 1 onwards; indicates the major version of the document. this element will change in accordance with change control processes and generally indicate major changes or additions to the document. release: varying 1 through 9; indicates minor amendments within a version of the document. revision: a through z; indicates revisions or drafts of the document as issued for review.for example: a document is created as version 1.0a. it passes through three drafts during review (1.0a, 1.0b and 1.0c) before formal release (published) as version 1.0. this version must be submitted to the pmo in both hard and soft (electronic) copies. a subsequent minor addition to the deliverable re-opens the document as version 1.1a. this is reviewed and 1.1b is published as version 1.1.all documents subject to version control must identify the following:attribute requireddescriptionprojectthe project nametitlethe document title subjectsubject of the documentauthorauthorversion number the version number e.g. version 1.0arevision recorda brief description of each revisiondistribution listidentifying recipients as “for information” or “for review”figure 5a: document reference data5.4. file namingproducts should adhere to the following file naming convention:_for example: p0-1-c_implementation plan_1.0_20050303product management6. product management6.1. purposeto ensure that products (deliverables) created during the project are delivered on time, and meet the expectations set at the beginning of the project, a quality procedure is in place.6.2. product management processall products identified during the project planning exercise are logged and monitored in the product checklist. each product will also be set quality criteria to meet so that it can be approved. a detailed description of the product, its quality criteria, the owner and sign-off requirements will be contained in the product description. the template for the description is attached at appendix d.when a deliverable is completed, it is required to go through a sign-off process to ensure that it meets the quality criteria set when originally defined. the sign-off process requires:product owners to notify the pmo that the deliverable is complete. the pmo to prepare a sign-off requestidentified reviewers to review deliverable against sign-off criteriaif acceptable, the deliverable is signed off and the product checklist updatedif not acceptable, reviewers will provide notes as to what is missing and the product will need to go through the same process again.figure 6a: product management processchange control process7. change control process7.1. purposethe purpose of change control is to control changes to the established project scope, schedule, cost, quality, and approved project deliverables. the objectives of the change control process are to:l develop change standards, policies, and procedures;l effectively manage and coordinate all changes to the project;l monitor the impacts on the projects delivery date;l coordinate all of the work activities associated with a change request;l manage the approved baseline and deliverables;l eliminate or reduce “scope creep”.change management controls any additions, deletions, or modifications to the scope and the project plan. the type of change to the project affects the scope documents. the investigation of a proposed change evaluates its effect on budget, schedule, and resources. not all aspects of a project can be determined in advance. change from internal or external sources to the scope and project plan need to be accommodated through the life of the project. all requests for changes must be evaluated and approved (or disapproved) in order to recognise and control scope creep.7.2. change control steps the change control process follows these steps:1. identify and document the need for change.2. analyse the impact of the requested change and alternatives.3. classify and record the change request.4. have the change control board approve, defer, or reject the change request.5. record and communicate the decision.6. if the change is approved, have the project manager review and prioritise the approved change requests.7. update applicable project documentation.8. schedule and assign resources.9. execute the change.7.3. change control flow the change control process flow is shown in figure 7-a.figure 7a: change management process7.4. change control roles7.4.1. change control board (as part of programme board)the change control board will meet as part of the programme board, or whenever a key change or group of changes requires consideration. meetings may take place in person or via conference call.the change control board includes the following individuals:programme board;other individuals at the discretion of the programme board.the project manager acts as the facilitator and the focal point for collecting change requests and coordinating change board meetings.the pmo will provide the board with a list of current change requests at least 24 hours prior to the change control review meeting.the change control board must communicate its decisions to the project manager and other project stakeholders within one day after the change control board meeting.the change control board must approve a change request before any work on the requested change commences.the change control board retains the authority for deciding which proposed changes actually get incorporated into a project.7.4.2. project managerthe project manager has the following responsibilities with respect to the change control process:receive all change request forms;review the change request forms with respect to the cost plan and schedule plan;determine the disposition of the change request forms;communicate the results of the change request to the project team, interested stakeholders, and parties responsible for implementing the change;update the baseline schedule and budget, if applicable.7.4.3. team leadindividual team leads have the following responsibilities:review all change request forms;research the possible change request impact;suggest alternatives to the requested change; compare changes to the status quo. 7.4.4. project members & user communityproject team members and users will identify requests for changes using the change request form. 7.4.5. pmothe pmo has the following responsibilities:record each change request on the change request log;maintain the change request log;generate and distribute a list of change requests on a periodic basis.7.5. method for assessing change requests7.5.1. procedure for identifying and documenting changesthe change control process is invoked in the following circumstances:there is a change to the project scope, time frame, or budget as defined in the pid, business case or other key management document;a change is requested to signed-off product in a phase; for example, requirement specifications, functional designs, training materials, user guides, or architecture documents;a change is proposed to the baseline hardware, operating or applications software, database, tables, or user configuration;a change is requested to delivered and accepted systems.7.5.2. procedure for analysing the impact of change requestsreview each change request form to identify the impa