《PMOHandbookforOracle 11i ERP Project.doc》由会员分享，可在线阅读，更多相关《PMOHandbookforOracle 11i ERP Project.doc（46页珍藏版）》请在三一办公上搜索。
1、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 IssueContents1.PMO Objectives1Figure 1A: PMO Key Activities12.Project Reporting St
2、ructure22.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.
3、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: Chang
4、e 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
5、.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 Managemen
6、t138.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
7、.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 Manag
8、ement199.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.
9、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 Submissi
10、on FormF-1G.Appendix G Risk Submission FormG-11. 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;Creat
11、e 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:Activity
12、DetailsScope 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 Implem
13、enting 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 communi
14、cations scheduleFacilitate communications activitiesFigure 1A: PMO Key Activities2. 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
15、 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,
16、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
17、 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 stag
18、e 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
19、 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
20、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.3. Communications3.1. ObjectivesThe objectives of the communications processes are:To help co-ordinate programme activities;To manage effect
21、ive & 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 & 3r
22、d 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
23、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.4. Project Planning4.1. Planning OverviewThe Project
24、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 pla
25、n. 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 main
26、tained 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 b
27、y 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
28、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). Up
29、ward 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 n
30、eed 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 Process5. Document Control5.1. IntroductionThis section sets out the standards to be used when producing and changing key documented prod
31、ucts 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
32、 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 ch
33、ange 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
34、 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
35、-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 ver
36、sion 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_implementa
37、tion plan_1.0_200503036. 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
38、 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 descr
39、iption. 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 delive
40、rable 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
41、 go through the same process again.Figure 6A: Product Management 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
42、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 El
43、iminate 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
44、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 cree
45、p.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 reque
46、st.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
