ࡱ>     ]}} Rbjbj55  __ZZ(ŏ $ ْlE )xqgL; $5(((((((w-0L2)ɷ@ɷɷ)"DG)ɷ(ɷ(t$0EAK ~n Z(])0) e0-e0$e0$ɷɷɷɷɷɷɷ)((ɷɷɷ)ɷɷɷɷe0ɷɷɷɷɷɷɷɷɷZ c: PM 904 Project Business Plan (Medium Projects) Template and Guide Version 2, April 2008 This Template and Guide is for the development of a Project Business Plan for a medium sized project. The Guide is intended to be read in conjunction with the Template and should be removed from the front of the final document. Other templates and guides for the development of a Project Business Plan for a larger, more complex project (PM 004 Project Business Plan - Large) or a small project (PM 994 Project Business Plan - Small) have also been developed. Please refer to Project Management Fact Sheet: Project Sizing to determine your relevant Project Business Plan. These are available at www.egovernment.tas.gov.au. The project management templates are being continuously improved. Feedback on suggested improvements to this Template would be appreciated, and may be made to IAPPU by emailing HYPERLINK "mailto:pminfo@dpac.tas.gov.au"pminfo@dpac.tas.gov.au. DISCLAIMER This material has been prepared for use by Tasmanian Government agencies and Instrumentalities. It follows that this material should not be relied upon by any other person. Furthermore, to the extent that this material is relied upon, the Crown in Right of the State of Tasmania gives no warranty as to the accuracy or correctness of the material or for any advice given or for omissions from the material. Users rely on the material at their own risk. What is a Project Business Plan? A Project Business Plan is the management document for the project. It is owned, maintained and utilised by the Sponsor to ensure the delivery of project outputs and the realisation of project outcomes. The Project Management Fact Sheet: Project Sizing can assist you to determine the size of your project. Why would you develop a Project Business Plan? A Project Business Plan is developed to provide: Comprehensive overview of all the project components, how you intend to produce the outputs and describes the roles and responsibilities of each of the parties in the governance structure of the project. The projects Sponsor with a documented framework to ensure the achievement of defined project outcomes and to effectively monitor the project from start to finish. A formalised agreement between the Project Sponsor and the Project Manager of what needs to be done and when. The document expands upon the original Project Proposal or the approved option in the Project Business Case enabling detailed definition of the scope and management of the project. When would you develop a Project Business Plan? Approval to proceed to develop a Project Business Plan is usually obtained from the acceptance or approval of a preceding stage such as a Project Proposal, Project Business Case or Feasibility Study. The Project Business Plan expands the approved proposal developed in these documents in order to: Provide specific details on the scope, governance, budget, resources, work plan and milestones of the project. Define the project and quality management processes to be used throughout the project. Gain authorisation to proceed to the next step of the project. What you need before you start: Agreement to proceed with the development of the Project Business Plan from the Project Sponsor or Proposer. Knowledge and understanding of the development of a Project Business Plan, as outlined in the Tasmanian Government Project Management Guidelines Version 6.0, 2005. Any other project approval processes that are required in your organisation. Endorsed document establishing the scope of the Project Business Plan, which could be a Project Proposal or a Project Business Case, or as simple as an email from your manager. Also advisable: Knowledge and understanding of project planning, scope definition, stakeholder identification, risk identification and the development of work breakdown structures. Awareness of the environmental factors that may affect the project such as political, industrial, legislative, technical, financial, social, cultural and security/privacy. Corporate/Business Plan for the Department/Business Unit. Departmental Project Management Guidelines. What you will have when you are finished: A complete Project Business Plan that is ready for acceptance by the Project Sponsor/Steering Committee. Integration Process: Any endorsed documents (for example a Project Proposal, Project Business Case or an email from your manager) should be utilised to populate the Project Business Plan. This information, along with any gaps, then provide a basis for further discussion, clarification and confirmation of the project scope. It should be noted that development of the Project Business Plan is not a static process, and that all aspects described in the Business Plan must be re-examined many times over the life of the project, particularly where a great deal of change is involved. This iterative development should involve the Project Sponsor. The key is to obtain clear sign-off where scope changes are required during the life of the project. Maintaining document control: In order to track the agreed changes to the Project Business Plan, and record its distribution throughout the document's development and subsequent revision(s), a document version control process is essential. Version control provides for unique identification of documents, whether electronic or hard copy, and assists with the easy identification of each subsequent version of a document. The version number changes as the document is revised allowing released versions of a document to be readily discernable from draft versions. Refer to the Project Management Fact Sheet: Document Control at  HYPERLINK "http://www.egovernment.tas.gov.au" www.egovernment.tas.gov.au for more information. How to use this template: The template contains sections which are either optional or can be developed at a number of levels of detail depending upon individual need. All documents developed based on this template should include an appropriate acknowledgement. A number of different text styles have been used within the template, as follows: Text in blue italics is intended to provide a guide as to the kind of information that can be included in a section and to what types of projects it might be applicable. It should be deleted from the final document . Text in normal font is intended as examples. Text enclosed in is intended to be replaced by whatever it is describing. This document has been formatted for duplex printing. If you intend to print single sided, you may need to delete some page breaks. Where to Get Additional Help The following tools and resources are available at www.egovernment.tas.gov.au: The Project Management Fact Sheet: Developing a Project Business Plan provides additional detail on the steps involved in developing a Project Business Plan. The Project Status Report: Template and Guide Further information on stakeholder management is contained within the Tasmanian Government Project Management Guidelines - Section 5: Stakeholder Management and the Project Management Fact Sheet: Developing a Project Communication Strategy. Further information on assessing the projects exposure to risk is contained within the Tasmanian Government Project Management Guidelines Section 6: Risk Management and the Resource Kit: Risk Management. Checklist Have you remembered to remove: The versioning statement from the front cover of your document? This guide and checklist from the front of your document? All blue italic instructional text and within the template? < DOCPROPERTY strProjectTitle \* MERGEFORMAT Project Title> Project Business PlanThe version number starts at one and increases by one for each release. It shows the release number and a revision letter if in draft. The original draft is 0.A and subsequent drafts are 0.B, 0.C etc. The first accepted and issued document is 1.0. Subsequent changes in draft form are 1.0A, 1.0B etc.. The accepted and issued second version is 1.1 or 2.0, depending on the magnitude of the change. Refer to the Project Management Fact Sheet: Document Control, for more information at HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au  Version No: Copy: Uncontrolled Acknowledgements The contribution of the following individuals in preparing this document is gratefully acknowledged: This document has been derived from a template prepared by the Department of Premier and Cabinet, Tasmania. The structure is based on the Tasmanian Government Project Management Guidelines Version 6.0, 2005. For further details, refer to HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au  Document Acceptance and Release Notice This document is  DOCPROPERTY strVersion \* MERGEFORMAT Version No of the Project Business Plan. The Project Business Plan is a managed document. For identification of amendments, each page contains a release number and a page number. Changes will only be issued as a complete replacement document. Recipients should remove superseded versions from circulation. This document is authorised for release once all signatures have been obtained. PREPARED:Date:--(for acceptance) Project ManagerACCEPTED:Date:--(for release) Project Sponsor Document Development History Build Status: VersionDateAuthorReasonSections List the most recent amendment firstInitial ReleaseAllAmendments in this Release: Section TitleSection NumberAmendment Summaryeg: This is the first release of this document.Distribution: Copy NoVersionIssue DateIssued To12ElectronicShared drive Table of Contents  TOC \h \z \t "Heading 1,1,Heading 2,2,Heading 3,3"  HYPERLINK \l "_Toc195948382" 1 Overview  PAGEREF _Toc195948382 \h 11  HYPERLINK \l "_Toc195948383" 1.1 Purpose of Business Plan  PAGEREF _Toc195948383 \h 11  HYPERLINK \l "_Toc195948384" 1.2 Project Title  PAGEREF _Toc195948384 \h 11  HYPERLINK \l "_Toc195948385" 1.3 Initiation & Background  PAGEREF _Toc195948385 \h 11  HYPERLINK \l "_Toc195948386" 2 Objectives and Scope  PAGEREF _Toc195948386 \h 11  HYPERLINK \l "_Toc195948387" 2.1 Objectives  PAGEREF _Toc195948387 \h 11  HYPERLINK \l "_Toc195948388" 2.1.1 Corporate Objective(s)  PAGEREF _Toc195948388 \h 12  HYPERLINK \l "_Toc195948389" 2.1.2 Project Objective(s)  PAGEREF _Toc195948389 \h 12  HYPERLINK \l "_Toc195948390" 2.2 Outcomes  PAGEREF _Toc195948390 \h 12  HYPERLINK \l "_Toc195948391" 2.3 Outputs  PAGEREF _Toc195948391 \h 13  HYPERLINK \l "_Toc195948392" 2.4 Scope of Work  PAGEREF _Toc195948392 \h 13  HYPERLINK \l "_Toc195948393" 2.5 Project Development Plan  PAGEREF _Toc195948393 \h 14  HYPERLINK \l "_Toc195948394" 2.6 Assumptions and Constraints  PAGEREF _Toc195948394 \h 15  HYPERLINK \l "_Toc195948395" 2.6.1 Assumptions  PAGEREF _Toc195948395 \h 15  HYPERLINK \l "_Toc195948396" 2.6.2 Constraints  PAGEREF _Toc195948396 \h 15  HYPERLINK \l "_Toc195948397" 2.7 Relevant Government Policy, Legislation and Rules  PAGEREF _Toc195948397 \h 15  HYPERLINK \l "_Toc195948398" 3 Project Management Plan  PAGEREF _Toc195948398 \h 16  HYPERLINK \l "_Toc195948399" 3.1 Governance  PAGEREF _Toc195948399 \h 16  HYPERLINK \l "_Toc195948400" 3.1.1 Project Sponsor  PAGEREF _Toc195948400 \h 17  HYPERLINK \l "_Toc195948401" 3.1.2 Project Business Owners  PAGEREF _Toc195948401 \h 17  HYPERLINK \l "_Toc195948402" 3.1.3 Steering Committee  PAGEREF _Toc195948402 \h 17  HYPERLINK \l "_Toc195948403" 3.1.4 Project Manager  PAGEREF _Toc195948403 \h 17  HYPERLINK \l "_Toc195948404" 3.1.5 Project Team  PAGEREF _Toc195948404 \h 17  HYPERLINK \l "_Toc195948405" 3.1.6 Consultants and Contractors  PAGEREF _Toc195948405 \h 18  HYPERLINK \l "_Toc195948406" 3.1.7 Reference Groups  PAGEREF _Toc195948406 \h 18  HYPERLINK \l "_Toc195948407" 3.1.8 Working Groups  PAGEREF _Toc195948407 \h 18  HYPERLINK \l "_Toc195948408" 3.2 Reporting Requirements  PAGEREF _Toc195948408 \h 18  HYPERLINK \l "_Toc195948409" 3.2.1 Reports to the Steering Committee  PAGEREF _Toc195948409 \h 19  HYPERLINK \l "_Toc195948410" 3.2.2 Quality Consultants Reports  PAGEREF _Toc195948410 \h 19  HYPERLINK \l "_Toc195948411" 4 Stakeholder Management & Communication  PAGEREF _Toc195948411 \h 19  HYPERLINK \l "_Toc195948412" 5 Related Projects & Programs  PAGEREF _Toc195948412 \h 20  HYPERLINK \l "_Toc195948413" 6 Resource Management  PAGEREF _Toc195948413 \h 21  HYPERLINK \l "_Toc195948414" 6.1 Budget and Expenditure  PAGEREF _Toc195948414 \h 21  HYPERLINK \l "_Toc195948415" 6.2 Other Resources  PAGEREF _Toc195948415 \h 21  HYPERLINK \l "_Toc195948416" 7 Risk Management Plan  PAGEREF _Toc195948416 \h 21  HYPERLINK \l "_Toc195948417" 8 Quality Management Plan  PAGEREF _Toc195948417 \h 22  HYPERLINK \l "_Toc195948418" 9 Organisational Change Management & Outcome Realisation  PAGEREF _Toc195948418 \h 23  HYPERLINK \l "_Toc195948419" 10 Evaluation  PAGEREF _Toc195948419 \h 24  HYPERLINK \l "_Toc195948420" 11 Project Closure  PAGEREF _Toc195948420 \h 24  HYPERLINK \l "_Toc195948421" 12 Appendices  PAGEREF _Toc195948421 \h 25  Overview Purpose of Business Plan The Project Business Plan is the management document for the project. It is owned, maintained and utilised by the Steering Committee to ensure the delivery of project outputs and the realisation of project outcomes. The document will be reviewed and amended to meet changed conditions or objectives during the projects life span. Project Title Initiation & Background Briefly describe the reasons for establishing the project and how it was initiated. Summarise any relevant background information. This section may include an examination of the various options considered during the feasibility phase of the project. Additional information may be included in the Appendices. Objectives and Scope Objectives A project objective is a statement of the overarching rationale for why the project is being conducted. A project can have one or more objectives. They do not need to be measurable, and they should focus on what the project is going to achieve, rather than what is produced. A useful way to frame the objective is to answer the question 'why are you doing the project?' The result is a one sentence statement, or series of statements, starting with the word 'To'.... Project Objectives should be directly related to the Corporate Clients Corporate Objectives and the business driver(s) for the project. An Objectives Hierarchy illustrates the links between the projects activities and the client organisations goals and strategic direction, providing the context in which the project is being undertaken. Reporting on the projects relationship to these corporate objectives will become part of the focus of project closure. For example: Corporate Objective: To develop and maintain a best practice project management framework and methodology to be adopted across government Project Objective: To improve accessibility to, and quality of, information on project management tools and techniques and on available training for project participants. Corporate Objective(s) Project Objective(s) The objective(s) of the are : To To Outcomes Outcomes are the benefits or other long-term changes that are sought by undertaking the project. They are achieved from the utilisation of the project's outputs by project customers. If the outcomes are achieved then the project's objectives have been met. To define outcomes, ask what the project is going to achieve for the corporate stakeholders. While there is often one or more overarching outcomes/benefits sought from undertaking the project, it is important to isolate a small number of specific, quantifiable outcomes from within this. These Target Outcomes are what the project will be held accountable for. Target Outcomes have a measurable benefit and will be used to gauge the projects success. Target outcome measures will help answer such questions as 'what have we achieved?' and 'how do we know? Target Outcomes are expressed as a statement in the past tense and usually start with a word ending in 'ed. To make target outcomes quantifiable requires an analysis of the current situation, including a benchmark or baseline against which to measure, and a methodology for measurement. A pro forma for documenting Target Outcome Measures is provided at Appendix A. For example, broader outcomes may be: Improved standards for project management across the Tasmania State Service Increased knowledge and skills in project management methodology, through training and development covering all project participants Target Outcomes may be: Improved quality of information and resources relating to project management tools, techniques, processes and training needs for project participants Improved accessibility of information and resources relating to project management tools, techniques, processes and training needs for project participants Greater recognition of the PDMU as a source of high quality information and resources relating to Project Management. The broad outcome for the Project is: The Target Outcomes for the are: These Target Outcomes comprise performance information against which the project will be assessed and are detailed in Appendix A. Outputs Outputs are the products, services, business or management practices that will be required (produced) to meet the identified project outcomes/benefits. They may be new products or services, or revisions of existing operations. Outputs link with outcomes, in that the outputs are used by the project's customers to achieve the outcomes. Ask What new services, businesses, or management practices will need to be implemented to meet the identified outcomes. Output statements are kept as free as possible from system terms and are usually expressed as nouns. For example: A new financial management policy, procedures and standards manual A new legislation storage and access facility A decentralised enquiry and reporting facility for internal use Consider how stakeholders will utilise each output to achieve project outcomes. While there is never a direct one-on-one relationship, the use of a Customer Map can assist in identifying Target Outcomes and Outputs. This is provided at Appendix B. It is important to note that project documentation (such as a Project Business Plan or Risk Management Strategy) is not considered an output. Project documentation is the by-product of efficient project management. The following outputs are to be delivered by the project: The customer map at Appendix B illustrates the relationship between the utilisation of outputs and the achievement of outcomes. Scope of Work The scope of work is defined as a clear statement of the areas of impact and the boundaries of the work of the project. The following model will help to identify all of the project work that clearly falls within the scope of the project, that which is outside the scope, and any work that requires further consideration. Reviewing the Customer Map (see Appendix B) may assist in clarifying what is inside or outside the scope. Where the project is dependent on other work being completed (i.e. outside the scope of the project), agreement must be sought in terms of who is responsible and timelines for completion. At the time that the Project Business Plan is endorsed by the Steering Committee as Version 1.0, there should be no work that remains uncertain or unresolved it should be either inside or outside scope. Table 1: Scope of WorkPart of the Project (Inside Scope)Responsibility Not Part of the Project (Outside Scope)Responsibility Uncertain or UnresolvedTraining operational staff to use the new systemProject ManagerUpdating the induction manualsHR Sectiontimeline for completion Project Development Plan How is the development process to be undertaken to produce the project outputs? How will the Project Manager ensure that the projects development is on track? A Project Development Plan will set a course for the project and ensure that the projects progress can be monitored and reviewed by the Steering Committee. If the outputs are more complex, involving multiple teams, long periods of time, or dependent on the delivery of other outputs, a Project Development Strategy should be devised to ensure that the projects progress is systematically planned and reviewed. Depending on complexity, the development strategy may adopt a phased approach or may be planned in stages. The use of Gantt Charts to graphically represent the development of each phase or output against the timeframe may also be considered useful in this instance For medium sized projects, a Project Development Schedule, reflected chronologically as in the table below, listing major activities and milestones may be sufficient to set the projects course and monitor progress. Milestones are shown in bold and indicated by a blank scheduled start date, these are the dates identified during the initial planning stages for the projects key deliverables. The initial detailed Project Development Plan can be included as an appendix in this Project Business Plan. However, a working Project Development Plan should be maintained separately to avoid the need to continually re-release the Project Business Plan. Table 2: Project Development Schedule IdDescriptionWhoScheduled StartScheduled FinishPredecessor1Formal approval to commence project obtained1 July 2007-2Complete consultants brief for documentation of current processesProject Team1 July 20071 Aug 200713Document current processesConsultant1 Aug 20071 Sept 200724Review of present processes documentation with StakeholdersProject Manager1 Sept 200710 Sept 200735Investigate and develop enforcement methodology optionsProject Manager1 July 20071 Sept 200716Decide on preferred option for development of business processSteering Committee1 Oct 20075 Assumptions and Constraints It is essential that assumptions made during the planning process are recognised and recorded in the Project Business Plan along with any constraints. This process should also assist with risk identification, as both assumptions and constraints will reveal areas of risk for the project. Assumptions The project is dependent of the following assumptions: < enter list of assumptions eg resource availability, environment, technology, security etc> Constraints Major constraints have been identified as: Relevant Government Policy, Legislation and Rules Identify any government policies, legislation or rules and document their impact on the project. The successful completion of a project may depend on amending existing legislation, additional subordinate legislation (regulations), or development of a new Act. The required changes must be documented within the scope. A separate project may need to be established to manage the process. The timeline involved in developing new or amending existing legislation can be lengthy. Cabinet approval is required to draft legislation as well as to endorse the Bill for introduction to the Parliament. The timing of the introduction of legislation into the Parliament is at the discretion of Cabinet. Public consultations may be required, which can take several weeks. The drafting task may be complex and time consuming. Project Management Plan Governance The Projects governance structure is based on the Tasmanian Government Project Management Guidelines Version 6.0 prepared by the Department of Premier and Cabinet. The assessment and selection of people to perform the functions within an appropriate structure is critical to the projects overall success. A diagram to illustrate the specific structure of the is shown in Figure 1. This is a generic model and is used as an example only. Not all projects will include all of the entities listed. For more information on governance roles and varied models, please refer to the Tasmanian Government Project Management Guidelines, Chapter 3 and Glossary at HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au EMBED Word.Picture.8 EMBED Word.Picture.8 Figure 1: Governance Structure for the . Membership of the governance structure is specified in this section of the business plan. It may be prudent to include specific detail about roles, responsibilities, and accountability, under each title if it appears that such clarification will assist the project to run smoothly. Project Sponsor The Project Sponsor must be identified for all projects, no matter what the size or complexity. The Sponsor for the is: . Project Business Owners The Business Owner(s) must be identified for all projects, no matter what the size or complexity, even if they are the same entity as the Project Sponsor, or indeed the Project Manager, as they have a significant responsibility for ensuring outcome realisation. The Business Owner(s) for the is (are): . Steering Committee For further details on the roles of the Steering Committee and individual Steering Committee members, refer to the Tasmanian Government Project Management Guidelines - Appendix 2: Steering Not Rowing: A Charter for Project Steering Committees and Their Members. The Steering Committee is comprised of: (Project Sponsor); ; ; etc.. Project Manager The Project Manager must be identified for all projects, no matter what the size or complexity. The Project Manager is contracted by the Project Sponsor and Steering Committee to deliver the defined project outputs. They are responsible for organising and managing the day-to-day aspects of the project, developing the Project Execution Plan(s), resolving planning and implementation issues, and monitoring progress and budget. The Project Manager will: Develop and maintain the Project Business Plan and a Project Execution Plan(s) Manage and monitor the project activity through detailed plans and schedules Report to the Project Sponsor and Steering Committee at regular intervals Manage (client/provider/stakeholder) expectations through formal specification and agreement of goals, objectives, scope, outputs, resources required, budget, schedule, project structure, roles and responsibilities The Project Manager for the Project is: . Project Team The core Project Team will be: Consultants and Contractors Refer to the Tasmanian Government Project Management Guidelines Version 6.0 - Appendix 3: A Charter for Project Management Quality Advisory Consultants, and Appendix 4: A Charter for Project Management HYPERLINK "http://www.projectmanagement.tas.gov.au/guidelines/pm6_14appx4.shtml"Quality Review Consultants, for further information. Note: The Head of Agency or Deputy Secretary (or equivalent) must approve any decision to engage a consultant prior to the Agency undertaking the appropriate procurement process. Refer Treasurers Instruction 1113 (22 Dec 2006) this details the protocol that agencies must use for the engagement and use of contractors (including consultants). For more information see HYPERLINK "http://www.treasury.tas.gov.au"www.treasury.tas.gov.au Quality Advisory Services will be rendered by for . Quality Review Services will be rendered by for . Consultancy Services for will be rendered by . Contracting of services for will be rendered by . Reference Groups It is proposed that a Reference Group will be established for . It will comprise: Working Groups It is proposed that a working group will be established for . It will comprise: Reporting Requirements It is important to clarify frequency and reporting relationships to governance groups. The reporting relationships should be consistent with stakeholder communication and management processes and where possible minimise the reporting effort by utilising one report for many purposes. In some cases, the Project Manager may be required to report to bodies outside the Project Governance structure, for example in cases where the project is utilising Commonwealth funding, or the Communication Strategy includes regular reporting to stakeholder groups. Such requirements should be clearly documented in this section. Table 3: Reporting requirements for the Project: Reported byTo whomReporting requirementsFrequencyFormatProject ManagerSteering CommitteeStatus ReportMonthlyWritten and verbalProject ManagerReference Group Status ReportMonthlyWritten and verbalProject ManagerCommonwealth Status ReportMonthlyWritten and verbalQuality ConsultantSteering CommitteeStatus ReportMonthlyWritten and verbal Reports to the Steering Committee A summary of content for the status report should be agreed upon through the Business Plan. A template and guide for producing a Project Managers Status Report is available at HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au (Note that milestones for reporting purposes should reflect those listed in Section 2.5 - Project Development Plan as well as those in the operational Project Work Plan.) The Project Managers regular status report to the Steering Committee will address the following: Status of the project Milestones for the last reporting period Milestones for the next reporting period Milestones for the remaining period of the project Budget report (with respect to planned expenditure, actual expenditure and the reasons for any deficit/surplus); Issues report (including areas of concern, specific problems, and any action that needs to be taken by the Steering Committee); and Risk management report (which will specify any new risks, or changes to the major risks identified since the previous report and modification to the strategies put in place to manage them). Quality Consultants Reports The Quality Consultants reports provide independent feedback to the Steering Committee on issues such as the development of contractual documentation; compliance with internal and external audit requirements; quality of performance, and technical expertise, including the application of Project Management processes. Quality Consultants Reports will be provided for: Stakeholder Management & Communication This section of the Project Business Plan outlines the framework by which communication and management strategies will be established and conducted for the projects stakeholders/stakeholder groups. The stakeholder management strategies adopted may be formal, informal, detailed or broad, dependent on the needs of the project and what is most appropriate for each group of stakeholders. A stakeholder management and communication framework may need to include: A stakeholder analysis. This is a process of stakeholder identification and classification, which describes the nature of stakeholder interests (ie whether they will impact or be impacted by the project) and how they will be engaged. See Appendix C. A summary of the overall key communication and management issues/concerns for the project For more complex projects, a Stakeholder Communication Strategy, which can be a stand-alone document. It will contain details of key issues, communication approaches, management methods, and milestones for communication activities The Tasmanian Government has developed a Whole of Government Communications Policy and Tool Kit that provides detailed information templates and tools in this area. Refer to HYPERLINK "http://www.communications.tas.gov.au"www.communications.tas.gov.au for more information. A stakeholder analysis has been completed and is provided at Appendix C. This document outlines the intended communication activities to engage stakeholders. The key communication and stakeholder management issues for this project are: Related Projects & Programs Related projects (or major change initiatives) within the Division and/or Department can be of significance to the project. Representatives of these projects should be involved in project planning sessions. It is important to establish both the type and nature of the relationship between the projects. The type of dependency refers to whether: A related project is dependent on, or interdependent with this project, or Whether this project is dependent on another project. And if so, how and why. The nature of a dependency can include a shared relationship with data, functionality, staff, technology/infrastructure, funding, policy and/or legislation. This information should be reflected in other relevant sections of this Business Plan, including Assumptions and Constraints (Section 2.6), Stakeholder Management & Communication (Section 4) and Risk Management (Section 7). Other projects that are interdependent to the Project are: Resource Management Budget and Expenditure Identify and summarise the projects funding sources, budget and expected expenditure in line with the project plan and financial planning. The budget information can reflect funding for the life of the project, a specific Stage or Phase, or a single financial year. The fields indicated in the Detailed Budget table below, are standard reporting items on Finance 1. Where the project draws on multiple funding sources (eg Commonwealth and State funds), a separate budget analysis should be provided for each source. Where the project is beginning the transition to operational mode, Business Owners will be required to commit the level of recurrent expenditure required for ongoing maintenance of the outputs. For information on financial management within your Agency, contact your Finance branch or equivalent. For additional information on purchasing, procurement, common use contracts and related Department of Treasury and Finance publications, go to HYPERLINK "http://www.purchasing.tas.gov.au"www.purchasing.tas.gov.au. A working budget and current expenditure documents would be maintained separately to avoid the need to continually re-release the Project Business Plan. Funding Sources Department of (Tasmanian Government)$ Department of (Australian Government)(plus)$ Total project funding(equals)$  Project Budget Overview Total Project fundingeg: 4 year project$ Expenditure for (minus)$ Expenditure for (minus)$ Remaining budget for life of project(equals)$ Preliminary allocation for $ A detailed working budget table is attached at Appendix D Other Resources List other resourcing requirements, for example accommodation, IT equipment and information requirements. Risk Management Plan The purpose of risk management is to ensure levels of risk and uncertainty do not impede the success of the project. Any potential threat to the delivery of outputs (level of resourcing, time, cost and quality) and the realisation of outcomes/benefits by the Business Owner(s) needs to be properly managed. All projects require a risk assessment to be undertaken upon commencement, which is regularly reviewed throughout the project life, using the following process: Identification - The assumptions and constraints identified in Section 2.6 should be included where relevant Analysis grading risks in terms of likelihood and seriousness (see Appendix 5) Evaluation determining which risks require priority action Mitigation preventative and contingency planning, including accountability Monitoring & Review determining a strategy to keep abreast of risk related issues Please refer to the Risk Identification Tool included in the Tasmanian Governments Risk Management Resource Kit for further assistance: HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au. It may be prudent to discuss any political risks with the Project Sponsor prior to documentation. A Risk Register (see Appendix D) is an essential chart to include in reports to convey a snap-shot of current risks and management strategies for smaller scale projects. However, for more complex projects, an additional standalone Project Risk Management Plan may be necessary. Such documents can be maintained separately to avoid the need to continually re-release the Project Business Plan. A Risk Register is provided at Appendix . This lists all risks identified, and the proposed action for each risk at this point in time. The grading system used to analyse and evaluate risk priority is also described here. The following risks have been graded extreme/Grade A: The process used to identify risks for the project is: Relevant assumptions and constraints identified in Section 2.6 have been incorporated. Persons involved in risk identification are: Risks will be reviewed by Reports will be provided to Quality Management Plan The Quality Management Plan details how the quality processes will be implemented. The purpose of quality management in projects is to ensure that the project outputs are delivered fit-for-purpose. If outputs are not fit-for-purpose, there is every likelihood that planned project outcomes will not be realised, or realised to a much lesser extent. It can be achieved by developing quality criteria for the outputs themselves (quality control) and by ensuring that all project management processes are conducted in a quality manner (quality assurance). While it may be developed as a separate standalone document, the Quality Management Plan should address the following components in summary in this section of the Business Plan. Methodologies and Standards Monitoring and Reporting Risk Assessment and Management Issues Register Management Information Management Output Quality Organisational Change Management & Outcome Realisation Once a project delivers its outputs to the Business Owner(s), these outputs must be utilised effectively by the Project Customers to enable the projects outcomes/benefits to be realised. This requires a clear understanding of the organisational change that will occur, and the path to outcome/benefits realisation. Organisational Change Management refers to the management of realigning an organisations practices and processes to meet the changing demands imposed by the delivery and utilisation of project outputs. Outcome Realisation refers to the management of the utilisation of outputs to meet the specified outcomes, and bring about longer term benefits. In this section, it should be specified how outputs will be managed once they are delivered, how outcomes are to be achieved, and who will be accountable. This may change throughout as the project evolves, so a standalone Outcome Realisation Plan should be developed (see template and guide at HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au ). Outline the following details in this section: Who are the outputs going to be handed over to (ie. Business Owner), and how? Describe the new roles and responsibilities for staff positions, if any are required. Who will be responsible for any ongoing costs (eg. software licenses)? Are any outputs outstanding and has a delivery timeframe been agreed? Who has responsibility for any changes to ensure the transition is managed properly? What are the training requirements? What ongoing output maintenance arrangements have been made/are required once the project is completed? Will there be any contracts that require ongoing management, if so, by whom will they be managed? At what point will the project be closed? How will you establish that the project has been successfully completed? What form of evaluation of the project will be undertaken? Who is responsible for monitoring progress and reporting towards outcome realisation once the work of the project team is finished? The following measures will be undertaken to ensure outcome realisation: Evaluation Regardless of the size or complexity of the project, measurement of the projects success against well-defined criteria is necessary. Establishing criteria helps with the measurements taken during the project and after the project has finished. These measurements include determining whether key performance milestones are being met, how well managed the project is, and whether the specified project outputs have been delivered and the outcomes realised. Consider the following: The timing for any reviews, which may be conducted at the end of a phase or each and every phase, and/or after all outputs have been delivered prior to the project being closed. What each review(s) will cover, for example: A technical review of the outputs from the project; A review of the success of the project; A review of the processes used to produce the outputs; Lessons learnt from the project; or A combination of the above. Who is responsible for arranging and managing the review(s)? Who will perform the review(s)? Who is responsible for the post implementation review process? Who will the report(s) be delivered to? Who is responsible for accepting the reports produced by the process? Will all relevant stakeholders be included within the review process? What action will be taken once the report(s) have been received? At what point will the project be closed and what will be done to formally close the project? Ideally, an independent body conducts these types of review and the cost for the reviews should be included in the project budget. Refer to the HYPERLINK "http://www.projectmanagement.tas.gov.au/guidelines/pm6sum.htm"Tasmanian Government Project Management Guidelines and the Project Management Template: Project Review and Evaluation at HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au for more information. Project Closure Projects can be closed because they are completed successfully, or because it is clear the proposed benefits of the project are unlikely to be attained or are unlikely to be relevant in the current organisational context. To gain formal acceptance of project outputs, and confirm the realisation of the outcomes, the closing down of a project should be planned using the following formal Project Closure steps: Business Owner(s) acceptance of project outputs Issues Management Risk Management Project Team disbandment Financial Management Asset Management Post Project Responsibilities Post-project Review Outcome Realisation Reporting Formal closure by Project Sponsor/Steering Committee and disbanding the Steering Committee It is advised that a Project Closure Report be developed as a standalone document. Refer to the Tasmanian Government Project Management Guidelines and the Project Management Template: Project Closure Report at: HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au for more information. The project will be closed upon completion of the following: Appendices Appendices are usually documents that are either One-off forms used within the projects scoping process (eg objectives /stakeholder relationship); or Templates that become working documents in their own right, as they will be updated and managed during the life of the project (eg risk register or project schedule); or Additional information provided to support the summary content within the Project Business Plan (eg. project management methodology). The Appendices provided here are for guidance only. Other documentation should be included as appropriate. The following documents and forms are attached to the Project Business Plan as appendices to enhance or meet specific project requirements: Appendix A Target Outcomes Measurement Appendix B Customer Map Appendix C Stakeholder Analysis Appendix D Budget Analysis Appendix E Risk Register < DOCPROPERTY strProjectTitle \* MERGEFORMAT Project Title> Project Business Plan Version No: Date: Target Outcomes Measurement Target OutcomePerformance IndicatorMeasureBaselineTarget LevelCompletion DateAccountabilityThe measurable benefits that are sought from undertaking a project.The measure that will be used to indicate the level of achievement of the outcome(s).The actual mechanism for measuring the level of the performance indicator.The current level of the performance indicator.The targeted level of performanceThe date by when the target levels are to be achievedWho is accountable for the achievement of the targeted outcome(s) and reports on the progress towards the target?123 < DOCPROPERTY strProjectTitle \* MERGEFORMAT Project Title> Project Business Plan Version No: Date: OUTPUTS  1 Name(s) of customer(s) who will utilise the output on the left to generate the outcome at the top Name(s) of customer(s) who will utilise the output on the left to generate the outcome at the top Name(s) of customer(s) who will utilise the output on the left to generate the outcome at the top2    < DOCPROPERTY strProjectTitle \* MERGEFORMAT Project Title> Project Business Plan Version No: Date: Stakeholder Analysis #Ref CodeStake-holderKey or Non KeyNature of stakeholdingKey issues for projectEngagement and commitment processPlanned action detailed in?Who?a) What potential impact does the stakeholder have on the project? b) What potential impact does the project have on the stakeholder?How will we engage this stakeholder and gain their commitment?eg. Communication Plan Risk Register Issues Register Change Mgt Plan Work plans Budget Resources Action List(Project example:. Building a Community Hall) 1 Unhappy neighbourKeya) Lobby against vandalism b) DisturbedProject can be disrupted or delayedSet-up Neighbourhood Consultative Committee One-on-one Involve champion in consultation Protect siteWBS Action List Communication Plan Risk RegisterProject Manager Marketing Consultant Contractor123 < DOCPROPERTY strProjectTitle \* MERGEFORMAT Project Title> Project Business Plan Version No: Date: Budget Analysis Items in this list are intended as example only. Delete items from the following table as required. Operating Expenses FY $,000FY $,000Salary Salary and Related ExpenditureOther Employee related expensesTotal for salaries and other related expenditureTotal Salary (1)Operating CostsRent and Accommodation related expensesCommunicationsTravel (including motor vehicle expenses)Advertising and promotionConsultanciesInformation TechnologyOther administrative expensesTotal Operating Costs (2)Capital ExpenditureConstruction ProgramOther CapitalTotal Capital Expenditure (3)Total Expenditure (1)+(2)+(3) < DOCPROPERTY strProjectTitle \* MERGEFORMAT Project Title> Project Business Plan Version No: Date: Risk Register IdDescription of Risk Impact or consequenceLikelihood/ SeriousnessGradeChangeMitigation Actions (Preventative or Contingency)Individual/Group Responsible for Mitigation ActionTimeline for Mitigation ActionRefer to the assumptions and constraints identified during the planning process, as listed in Section 2.6, as they often indicate risks to project success. Review of the Workplan or Work Breakdown Structure will also reveal areas of risk Key to Risk Rating Symbols used: Rating for Likelihood and Seriousness for each riskLRated as LowERated as Extreme (Used for Seriousness only)MRated as MediumNANot AssessedHRated as High Grade: Combined effect of Likelihood/SeriousnessSeriousnessLikelihoodlowmediumhighEXTREMElowNDCAmediumDCBAhighCBAA Recommended actions for grades of riskGradeRisk mitigation actionsAMitigation actions to reduce the likelihood and seriousness to be identified and implemented as soon as the project commences.BMitigation actions to reduce the likelihood and seriousness to be identified and appropriate actions implemented during project execution.CMitigation actions to reduce the likelihood and seriousness to be identified and costed for possible action if funds permit.DTo be noted - no action is needed unless grading increases over time.NTo be noted - no action is needed unless grading increases over time. Change to Grade since last assessmentNEWNew risk(Grading decreasedNo change to Grade(Grading increased  For a definition of common terms, refer to the Tasmanian Government Project Management Guidelines, Appendix 1: Project Management Glossary  For more information on project development strategies, see the Project Business Plan (Large) Template & Guide, and the Project Phase Review Report Template & Guide available at HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au.  Please see Project Management Fact Sheet: Developing a Gantt Chart at HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au  Activities in the Predecessor column must be completed prior to this activity commencing.  A template for Project Execution Plans can be found at HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au  For more information please refer to The Tasmanian Government Project Management Guidelines Chapter 9, and the Project Business Plan (Large) Template & Guide available at HYPERLINK "http://www.egovernment.tas.gov.au"www.egovernment.tas.gov.au   PM 904 Project Business Plan (medium projects): Guide Tasmanian Government Project Management Framework<>  PAGE \* MERGEFORMAT ii Inter Agency Policy and Projects Unit Department of Premier and Cabinet  PM 904 Project Business Plan (medium projects): Guide Tasmanian Government Project Management Framework<>  PAGE \* MERGEFORMAT iv Department of  PAGE \* MERGEFORMAT 10  STYLEREF "Document Title" \* MERGEFORMAT Project Business Plan  STYLEREF "Document Version No" \* MERGEFORMAT  Page  PAGE 1 of  NUMPAGES 36  STYLEREF "Heading 1" \* MERGEFORMAT Appendices Project Business Plan Version Copy: Uncontrolled Page  PAGE \* MERGEFORMAT 26  STYLEREF "Project Name" \* MERGEFORMAT Error! No text of specified style in document.  STYLEREF "Report Name" \* MERGEFORMAT Error! No text of specified style in document. Page  PAGE 28  STYLEREF "Heading 7" \* MERGEFORMAT Target Outcomes Measurement Project Business Plan Version Page  PAGE \* MERGEFORMAT 27  STYLEREF "Heading 7" \* MERGEFORMAT Customer Map Project Business Plan Version Page  PAGE \* MERGEFORMAT 29  STYLEREF "Project Name" \* MERGEFORMAT Error! No text of specified style in document.  STYLEREF "Report Name" \* MERGEFORMAT Error! No text of specified style in document. Page  PAGE 30  STYLEREF "Heading 7" \* MERGEFORMAT Stakeholder Analysis Project Business Plan Version Page  PAGE \* MERGEFORMAT 31  STYLEREF "Project Name" \* MERGEFORMAT Error! No text of specified style in document.  STYLEREF "Report Name" \* MERGEFORMAT Error! No text of specified style in document. Page  PAGE 31  STYLEREF "Heading 7" \* MERGEFORMAT Budget Analysis Project Business Plan Version Page  PAGE \* MERGEFORMAT 33  STYLEREF "Heading 7" \* MERGEFORMAT Risk Register Project Business Plan Version Page  PAGE \* MERGEFORMAT 36 $%&-/0KLMXY 6 c v z { ¾±񏱏zvnh{2Jhob>*h>hWp h>0J h>0J hob0JjhobU h0Jhh0J5hhob0J5hWp hob0JhJ!h/ hhobhhh6 h6hhob6hh6 hhobhobh'hobCJ,aJ$)/0CY> gd>gd>gd5o X^gdsgd6gd2Nx$`]`^`a$gds "S2E$gdw$gd$$ & F Vd[$^`Vgdx*$$ & F Vdx[$\$^`Vgdx*wgd{gd5owgd5ogd> 56"$9Yi:OJKk !6>?{#39N|}hh2N6]^Jhh2N^J hUhob0J"B*\^JphhUhobB*^Jph hJ56^Jh hob^Jhhob6]^Jh{2Jhob>*h/jhhobH*U^JhJ5hob6^Jhhob^J3E JKk||}2$$ & F Vdx[$\$^`Vgdx*$$ & F Vd[$^`Vgdx*$$ & F Vdx[$\$^`Vgdx*wgd$$ & F Vdx[$\$^`Vgdx*}CDEoz K`dpqx'78;<kl枚攊vlvhJ5h/5^Jhh/^Jh22hJ50J"^JjhJ5U^J hJ5^Jh h^JhAzhob5\]^Jh2Nhob5^JhJ5hob6^Jh4h/hhob6]^J hh hob^Jhhob^Jh{2Jhob>*h{2Jh2N>*)DEo G [$\$gd/$gdwgdgd5owgd5o$$ & F Vd[$^`Vgdx*wgdgd$$ & F Vd[$^`Vgdx* W!!!!)"G"M""""""####[###$^$h$i${$|$$$$$$$$$B%D%E%F%~%%%%%%%%ѶǬǬצ||hJ5hAhob0JhAhobhZhob5 h{2Jhob h4^J hob^JhJ5hA6^JhJ5hJ56^J hJ56^JhJ5hob6^J hJ5^Jhhob^Jh{2Jhob>* h/^Jhh/^Jh3.eh/0J0 X!!!!I""#$$$r$$ & F d[$^gd4$$ & F Vd[$^`Vgdx*gdJ5w V^`Vgd5o$$ & F d<[$\$^gd/$$ & F d<[$\$^gdx*$$ & F <\$^gdx* $$%@%z%%%%%)&?&zq $Ifgd% $Ifgd2KBkd$$Ifl"&& t&644 la $IfgdPgd4 $ & Fd[$gdx*$ & F^`gdx*\$gdAgd4 %%%%%%%&&'&(&)&>&?&@&'$(%(R(S(m(n(o(p(q(~(((((((((()@)))****/*0*]*^*中|u hob6]h+hob6]hhob6] hhob hi/h2NhKh2N hi/hobh5ohobCJaJhZrhob0Jh{hob0JCJhZrhob0J6 h%hob h/hobjhobU hThobh45\^Jhob.?&@&'o(p(q(r(((_ZQH $Ifgd2N $Ifgd5ogd5oBkd$$Ifl,"&& t&644 la $$Ifa$gdX0 $Ifgd5oEkdM$$Ifl;"&& t&644 laytX0(((()@)*z*{*|*}*]Xgd|@kd5$$Ifl"&& t&644 la $Ifgd5o $IfgdK $IfgdKgd5o@kd$$Ifl"&& t&644 la ^*x*y*z*{*|************++&+'+(+/+?+c+p+++,,,,`,a,,,,,,,,, --- -!-3-4-6-7-9-:-H-v-~-----ĽĽ᫝h6Ahob56CJaJh6AhobCJaJ h#hob h#hh h5ohobh/ h2hob hi/hobhob hob6]jhobUhlhob0J"6];}**W+a,,,,,,,,,, <$Ifgd}Ngd}Ngd{gdy ,,,,-90$$ <$$Ifa$gd <$Ifgd}Nkd}$$Iflִb "#&856 t6    44 lalyt5o------- -zn <$$Ifa$gd5o|kd$$Ifl1\b&8 t644 lalyt5o <$Ifgd}N -!-+-,-2-3-5-6-8-9-zzzzzzzz <$Ifgd}N|kdG$$Ifl1\b&8 t644 lalyt5o 9-:-H-f--90$$ <$$Ifa$gd <$Ifgd}Nkd$$Iflִb "#&856 t6    44 lalyt5o------------zuupggggg 3$Ifgd}Ngd}Ngdy|kd$$Ifl1\b&8 t644 lalyt5o <$Ifgd}N ---..K@-$ <$Ifgd}N"$If^"`gd3.e $Ifgd6Akd$$Iflr9s& t0644 lalyt6A--. .}.......0/7/^/_/////////////////////00߹㚊{n{{eh/5OJQJj h/Ujh/U h/jt hh/0J"Uhh/0J"jhh/0J"Uh$>hob0Jjh$>hob0JUh7 hob\h6Ahob6h3.ehob0Jhobh/h3.ehob0J5CJaJhob56CJaJ$..*.../.K.B=gd}Nkdx$$Iflr9s& t0644 lalyt6A <$Ifgd}NK.Y.h.z.{.|.}..h___ <$Ifgd}NkdD$$IflFd^&t t06    44 lalyt5o 3$Ifgd}N.......qlcccc 3$Ifgd}Ngd}Nkd$$IflFd^&t t06    44 lalyt5o...../^UUUU <$Ifgd}Nkd$$Ifl\3 0~&l/F t0644 lalyt5o//////^UUUU <$Ifgd}Nkdd $$Ifl\3 0~&l/F t0644 lalyt5o//////^UUUU <$Ifgd}Nkd( $$Ifl\3 0~&l/F t0644 lalyt5o//*/0/=/J/^UULU <$Ifgd/ <$Ifgd}Nkd $$Ifl\3 0~&l/F t0644 lalyt5oJ/K/L/^//B000P11^YYWUUUWUA=gd|kd $$Ifl\3 0~&l/F t0644 lalyt5o 0000 0!0;0<0=0?0@0A0B0C0D0`0a0b0c0t0u0v00000000000000000000000000ԽٯٟԒٯقujh/Ujbhh/0J"Ujh/Ujhhh/0J"Uh/h/OJQJaJj h/Ujh/U h/hh/0J"jhh/0J"Ujn hh/0J"U.01111-1.1/1I1J1K1M1N1O1P1Q1R1n1o1p1q11111111111111111111111Ѻֱє֊zmjh/UjPhh/0J"Uh/OJQJaJjh/UjVhh/0J"Uh/5OJQJjh/Ujh/U h/jhh/0J"Uj\hh/0J"Uhh/0J"h/*1122222 2!2"2#2=2>2?2Y2Z2[2]2^2_2`2a2b2~222222222222222222222222ѽѠyj>hh/0J"Uh/OJQJaJjh/UjDhh/0J"Ujh/UjJhh/0J"Uh/hh/0J"h/OJQJ]jhh/0J"Ujh/U h/.12`222T334l44:555B666X778m88#999`::;x;;)<=A222222233333 3132333M3N3O3Q3R3S3T3U3V3r3s3t3u3333333333333333333İēvj,hh/0J"Ujh/Uj2hh/0J"Ujh/Uj8hh/0J"Uh/hh/0J"h/OJQJaJjhh/0J"U h/jh/Ujh/U.3344444444454647484I4J4K4e4f4g4i4j4k4l4m4n4444444444444444444İךĊ}ךjh/Uj hh/0J"Uh/OJQJ]jh/Uj&hh/0J"Uh/hh/0J"h/OJQJaJjhh/0J"Ujh/U h/jh/U,444555354555758595:5;5<5X5Y5Z5[5t5u5v5555555555555555555555ԽٯٟԒٯyljh/Ujhh/0J"Uh/5OJQJjh/Ujhh/0J"Uh/h/OJQJaJjh/Ujh/U h/hh/0J"jhh/0J"Ujhh/0J"U*5555566 6 66 6!6;6<6=6?6@6A6B6C6D6`6a6b6c66666666666666666666ߌ߼o߼jhh/0J"Ujh/Ujhh/0J"Uh/OJQJ]jh/Ujh/U h/hh/0J"\jhh/0J"Uh/hh/0J"h/OJQJaJjhh/0J"U+6666666677777 7576777Q7R7S7U7V7W7X7Y7Z7v7w7x7y777777777777777777İēvj"hh/0J"Ujm"h/Uj!hh/0J"Ujs!h/Uj hh/0J"Uh/hh/0J"h/OJQJ]jhh/0J"Ujh/Ujy h/U h/.777 8 8888888818283848J8K8L8f8g8h8j8k8l8m8n8o88888888888888888888İēvj%hh/0J"Uj[%h/Uj$hh/0J"Uja$h/Uj#hh/0J"Uh/hh/0J"h/OJQJ]jhh/0J"Ujg#h/Ujh/U h/.88999999 9!9"9#9$9%9A9B9C9D9k9l9m99999999999999999999999999::|jI(h/Uj'hh/0J"Uh/OJQJ]jO'h/Uj&hh/0J"Uh/h/OJQJaJjU&h/Ujh/U h/hh/0J"jhh/0J"U/:::=:>:?:Y:Z:[:]:^:_:`:a:b:~:::::::::::::::::::::::;;;;;;;;;Խٰ٠ԓٰكvj7+h/Uj*hh/0J"Uj=*h/Uj)hh/0J"Uh/h/5OJQJjC)h/Ujh/U h/hh/0J"jhh/0J"Uj(hh/0J"U.;8;9;:;;;U;V;W;q;r;s;u;v;w;x;y;z;;;;;;;;;;;;;;;;;;;;;<<<"<#<$<&<'<(<Ѻְѓְvj%.h/Uj-hh/0J"Uj+-h/Uj,hh/0J"Uh/OJQJaJj1,h/Ujh/U h/jhh/0J"Uj+hh/0J"Uhh/0J"h/-(<)<*<+<G<H<I<J<c<d<e<<<<<<<<<<<<<<<<<<<<<===== =!="=#=0=1=2=L=M=N=P=ǽǰǽǽǓǽǽvj1h/Uj0hh/0J"Uj0h/Uj/hh/0J"Uj/h/Ujh/U h/j.hh/0J"Uh/hh/0J"jhh/0J"Uh/5OJQJ.)<<=S=====>>?z????@@@AB & F |^`|gdx*gd/gdtgd7Y. & Fgdx*gdt & F z^`zgdx* & Fgdx*@&gd<=P=Q=R=S=T=U=q=r=s=t==============================>q>>?׾ס׾|u|u hhobhob h2hobjh$>hob0JUj3h/Uj2hh/0J"Uj 2h/U h/j1hh/0J"Uh/hh/0J"h/5OJQJjhh/0J"Ujh/U*?y?z???????@@@ADD=EREmEnEEEEFF>FBFWFdFeFfFgFpF}FFFFFFFFFFվ恔wwkh.hob6]^Jhxhob]^Jhhob6^Jhxhob^J hob6^J hhxhxh[Rph40J h[Rp0Jh[Rph[Rp0Jh[Rphob0J h/hob hob0J6hthob0J6 hCxhob hhobhob hob^Jhhob^J)BDD?EEFBFWFFFFFF+HlJoKKgdG & F z^`zgdx*^gd'* & F gdx*gdt & F |1$^`|gdx* p^p`gd[Rpp[$^p`gd[Rp\$gd[RpgdtF,GoK{KKKKKKKKeLfL~LL+MMM&N'N8NBNON^NkNmNNNNNNNNNhOjOrOOPQQQϷϨtpi hG0J6hobhhob6]^Jhob6]^Jhhob^Jh/hob^J h/hob hob^J h ^JhGhx0JhGhG0JhGh[Rp0J hob0JhGhob0J hG0J h 0J h[Rp0Jhthob0J6hbhob0J56)KKfL~LMM'N]NmNNNNiOjOrOQQ  \$gdt  gdt$ & F zd\$^`zgdx* & F gdx* & F gdx*gdtgdG & Fgdx*QQ R`RXS/TiTTBUCUQUVXXX $IfgdL$ & F zd\$^`zgdx*gdt & Fgdx*gdt & F ^`gdx* & F [$\$^`gdx*QR"R_R/TiTjTTTQUqUUWWXXXXXXXXX YY2Y3YYYYyZZZZZ[[[[[}\жۯ۩۩ۯЎzszm hob0J hob0J5hbhob0J5hQhob0J5hthob0Jh'*hob0Jh/hob0J hob^J hhob hhhob hob0J6hbhob0J56hob h/hobhhob^Jhhob6^Jhthob0J6 hG0J6(XXXX YY2Y 3$Ifgdb 3$Ifgdtjkd3$$Ifl4## 0#644 lalf4ytL2Y3Y kd&4$$Ifl4r:Wt#           20#644 lalf4p2ytL3YdYtYuYvYwYxY;kd5$$Ifl4r:Wt#0#644 lalf4ytL <$$$Ifa$gdtxYyYzYYYYY;kdg6$$Ifl4r:Wt#0#644 lalf4ytL <$$$Ifa$gdtYYY[[] ]^______``"`#`Ff8 $$Ifa$gdtgdt\$gdt$[$\$^gdQ[$\$^gdt$ & F zd\$^`zgdx* gd'*}\~\]]]=]Y]^ _+_2_3_>_?______ `!`#`b`c```aayazaaaaaaaAb_bcccd+dTdξΉ{qhhob6^J h/hob hob6^J hhob hob6]hob56\]#jhAhob6H*OJQJUhob hhhobhhob^J hob0J6hthob0J6hQhob0J5 hob0Jhthob0JjhQhob0JH*U+#`%`R`S`T```b` $Ifgdt $$Ifa$gdtb`c`e``8,# $Ifgdt $$Ifa$gdtkd:$$Ifl4ֈ~ Vu& 0644 laf4ytt````` $$Ifa$gdQ $$Ifa$gdt````8,# $Ifgdt $$Ifa$gdtkd;$$Ifl4ֈ~ Vu& 0644 laf4ytt``a aa $$Ifa$gdtaaaNa8,# $Ifgdt $$Ifa$gdtkd<$$Ifl4ֈ~ Vu& 0644 laf4yttNa^ajawaya $$Ifa$gdtyaza|aa8,# $Ifgdt $$Ifa$gdtkdn=$$Ifl4ֈ~ Vu& 0644 laf4yttaaaaa $$Ifa$gdtaaa b8,# $Ifgdt $$Ifa$gdtkdK>$$Ifl4ֈ~ Vu& 0644 laf4ytt b3b4b?bAb $$Ifa$gdQ $$Ifa$gdtAbBbCb83gd'*kd(?$$Ifl4ֈ~ Vu& 0644 laf4yttCb_bcccd+dVddddZfhh'hik+kgdqUC$ & F |dd[$\$^`|gdx*gdqUC^gd'* & Fgdx* & F |1$^`|gdx*gdt$ & F zd\$^`zgdx*TdVdqdddddh'hZhhYiZiiiiiijjjjjjkkkk'k(k)k*k+k,k@kƿ܂uf\hhob]^JjhhobU]^Jj@hhobU^JjmpK hhobUV^JjhhobU^JhHhob^JjhobU h/0JhHhob0J hob0J6hHhob0J6hhob6]^Jhhob^JhqUChob0J6 hhobhob hob^J"@kAkBkCkDkek{k|kllmmImKmLmdmjnnnnnnnnoop p%p&p6p7p?DͶȮͶѶѶ͖͞Ȗ h)ThobhUhob6h)Thob^J hob0J6hG,hob6h}hob0J6hhob6 hob6hobjhobUhqUChob0J6hob0J56CJaJhqUChob0J56CJaJ8ZÐXh $$Ifa$gd} $$Ifa$gd_qy $Ifgd_qy & Fgd}gd}$ & F zd\$^`zgdx*$ & F |dd[$\$^`|gdx* ^gd'*  & Fgdx* gd} ĔȔz $$Ifa$gd} $$Ifa$gd_qy $Ifgd_qydkd$$IflFp#$ p#6    44 lalyt_qyȔɔߔz $$Ifa$gd} $$Ifa$gd_qy $Ifgd_qydkd"$$IflFp#$ p#6    44 lalyt}/2xl $$Ifa$gd} $$Ifa$gd_qy $If[$gd_qy & Fgd}dkd$$IflFp#$ p#6    44 lalyt}23X`dtk__ $$Ifa$gd_qy $Ifgd_qykd($$IflFp# 0p#6    44 lalyt}detk__ $$Ifa$gd_qy $Ifgd_qykdޖ$$IflFp# 0p#6    44 lalyt}ŕɕtk__ $$Ifa$gd_qy $Ifgd_qykd$$IflFp# 0p#6    44 lalyt}ɕʕ˕͕̕tk__ $$Ifa$gd_qy $Ifgd_qykdX$$IflFp# 0p#6    44 lalyt}͕Εtk_S $$Ifa$gd} $$Ifa$gd_qy +$Ifgd_qykd$$IflFp# 0p#6    44 lalyt}>?OϖtoogobE$ & F |dd[$\$^`|gdx*gd & Fgdx*gd}kdҙ$$IflFp# 0p#6    44 lalyt}DOϖBO`akǚȚ},@FOs۝"*,;h'Hhob6 hhMK hhi hMK6 hi6 hob0Jh8hijhobUh_qyhob0J56h}hob0J56h'Hhob0J56 hhob hob0J6h}hob0J6hob4ϖa?w,e<Cgd_qy$ & F |dd[$\$^`|gdx*$$ & F 7\$gdMK # & F SgdM & Fgdx*gdU5 & Fgdx*gd}ţ>ɥ[ͧΧѧҧ7ũ&'2HfDE² 78RSiƲƲƲh_qyhob0JCJ hhobhoLhob6 hob6 hob0J6jhobUh'Hhob0J56hob hh h0J hob0Jh_qyhob0Jjh_qyhob0J6Uh_qyhob0J67C+Je|ţ̥^ҧԧS  & F[$\$gdx* [$\$gd_qy & F^`gdx*[$\$^gd'* [$\$gd & F[$\$gdx*gd_qyS8}+&'2$gd_qygd_qy$ & F |dd[$\$^`|gdx* 7[$\$`7gd_qygd [$\$gd_qy  & F[$\$gdx*Į%Mů"aϰV7jk{Y$gd_qy$ & F |dd[$\$^`|gdx*gd_qy  & F^`gdx*  W^`Wgd_qyijk{'(UVpqշַ7:0=>?@ABpqyzݻ?@׼ټ˺ĺꍇwwh$0hob0J hhob hob^Jhhob^Jh7 h4 hob hob0Jhk+nhob6^Jhob56^JhV}hob6^J hob6^Jhl hob6^Jhx/ hob6 hob6jhobUhobh_qyhob0J6 hob0J6.FXhŵٵTŷշַ\$gd_qy$ & F |dd[$\$^`|gdx*gd_qy & F ^`gdx*$ & F ^`gdx* $ & F^gdx*y#ʺ#?@ݻ  0 3$IfgdCf= & Fgdx*gd gd/gd_qy ^`gd_qy & Fgdx* & F[$\$^`gdx*0?@ڼ%Uw <$Ifgd$0Ff) 3$IfgdCf= ټ#$ST !()*124:;=>lmuv|ȾɾʾҾӾԾվ־ʻʷʰzkahthob]^JhthobB*PJ^Jph h0hobh0hob^Jh0hobCJ^Jh0hobCJ\^Jh0hobB*PJ^Jph hCf=hobh7 h4 hobjhobUhob hhobhhob6]^Jhob6]^J h$0hob hob0Jh$0hob0J# "#& <$IfgdCf=kd|$$IflU֞ "*/;P $P 0644 laytt#$%&'( <$IfgdCf=()+,& <$IfgdCf=kd_$$Ifl6֞ "*/;P $P 0644 laytt,-./01 <$IfgdCf=1245& <$IfgdCf=kdB$$Ifl֞ "*/;P $P 0644 laytt56789: <$IfgdCf=:;<~&!!gdCf=kd%$$Ifl֞ "*/;P $P 0644 laytt~ȾɾʾԾվ־e\\\\ <$IfgdCf=xkd$$Ifl0O&n0644 layt 3$IfgdCf= [$\$gdCf= & Fgdx*gdCf=  !"#$245]^_`abcdefghimij~~lcXcXchthob0JPJhthob0J#h0hob6B*PJ]^Jphh0hob6]^Jh0hob\^J h0hobh0hobB*PJ^Jphh0hob^J h0hob5B*PJ^Jphh0hob5CJ^Jh0hob5CJ\^J hthobhthob]^J hthobB*PJ]^Jph" aXXKX < $IfgdCf= <$IfgdCf=kd$$Ifl\OE=&n0644 laytt !#5]aULLLL <$IfgdCf= <$$Ifa$gdCf=kd$$Ifl\OE=&n0644 laytt]^`bdfgNB9999 <$IfgdCf= <$$Ifa$gdCf=kdw$$IflrOE=&0644 layt ghijklmNB9999 <$IfgdCf= <$$Ifa$gdCf=kdF$$IflrOE=&0644 layt mnopNIDDD< & Fgdx*gdCf=+gd/kd$$IflrOE=&0644 layt mnoqr%&(34=>GHQRSUVúúú hUhobh$>hob0J hthob hob0Jh(}hob0Jhthob0Jhyhob6CJ hobCJ hCf=hobh7 h4 hobjhobUhobhobOJQJ h0hob:,CZ|'(g~ <$Ifgd(} <$IfgdCf=Ff 3$IfgdCf= [$\$gdCf= <$IfgdCf= <$Ifgd(}kdG$$IflZִLn (29" j  0e:    44 layt(}8Ei(3 <$IfgdCf= <$Ifgd(}34kd^$$IflִLn (29" j  0e:    44 laytCf=46789:;<= <$IfgdCf==>kdu$$IflkִLn (29" j  0e:    44 laytCf=>@ABCDEFG <$IfgdCf=GHkd$$IfloִLn (29" j  0e:    44 laytCf=HJKLMNOPQ <$IfgdCf=QRkd$$IfloִLn (29" j  0e:    44 laytCf=RST 3$IfgdCf=gdCf= & Fgdx*gdCf=gd/ &)DSVY^nD\_bg{!"*+1Kdnoq\r{|st?@䭣hhobCJ\]^Jhhob5\^J hob^Jhhob6] hhobhK h4 hobjhobU hobCJhhob5CJhhob5 hob\hobhUhob6 hUhobhCf=hob0J.rggg <$IfgdCf=kd$$IflFd\DZZ06    44 laytCf=rggg <$IfgdCf=kdX$$Ifl,Fd\DZZ06    44 laytCf= rggg <$IfgdCf=kd$$Ifl,Fd\DZZ06    44 laytCf=ABCrggg <$IfgdCf=kd$$Ifl9Fd\DZZ06    44 laytCf=CDWXYrggg <$IfgdCf=kd\$$Ifl,Fd\DZZ06    44 laytCf=YZ[\]rggg <$IfgdCf=kd$$$Ifl,Fd\DZZ06    44 laytCf=]^noprggg <$IfgdCf=kd޴$$Ifl,Fd\DZZ06    44 laytCf=pqrggg <$IfgdCf=kdе$$Ifl,Fd\DZZ06    44 laytCf=rggg <$IfgdCf=