ࡱ> uwjklmnopqrstyz} 4bjbj55 } __Hqq3X@t???HS? {H×:gKϷA LZ ^8" oYYYYYY>rB$"K?M"<0^ F lr rY8(Y q }: PM 004 Project Business Plan (Large Projects) Template and Guide Version 2.1, April 2008 This Template and Guide is for the development of a Project Business Plan for a large 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 medium and small projects have also been developed (PM 904 Project Business Plan Medium, and PM 994 Project Business Plan Small). 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 Steering Committee 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: A 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 Steering Committee 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 Steering Committee 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. Endorsed document establishing the scope of the Project Business Plan, which could be a Project Proposal or a Project Business Case or a Feasibility Study. Any other project approval processes that are required in your organisation. 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 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 provides 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 Team, the Steering Committee and 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. Determining the project size: While the Project Sponsor or Project Officer has usually made an initial determination of the project size in the preparation of the Project Proposal and/or the Project Business Case, the size of the project should be formally determined by the appointed Project Manager and agreed by the Steering Committee once the project has been approved and funded. There are many factors that could be taken into account to determine the project size such as: complexity; strategic and/or political importance; budget; level or degree of risk; technology requirements; number of key stakeholders; impact (the level of organisational change required); dependencies and inter-related projects; and the size and skill level of the project team. A large project usually requires a higher degree of project management activity and detailed documentation, to ensure how the project will be managed and the level of detail and discipline that will be employed are clearly defined, accepted and agreed. Where a project is cross-Agency, whole-of-government or involves more than one tier of Government, the application of project management methodology to its fullest extent should seriously be considered. Refer to the Project Management Fact Sheet: Project Sizing 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  HYPERLINK "http://www.egovernment.tas.gov.au" 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?  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 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 Version 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 complete replacement. 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 On behalf of the Steering Committee 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 "_Toc195953511" 1 Overview  PAGEREF _Toc195953511 \h 11  HYPERLINK \l "_Toc195953512" 1.1 Purpose of Business Plan  PAGEREF _Toc195953512 \h 11  HYPERLINK \l "_Toc195953513" 1.2 Project Title  PAGEREF _Toc195953513 \h 11  HYPERLINK \l "_Toc195953514" 1.3 Project Initiation  PAGEREF _Toc195953514 \h 11  HYPERLINK \l "_Toc195953515" 1.4 Background  PAGEREF _Toc195953515 \h 11  HYPERLINK \l "_Toc195953516" 2 Objectives and Scope  PAGEREF _Toc195953516 \h 12  HYPERLINK \l "_Toc195953517" 2.1 Objectives Hierarchy  PAGEREF _Toc195953517 \h 12  HYPERLINK \l "_Toc195953518" 2.1.1 Government Objective(s): Tasmania Together  PAGEREF _Toc195953518 \h 12  HYPERLINK \l "_Toc195953519" 2.1.2 Australian Government Objective(s)  PAGEREF _Toc195953519 \h 12  HYPERLINK \l "_Toc195953520" 2.1.3 Corporate Objective(s)  PAGEREF _Toc195953520 \h 12  HYPERLINK \l "_Toc195953521" 2.1.4 Project Objective(s)  PAGEREF _Toc195953521 \h 12  HYPERLINK \l "_Toc195953522" 2.2 Project Outcomes  PAGEREF _Toc195953522 \h 12  HYPERLINK \l "_Toc195953523" 2.2.1 Target Outcomes  PAGEREF _Toc195953523 \h 13  HYPERLINK \l "_Toc195953524" 2.3 Outputs  PAGEREF _Toc195953524 \h 13  HYPERLINK \l "_Toc195953525" 2.4 Scope of Work  PAGEREF _Toc195953525 \h 14  HYPERLINK \l "_Toc195953526" 2.5 Project Development Plan  PAGEREF _Toc195953526 \h 15  HYPERLINK \l "_Toc195953527" 2.5.1 Project Development Strategy  PAGEREF _Toc195953527 \h 15  HYPERLINK \l "_Toc195953528" 2.5.2 Project Schedule  PAGEREF _Toc195953528 \h 15  HYPERLINK \l "_Toc195953529" 2.6 Assumptions and Constraints  PAGEREF _Toc195953529 \h 16  HYPERLINK \l "_Toc195953530" 2.6.1 Assumptions  PAGEREF _Toc195953530 \h 16  HYPERLINK \l "_Toc195953531" 2.6.2 Constraints  PAGEREF _Toc195953531 \h 16  HYPERLINK \l "_Toc195953532" 2.7 Relevant Government Policy, Legislation and Rules  PAGEREF _Toc195953532 \h 16  HYPERLINK \l "_Toc195953533" 3 Project Management Plan  PAGEREF _Toc195953533 \h 17  HYPERLINK \l "_Toc195953534" 3.1 Governance  PAGEREF _Toc195953534 \h 17  HYPERLINK \l "_Toc195953535" 3.1.1 Corporate Client  PAGEREF _Toc195953535 \h 18  HYPERLINK \l "_Toc195953536" 3.1.2 Project Sponsor  PAGEREF _Toc195953536 \h 18  HYPERLINK \l "_Toc195953537" 3.1.3 Project Business Owners  PAGEREF _Toc195953537 \h 18  HYPERLINK \l "_Toc195953538" 3.1.4 Business Customers  PAGEREF _Toc195953538 \h 19  HYPERLINK \l "_Toc195953539" 3.1.5 Steering Committee  PAGEREF _Toc195953539 \h 19  HYPERLINK \l "_Toc195953540" 3.1.6 Project Manager  PAGEREF _Toc195953540 \h 19  HYPERLINK \l "_Toc195953541" 3.1.7 Project Team  PAGEREF _Toc195953541 \h 20  HYPERLINK \l "_Toc195953542" 3.1.8 Quality Consultants  PAGEREF _Toc195953542 \h 20  HYPERLINK \l "_Toc195953543" 3.1.9 Reference Groups  PAGEREF _Toc195953543 \h 21  HYPERLINK \l "_Toc195953544" 3.1.10 Working Groups  PAGEREF _Toc195953544 \h 21  HYPERLINK \l "_Toc195953545" 3.1.11 Consultants  PAGEREF _Toc195953545 \h 21  HYPERLINK \l "_Toc195953546" 3.1.12 Contractors  PAGEREF _Toc195953546 \h 22  HYPERLINK \l "_Toc195953547" 3.2 Reporting Requirements  PAGEREF _Toc195953547 \h 22  HYPERLINK \l "_Toc195953548" 3.2.1 Reports to the Steering Committee  PAGEREF _Toc195953548 \h 22  HYPERLINK \l "_Toc195953549" 3.2.2 Quality Consultants Reports  PAGEREF _Toc195953549 \h 23  HYPERLINK \l "_Toc195953550" 4 Stakeholder Management & Communication  PAGEREF _Toc195953550 \h 24  HYPERLINK \l "_Toc195953551" 4.1 Stakeholder Identification and Classification  PAGEREF _Toc195953551 \h 24  HYPERLINK \l "_Toc195953552" 4.2 Stakeholder Analysis  PAGEREF _Toc195953552 \h 24  HYPERLINK \l "_Toc195953553" 4.3 Stakeholder Communication and Management  PAGEREF _Toc195953553 \h 25  HYPERLINK \l "_Toc195953554" 4.3.1 Key Issues  PAGEREF _Toc195953554 \h 26  HYPERLINK \l "_Toc195953555" 4.3.2 Approach  PAGEREF _Toc195953555 \h 26  HYPERLINK \l "_Toc195953556" 4.3.3 Strategies  PAGEREF _Toc195953556 \h 27  HYPERLINK \l "_Toc195953557" 4.3.4 Milestones  PAGEREF _Toc195953557 \h 27  HYPERLINK \l "_Toc195953558" 4.4 Related Projects & Programs  PAGEREF _Toc195953558 \h 28  HYPERLINK \l "_Toc195953559" 4.5 Industrial Relations Impact  PAGEREF _Toc195953559 \h 29  HYPERLINK \l "_Toc195953560" 5 Resource Management  PAGEREF _Toc195953560 \h 30  HYPERLINK \l "_Toc195953561" 5.1 Budget and Expenditure  PAGEREF _Toc195953561 \h 30  HYPERLINK \l "_Toc195953562" 5.1.1 Funding Sources  PAGEREF _Toc195953562 \h 30  HYPERLINK \l "_Toc195953563" 5.1.2 Project Budget Overview  PAGEREF _Toc195953563 \h 30  HYPERLINK \l "_Toc195953564" 5.1.3 Detailed budget - Planned Expenditure:  PAGEREF _Toc195953564 \h 31  HYPERLINK \l "_Toc195953565" 5.2 Other Resources  PAGEREF _Toc195953565 \h 31  HYPERLINK \l "_Toc195953566" 6 Risk Management Plan  PAGEREF _Toc195953566 \h 32  HYPERLINK \l "_Toc195953567" 6.1.1 Risk Identification  PAGEREF _Toc195953567 \h 33  HYPERLINK \l "_Toc195953568" 6.1.2 Risk Analysis  PAGEREF _Toc195953568 \h 33  HYPERLINK \l "_Toc195953569" 6.1.3 Risk Evaluation  PAGEREF _Toc195953569 \h 33  HYPERLINK \l "_Toc195953570" 6.1.4 Risk Mitigation  PAGEREF _Toc195953570 \h 33  HYPERLINK \l "_Toc195953571" 6.1.5 Monitoring and Review  PAGEREF _Toc195953571 \h 33  HYPERLINK \l "_Toc195953572" 7 Quality Management Plan  PAGEREF _Toc195953572 \h 34  HYPERLINK \l "_Toc195953573" 8 Outcome Realisation  PAGEREF _Toc195953573 \h 36  HYPERLINK \l "_Toc195953574" 9 Evaluation  PAGEREF _Toc195953574 \h 37  HYPERLINK \l "_Toc195953575" 10 Project Closure  PAGEREF _Toc195953575 \h 38  HYPERLINK \l "_Toc195953576" 11 Appendices  PAGEREF _Toc195953576 \h 39  Overview Purpose of Business Plan The Project Business Plan is the high-level management document for the project. It is owned, maintained and utilised by the  DOCPROPERTY strProjectTitle \* MERGEFORMAT  Steering Committee to ensure the delivery of defined project outcomes. The document will be reviewed and amended to meet changed conditions or objectives during the projects life span. Project Title Project Initiation Briefly describe the reasons for establishing the project and how it was initiated. Background 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 Hierarchy The Objectives Hierarchy directly links a projects activities with the organisational goals and direction of the Agency, providing the context in which the project is being undertaken. Where a project is contributing to the implementation of national policy decisions, it may also be necessary to include references to relevant Australian Government policy objectives in this section. Government Objective(s): Tasmania Together Include relevant Tasmania Together Benchmarks and Goals here. Australian Government Objective(s) Include relevant Australian Government policy objectives here. Corporate Objective(s) Include relevant Departmental and/or Divisional Goals here. Project Objective(s) A project objective is a statement of the overarching rationale for why the project is being conducted, and should be directly related to the Corporate Objectives and the business driver(s) for the project. It focuses on what the project is going to achieve, rather than what is produced. A project can have one or more objectives, which do not need to be measurable. 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 Outcomes Outcomes are the benefits or other long-term changes that are sought from undertaking the project. They are achieved from the utilisation of the project's outputs. Outcomes are linked with objectives, in that if the outcomes are achieved then the project's objective(s) have been met. Confirmation of project outcomes should be undertaken with stakeholders who will utilise the outputs delivered from the project to achieve the desired outcomes. List the outcomes sought from the project. Ask why the corporate stakeholders want the project to proceed. Identify which stakeholders will utilise which outputs to produce which outcomes. Some of the outcomes may not necessarily be relevant to all stakeholders. Outcomes should simply state a requirement and not contain any details about how they will be achieved (this information is considered in the definition of project outputs and processes). Target Outcomes Target Outcomes for a project are outcomes that have a measurable benefit and will be used to gauge the success of the project. Usually there will only be a small number of target outcomes for any project. Each measure will be linked to one or more target outcomes. At the end of the project the measures will help answer such questions as 'what have we achieved?' and 'how do we know?'. Target Outcomes are expressed as a sentence in the past tense and usually start with a word ending in 'ed', such as improved, increased, enhanced or reduced. Framing target outcomes in this way makes it easier to determine their success measure. A proforma for specifying and documenting Target Outcome Measures is provided at Appendix A. List the Target Outcomes sought from the project and detail relevant dates for achievement. The following outcomes have been selected as the Target Outcomes for the  DOCPROPERTY strProjectTitle \* MERGEFORMAT : TO #1 TO#2 These outcomes comprise performance information against which the project will be assessed, and are detailed at Appendix . Outputs Outputs are the products, services, business or management practices that will be required (produced) to meet the identified outcomes. They may be new products or services, or 'fixed things' called alterants. Outputs link with outcomes, in that the outputs are used by the project's customers to achieve the outcomes. Outputs are usually expressed as nouns. 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. Some examples: 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 Confirm the Output Utilisation stakeholders by identifying how each stakeholder will utilise each output to achieve project outcomes. Outputs must be logical by providing answers to questions: Why, What, Which, How. While there is never a direct one-on-one relationship, the use of a Customer Map can assist in identifying Target Outcomes and outputs. List the high level Outputs to be delivered by the Project. Include descriptions where necessary. Scope of Work The scope of work is defined as the processes that are required to produce the project outputs. The following model initially identifies 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. Any work falling outside the scope of the project must be considered carefully. Where the project is dependent on other work being completed, agreement must be sought terms of who is responsible and timelines for completion. At the time that the Project Business Plan is endorsed/approved 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 Project Development Strategy How are the overall project development processes to be undertaken to produce the project outputs? Depending on the complexity of the project, the Project Development Strategy may reflect a phased approach: Initiation Planning & scoping Management Development, delivery & implementation Finalisation & outcome realisation Large or long-term projects may take a staged approach: A Stage is defined as A major segment of a project for which there are outputs and outcomes at the end. Each Project Stage may comprise a number of Phases or a section or chunk of work in a project for which there are no measurable outcomes at the end, although some outputs may be produced.  Large and/or complex projects often scope the work in phases to enable each phase to be planned in more detail on completion of the previous phase. Planning for each phase may identify a number of sub-projects, with different team leaders working to deliver specific outputs. Using a phase approach also provides periodic points for review or Project Phase Reviews. Project Schedule The project schedule will depend on the choice of project strategy. The preferred approach is to develop a detailed project schedule at the commencement of each project phase. It may be subject to timing constraints and the strategies selected for the project. The following table is an example showing high-level major milestones only. Milestones are the progress markers by which the projects Steering Committee will monitor the progress of the project and need to be spaced accordingly. It is important to note who is responsible for ensuring the necessary activity required for milestone achievement. You may choose to list other on-going project management tasks, such as Steering Committee meetings, risk review etc. Key DeliverablesTarget DateWhoPhase 1Milestone AMilestone BMilestone CPhase 2Table  SEQ Table \* ARABIC 1 : Project Development Schedule The initial detailed Project Plan (ie Gantt Chart) can be included as an appendix in the Project Business Plan. However, the working project plan should be maintained separately to avoid the need to continually re-release the Project Business Plan. 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. Examples of assumptions and constraints include deadlines, finance and budget, legislation, resource availability, environment, technology, security etc. This process should also assist with risk identification, as both assumptions and constraints will reveal areas of risk for the project. Assumptions eg resource availability, environment, technology, security etc Constraints eg deadlines, finance and budget, legislation etc 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  STYLEREF "Document Title" \* MERGEFORMAT Project Business Plan 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. EMBED Word.Picture.8 EMBED Word.Picture.8 Figure  SEQ Figure \* ARABIC 1: Governance Structure for the Corporate Client In a large, complex or politically driven project, the Corporate Client is the champion of the project and has ultimate authority. They promote the benefits of the project to the community, and may be viewed as the public face of the project. For example, the Corporate Client may be the Premier, Minister of the State or Head of Agency. In a small, less complex project, the Project Sponsor would fulfil the role of the project champion. The Corporate Client may also be funding the project (Project Funder). The Corporate Client for the  STYLEREF "Document Title" \* MERGEFORMAT Project Business Plan is: . Project Sponsor The Project Sponsor has ultimate accountability and responsibility for the project. The Sponsor oversees the business management and project management issues that arise outside the formal business of the Steering Committee. The Sponsor also lends support, by advocacy, at senior levels, and ensures that the necessary resources (both financial and human) are available to the project. The Project Sponsor has delegated authority of the Steering Committee to assist with business management and project management issues that arise outside the formal business of the Steering Committee. The Project Sponsor is a member of the Steering Committee, and is usually the Chair. The Corporate Client and Project Sponsor may be the same person for some projects. The Project Sponsor is ultimately responsible for ensuring that project Target Outcomes are secured before formally closing the project. This responsibility might be delegated to senior management where the Business Owner(s) is not within the same Agency. The Project Sponsor may also be the Business Owner for the project and can also be the funder, but it varies within Government, depending on the budgetary arrangements and decisions about who will be managing the outputs after the project closes. In the case of large whole-of-government projects, the project funds may be managed by one Agency on behalf of the Government, but there may be several Business Owners. The Project Sponsor must be identified for all projects, no matter what the size or complexity. The Sponsor for the  STYLEREF "Document Title" \* MERGEFORMAT Project Business Plan is:  DOCPROPERTY strSponsor \* MERGEFORMAT  Project Business Owners The Business Owner(s) is responsible for managing the project outputs for utilisation by the Project Customers. The Business Owner(s) must be satisfied that the project includes all of the outputs necessary for outcome/benefits realisation. Each output must be specified and delivered fit-for-purpose. During the development of the project outputs, the Business Owner(s) also may be required to contribute resources to the project, in order to ensure that the outputs are being developed satisfactorily. This involvement is continuous from the early conceptual stages through to reviewing and/or testing the completed products. There may be one or more Business Owners, at a number of managerial levels, depending on the size of the project. Usually the Business Owner(s) is accountable to the Project Sponsor or their delegate(s), who may be Senior Management in the Agency, for the realisation of project Target Outcomes. One or more Business Owners are usually Steering Committee members. 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. The Business Owner(s) for the is (are): . Business Customers There may be other Government Agencies or Business Units that will utilise the project outputs, but do not have management responsibility for their ongoing maintenance or accountability for the realisation of outcomes. These are known as the Business Customers. Sometimes the Project Observer or the Project Business Owner(s) represents the interests of the Business Customer(s). Steering Committee The Steering Committee is responsible for policy and resourcing decisions essential for the delivery of project outputs and the attainment of project outcomes. It is also responsible for ensuring appropriate management of the project components outlined in this Project Business Plan including risk monitoring, quality and timeliness. 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, at  HYPERLINK "http://www.egovernment.tas.gov.au" www.egovernment.tas.gov.au. Members: (Chairperson); (Project Observer); etc Project Manager The Project Manager is contracted by the Project Sponsor and Steering Committee to deliver the defined project outputs. They are responsible for organising the project into one or more sub-projects, 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 It is essential that the Project Manager has demonstrated high-level project management skills. A Project Manager cannot lead effectively unless they have credibility. For most projects, it means the Project Manager must have knowledge of how the outputs will be created and how they will achieve the outcomes described in the Outcome Realisation Plan. The Project Manager must be identified for all projects, no matter what the size or complexity. The Project Manager for the  STYLEREF "Document Title" \* MERGEFORMAT Project Business Plan is . Project Team The Project Team is led by the Project Manager, working for the successful delivery of the project outputs, as outlined in the Project Execution Plan(s). It is desirable that the Project Team includes representatives from the Business Unit(s) affected by the project. Team Leaders may manage different sub-projects. The composition of the Team may change as the project moves through its various phases. The assessment and selection of people with the requisite skills required for each phase of a project is critical to its overall success. The skills should be explicitly identified as a part of the project planning process. The Project Team is responsible for completing tasks and activities required for delivering project outputs. It is proposed that the core project team will be: Quality Consultants Large projects generally engage one or more quality consultants to undertake formal quality reviews of the projects processes or outputs. These consultants work independently of the Project Team, and are often contracted from outside the organisation. There are two distinct classes of Quality Review: One class focusing on the project as a whole in terms of structure, processes and progress toward outputs One class focusing on the quality of products or services (outputs) being produced within a project in a technical field (eg law, IT, construction) 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 more information (available at  HYPERLINK "http://www.egovernment.tas.gov.au" www.egovernment.tas.gov.au). Reference Groups Reference groups provide expertise and quality assurance in the development of project outputs. They also provide forums to achieve consensus among groups of stakeholders. The group may already exist, have an indefinite life span or may continue for the life of the project. One such group might be a general reference group delegated by the Steering Committee to monitor or modify the Project Business Plan for approval by the Steering Committee. The group also may consist of collection of people with like skills to address a particular set of issues. An information technology reference group is an example. Working Groups Working groups consist of small specialist work groups, each dedicated to producing a well-defined output within a specific timeframe. A working group has no life beyond the delivery of that output. Working groups probably involve one or more members of a Project Team to support activity. Consultants Consultants are employed from outside the organisation to provide specialist or other expertise unavailable from internal resources. The consultants may report directly to the Chair of the Steering Committee (or perhaps the Chair of a general Reference Group). Typically Project Consultants may include: Information technology specialists who define and manage the technological aspects of the project Representatives employed by stakeholders to ensure their interests are represented and managed Legal advisers who assist in the development and review of the contractual documentation Auditors who ensure compliance with internal and external audit requirements Contractors Contractors also may be engaged to work as part of the Project Team. Contractors are employed, external to the business area, to provide a specified service in relation to the development of project outputs. Examples include: Prepare and deliver training to staff in the business area Develop and deliver marketing programs Develop guides and/or manuals Develop business application software Reporting Requirements Reports for the Steering Committee are required to concentrate on the management issues of the project. It is important to clarify frequency and reporting relationships this will also inform Stakeholder Communication and Management and development of the Project Communication Plan. Current reporting requirements are: Reported byTo whomReporting requirementsFrequencyFormatProject ManagerSteering CommitteeStatus ReportMonthlyWritten and verbal Project ManagerReference Group Status ReportMonthlyWritten and verbalProject ManagerCommonwealth Status ReportMonthlyWritten and verbalQuality ConsultantSteering CommitteeStatus ReportMonthlyWritten and verbalIn 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. Reports to the Steering Committee The Project Managers regular report to the Steering Committee will include 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. Note that milestones for reporting purposes should reflect those listed in Section 2.5.2 Project Development Schedule as well as those in the operational project work plan. Budget report (with respect to planned expenditure, actual expenditure and the 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 changes to the major risks identified since the previous report and modification to the strategies put in place to manage them). A template for Project Managers Status Report is available at  HYPERLINK "http://www.egovernment.tas.gov.au" www.egovernment.tas.gov.au Quality Consultants Reports The Quality Consultants reports provide independent feedback to the Steering Committee on issues such as: Legal issues related to the development of contractual documentation; Auditors who report on the Projects compliance with internal and external audit requirements; Quality reviews conducted of the project, for example with respect to the project and quality management methodologies and processes that are being used; or Whether outputs meet the specified requirements, for example advice from information technology specialists who are contracted to define and manage the technological aspects of the project. Stakeholder Management & Communication Stakeholder Identification and Classification The following table provides a list of classifications that may be adopted by a project to categorise groups of project stakeholders. Classifying stakeholders into groups allows management strategies for like groups to be developed and implemented. The list is not definitive, nor will every project use every classification. It may be necessary to break some groups down into sub-categories eg breaking the outcome-impacted group into those that receive a benefit and those that receive a dis-benefit (negatively impacted). An early review of the stakeholder list is required to identify critical stakeholders who should be involved in all project planning and review sessions. Classification of stakeholders may change as the project progresses. GroupGroup DescriptionStakeholdersReviewGroups/organisations who need to review (or audit) the project and its outputs/outcomes.eg Quality Review Consultant, Auditors, Minister, Parliament, Budget Committee.Related ProjectsRelated projects and change activities that will impact upon this project.eg can be internal or external to the organisation, government, national etc identify owners of each.Outcome ImpactedIndividuals/groups/organisations/related projects who will be impacted by the achievement of the projects outcomes.ProviderGroups/organisations who will be required to provide inputs and services to the project.eg can be internal and external to provide resources, specific expertise or products etc.Output DeliveryGroups/organisations responsible for the delivery of the projects outputs.eg Project Team, Consultants.Output UtilisationGroups/organisations who will be required to implement and utilise the projects outputs to enable the achievements of the projects outcomes.eg Business Owner(s).Outcome AccountableClient groups who are the corporate owners/sponsors of the project, supporting the achievement of project outputs and outcomes.eg Corporate Client, Project Sponsor, Steering Committee.Table  SEQ Table \* ARABIC 2: Stakeholder Groups (modified from Thomsett and Smyrk) Stakeholder Analysis While initially classifying stakeholders into generic groups for the purposes of identification is useful, the individuals or groups within each category should then be identified specifically and targeted. The Stakeholder Analysis process includes: Identify/review all stakeholders Analyse/review nature of stakeholding for each Categorise/confirm as key and non-key, and prioritise based purely on your own judgements about the importance of the stakeholder Perform/review buy-in analysis for Key Stakeholders, ie what is required to engage them in the project and gain their commitment, and how to communicate with them Stakeholder analysis is best carried out by the Project Team in consultation with potential stakeholders or representatives of potential stakeholder groups. #Ref CodeStake-holderKey or Non KeyNature of stake holdingKey issues for projectEngagement and commitment processPlanned action detailed in?Who?What potential impact does the stakeholder have on the project? What potential impact does the project have on the stakeholder?How will we engage this stakeholder and gain their commitment?Communication Plan Risk Register Issues Register Change Mgt Plan Work plans Budget Resources Action List1.0 (For Example) Building a community hall Unhappy neighbourKeyLobby against Vandalism 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 ContractorTable  SEQ Table \* ARABIC 3: Stakeholder Analysis Stakeholder Communication and Management In large and/or complex projects, all communication takes place in the context of an overall communication strategy and plan. It should involve the Agency Communications Manager or a Communication and Marketing professional, depending on the nature of the Key Stakeholders identified and the focus of the project or program of projects. 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. It is recommended that a stand-alone Project Communication Strategy be developed that reflects the initial Stakeholder Analysis provided in the Business Plan. The stakeholder management strategies adopted may be formal, informal, detailed or broad, dependent on the needs of the project. 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. Key Issues Summarise the overall key communication and management issues for the project that have been discussed with the relevant stakeholders. Stakeholder management activities can consume project resources, particularly the Project Managers time, therefore these activities should concentrate on what will contribute to the projects success or where a lack of communication can lead to failure. Approach Broadly describe the direction and approach that will be used for stakeholder management. Consider any assumptions and constraints that may need to link into the projects risk management plan. Examples include: Use of diverse means of communication with face to face the primary method by the projects key management team (eg Project Sponsor, Business Owner, Project Manager) Information presented regularly, (ie frequency) via a variety of medium and formats Strategy for responding to unexpected stakeholder demands or information requests Mechanisms established to ensure two-way communication Key roles for specific personnel (eg who is the primary contact for handling queries from the public, media, private organisations etc) Some communication technology factors to consider: Will project success require up to date information at a moments notice? Are communication systems currently in place appropriate? Will the current technology alter during the life of the project? Are communication systems proposed compatible with staff skills and experience? (Is training required?) Strategies The information needs of each stakeholder group should be analysed and may be summarised according to the following sub-headings: Key issues that need to be addressed End results sought by the stakeholder group and the project Mechanisms and tools to be used in communications Key messages and critical information to be exchanged Timeframes start, frequency, expected finish Depending on the size of the project and number of stakeholder groups, this information may be presented in a tabular format as an appendix. Example management methods: Provision of regular newsletters and/or progress reports Establishment of agreements which identify the nature of the relationship, the agreed service or product to be provided or received and any timing constraints on delivery. These agreements usually take the form of a memorandum, stakeholder agreement form, a formal agreement or contract Use of meetings, briefings and open-door sessions MBWA (Management By Walking Around) be seen, listen and communicate! Provide access to project documentation (eg www) Appropriate use of project specific/technical jargon Milestones Summarise the major events that are planned to occur. Major EventDue Dateeg newsletter releaseseg briefing sessionseg media releases/public launchTable  STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 4 : Stakeholder Analysis Full details of the work involved, resources and timeframes are to be included in the project plan (schedule of tasks). Related Projects & Programs Related projects (or major change initiatives) can be of significance to the project. Representatives of these projects should be involved in project planning sessions. Clearly establish appropriate linkages to other relevant sections, including Assumptions and Constraints (Section 2.4), Stakeholder Management Plan (Section 4) and Risk Management Plan (Section 6). 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. The nature of a dependency can include a shared relationship with data, functionality, staff, technology/infrastructure, funding, policy and/or legislation. DataFunctionalityStaffTechnology/ InfrastructureFundingPolicyLegislation dependent on another project[Project Title] interdependent with another project[Project Title]Other projects dependent on the [Project Title] Industrial Relations Impact The potential impact of employee/industrial relations issues to the project can be significant. Representatives from these areas should therefore be involved in project planning sessions. Resource Management Budget and Expenditure Identify and summarise the projects 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. Separate budget information should be provided for all sub-projects. 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), separate budget analysis should be provided for each source. Serious consideration should be given to contracting specialist external consulting services to provide advice and expertise in essential quality and project management methodologies in the areas of project management, risk management, governance, strategic planning, probity advice and audit, organisational performance management, business solutions, as well as information security strategy and management including disaster recovery. A working budget and current expenditure documents would be maintained separately to avoid the need to continually re-release the Project Business Plan. Where the project is beginning the transition to program 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 on behalf of the Tasmanian Government, related Department of Treasury and Finance publications, including the Handbook for Government Procurement and the available Tasmanian Government common use contracts, go to  HYPERLINK "http://www.purchasing.tas.gov.au" www.purchasing.tas.gov.au. Funding Sources Department of (Tasmanian Government)$ 500 000Department of (Australian Government)(plus)$ 500 000Total project funding(equals)$ 1 000 000Project Budget Overview Total Project fundingExample: 4 year project$1 000 000Expenditure for (minus)$ 200 000Expenditure for (minus)$ 250 000Remaining budget for life of project(equals)$ 550 000Preliminary allocation for $ 300 000Depending on how often the Project Business Plan is to be revised, a working budget and current expenditure documents would be maintained separately to avoid the need to continually re-release the Project Business Plan. Detailed budget - Planned Expenditure: Select as appropriate Copy or delete following table as required Operating Expenses FY $,000FY $,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) 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 are properly managed, so any potential threat to the delivery of outputs (level of resourcing, time, cost and quality) and the realisation of outcomes by the Business Owner(s) is appropriately managed to ensure the project is completed successfully. Ultimate responsibility for ensuring appropriate Risk Management processes are applied rests with the Project Sponsor and Project Steering Committee. In order to undertake appropriate risk management, the Project Sponsor and Project Steering Committee require a clear statement of the nature of each individual risk, the manner in which the risks can be contained, the potential impact on the projects success if the risk is left unaddressed and the likely cost of mitigation strategies. The processes by which risks will be managed during the project should be documented in the Project Risk Management Plan, which can be included in the Project Business Plan or developed as a separate document. The Project Risk Management Plan should also include details in relation to who was involved in the initial risk identification and classification process. All projects require a risk analysis to be undertaken upon commencement, which is regularly reviewed throughout the project life. Where they exist, Agency Risk Management processes should be incorporated in Project Risk Management activities. Attention should also be paid to the assumptions and constraints identified during the planning process, as listed in Section 2.6, as they will often indicate risks to project success. Examples of assumptions and constraints include deadlines, finance and budget, legislation, resource availability, environment, technology, security etc. The Risk Analysis should be undertaken with the critical stakeholders and will have a significant impact on the development strategy selected for the project. Where it is decided to take preemptive action to reduce a risk, it is essential that the cost of the risk strategy is included in both the project budget and any further cost/benefit/risk analysis. On completion of the initial risk analysis, and following risk reviews, strategies to manage or reduce high-level risks should be detailed here, noting how they will be implemented and how their effectiveness will be monitored. Processes for escalating business risks to Senior Management should occur as part of the overall Agency or whole-of-government risk management processes, including information and physical security risk management plans. Risk management is an ongoing process over the life of a project, and any Risk Register must be considered a snap shot of relevant risks at one point in time. The level of clarity with respect to specific risks usually improves as the project progresses. It may be prudent to discuss any political risks with the Project Sponsor prior to documentation. The risk assessment and management strategies working documents can be maintained separately to avoid the need to continually re-release the Project Business Plan. For further information on assessing the projects exposure to risk, refer to the Risk Management Resource Kit at www.egovernment.tas.gov.au.This approach reflects the Australian Standard for Risk Analysis AS/NZS4360:1999. The following headings should be broadly addressed here, with specific detail included in a standalone Risk Management Plan: Risk Identification What process was used to identify risks to the projects success? Who was involved? When was this conducted? Was any classification system used (ie Corporate Risks, Business Risks, Project Risks and System Risks)? Risks then should be filtered to determine which identified risks: Are best left, as the likelihood and seriousness would be so low that mitigation strategies are not required Need monitoring, but no proactive mitigation strategies required at this stage Are avoided by changing the scope of the work of the project, with appropriate sign-off Have to be escalated for the attention of Senior Management within the Agency as a risk to the overall Agency or whole-of-government business Need planned mitigation strategies, as detailed in the Risk Register Risk Analysis Risk analysis involves analysing the likelihood that risks will be realised and the level of seriousness/impact they will have if they occur. A matrix for grading risks is provided as part of Appendix C. The results of the initial analysis, particularly any Extreme and A level risks, should be included here. Initial results are also included in the Risk Register at Appendix C. Risk Evaluation Which risks pose the highest threat? What are the consequences should the risk be realised? Are benefits delayed or reduced? Are timeframes extended? Are costs advanced or increased? Is output quality reduced? Are treatment or mitigation plans required? Risk Mitigation What preventative action can be taken to reduce the likelihood a risk will be realised? What contingency planning can be done to reduce the seriousness of a risk if it occurs? For each risk that requires treatment or a mitigation plan, what is the cost (in budget terms as well as time and effort)? What recovery action is required if a risk occurs? Who is responsible for mitigation of each risk, and in what timeframe should action be taken? Monitoring and Review How often will the Risk Management Plan and Risk Register be formally reviewed, and by whom? How often will Risk Status be reported to the Steering Committee? 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 document, the Quality Management Plan should address the following components: Methodologies and Standards What proven methodologies and standards will be used to ensure that materials, products, processes and services are fit for their purpose? Examples in this context include project management methodology, procurement guidelines, relevant business domain driven standards, relevant standards developed by Standards Australia etc. Monitoring and Reporting What procedures will be utilised to ensure effective monitoring of project progress? What review and acceptance procedures will apply for example in the management of the Project Business Plan? Risk Assessment and Management How, to whom and how frequently will Risk status be reported? Who is responsible for management of the Risk Management Plan and Risk Register? Issues Register Management Who will be responsible for managing and maintaining the Issues Register? How often will it be updated? Who will have input? How will major issues be escalated, and to whom? Information Management Do any protocols apply for records management (eg TRIM)? How will registration of all official documents be managed? Output Quality Detail how the outputs are to be tested and accepted by the Business Owner. In many cases this will require establishment of a formal process. In addition detail how the sign off by the Business Owner that they have accepted the output is to be documented. In some cases this may be as simple as having the Steering Committee endorse that an output has been delivered and accepted. It is essential that the Business Owner is intimately involved in this process and take ownership once the output has been delivered. They may also need to have input into the quality assurance process for outputs to assist with making sure they are fit for purpose before delivery. Outcome Realisation Once a project delivers its outputs to the Business Owner(s), these outputs must be utilised by the Project Customers to enable the projects outcomes to be realised. This stage of the project is therefore referred to as outcome realisation.Usually this involves some degree of organisational change. Organisational Change Management is the management of realigning an organisation to meet the changing demands of its business environment, including improving service delivery and capitalising on business opportunities, underpinned by business process improvement and technologies. Any project planning activities must consider the amount of organisational change required to deliver the project outputs and realise the project outcomes. Large and/or complex projects may require change management to be addressed as a separate but closely related project, or series of projects, within the Agency. Organisational Change Management is a substantial discipline in its own right and includes the management of changes to the organisational culture, business processes, physical environment, job design/ responsibilities, staff skills/knowledge and policies/procedures. An Outcome Realisation Plan is used to support the organisational change management process required for effective utilisation of the agreed project outputs in the business unit(s) in order for longer term outcome/benefit realisation. In addition to planning for the measurement of the outcomes, this planning prepares the business areas for transition to the new operational environment that will exist once the Project Team has handed over the outputs, the Team has been disbanded and/or the project is closed. For large projects a separate Outcome Realisation Plan (ORP) is usually developed. Please see PM 006 Outcome Realisation Template and Guide at  HYPERLINK "http://www.egovernment.tas.gov.au" www.egovernment.tas.gov.au. In this section, describe when and who will develop and maintain the document throughout the life of the project. In some instances, more than one ORP may be required if more than one Agency will be responsible for the maintenance of the project outputs and for the achievement of project outcomes. Elements of the ORP include Transition Plan and Schedule Communication Plan Training Plan Maintenance Plan Performance Measurement Plan Usually the Business Owner(s) will be required to create and maintain the Outcome Realisation Plan(s), and report on progress toward the achievement of project outcomes to the Steering Committee and senior management. In reality it is often the Project Manager who will prepare the first draft of the ORP. Evaluation Regardless of the size or complexity of the project, a 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 and define 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. The following components of Project Evaluation should be detailed in the Business Plan: Project Performance Review Project Output Quality Review Project Outcome Realisation Review Project Management Methodology Review Project Output Development Methodology Review 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 Formal closure by Project Sponsor/Steering Committee and disbanding the Steering Committee Refer to the Tasmanian Government Project Management Guidelines and the Project Management Template & Guide: PM005 Project Closure Report at  HYPERLINK "http://www.egovernment.tas.gov.au" www.egovernment.tas.gov.au for more information. Appendices The following documents and forms may be attached to the Project Business Plan as appendices to enhance or meet specific project requirements. Appendices are usually documents that are: 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 analysis); or Additional information provided to support the summary content within the Project Business Plan (eg project management methodology). For example: Target Outcome Measurement Specify the Target Outcomes selected for measurement, including the performance indicator, baseline, target level, timeframe and accountability. Management Methodology Additional detail of the project management methodology and in particular, Steering Committee functions such as Terms of Reference. (This information may be summarised within the project management section.) Risk Register Provides snapshot details of the current risk assessment and risk management strategies. Budget and Expenditure Provides snapshot details of the current status of the projects budget and expenditure. Project Schedule A snapshot high-level Gantt Chart, or similar, of major project milestones and processes. 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 Project Business Plan Version No: Date: Customer Map   A B Number #Name of OutputsOutcomes Name of Outcome A Name of Outcome B 1Name of Output  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 2     Project Business Plan Version No: Date: Risk Register IdDescription of Risk Identification of consequencesLikelihood/ SeriousnessGradeChangeImpactMitigation Actions (Preventative or Contingency)Individual/Group Responsible for Mitigation ActionTimeline for Mitigation Action 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/SeriousnessSeriousnessLikelihoodLowMediumHighEXTREMELowEDCAMediumDCBAHighCBAA 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.ETo 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 Project Business Plan Version No: Date: Stakeholder Identification & Classification Stakeholder groups are classified according to the Tasmanian Government Project Management Guidelines. IdGroup & DescriptionStakeholdersTarget Audience Classification IdClassificationStakeholdersTA 1MandatoryTA 2InformationalTA 3Marketing Project Business Plan Version No: Date: Project Activities & Milestones (Version0.A) IdActivities & Key Milestones Start DateDue Date<1 January 2006><30 January 2006><1 February 2006>Note that Milestones are usually shown in bold and have no start date A milestone is defined as a significant scheduled event that acts as a progress marker in the life of a project. A milestone is either passed or it is not, the achievement or non-achievement of which is monitored and reported. The initial detailed Project Plan (ie Gantt Chart) could also be included as an appendix. However, the working project plan should be maintained separately to avoid the need to continually re-release the Project Business Plan.  For a definition of common terms, refer to the Tasmanian Government Project Management Guidelines , Appendix 1: Project Management Glossary  Refer to the Tasmanian Government Project Management Guidelines, Appendix1: Project Management Glossary  Refer to the Tasmanian Government Project Management Guidelines, Appendix1: Project Management Glossary  See the Project Management Fact Sheet: Developing a Gantt Chart at www.egovernment.tas.gov.au  An Act is called a Bill until it is passed by both Houses of Parliament and receives Royal Assent.  For a definition of Project Observer, refer to the Tasmanian Government Project Management Guidelines Version 6.0 (March 2005): Appendix1: Project Management Glossary (www.egovernment.tas.gov.au)  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  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  See note 8  Smyrk, John (2004) Primer example  Managing Projects for Outcomes, Course material  Refer to the Project Management Fact Sheet: Developing a Project Communication Strategy at www.egovernment.tas.gov.au.  Tasmanian Government Project Management Guidelines Version 6.0 (March 2005): Section 1.2 Key Elements in a Projects Life  Tasmanian Government Project Management Guidelines: Section 1.2 Key Elements in a Projects Life.   HYPERLINK "http://www.projectmanagement.tas.gov.au/guidelines/pm6_4.shtml" Tasmanian Government Project Management Guidelines: Section 4 Organisational Change Management and Outcome Realisation Planning   PM 004 Project Business Plan (Large): Guide Tasmanian Government Project Management Framework<>  PAGE \* MERGEFORMAT ii Inter Agency Policy and Projects Unit Department of Premier and Cabinet  PM 004 Project Business Plan (Large): Guide Tasmanian Government Project Management Framework<>  PAGE \* MERGEFORMAT iv Department of   STYLEREF "Document Title" \* MERGEFORMAT Project Business Plan Version Copy: Uncontrolled Page  PAGE 41 of  NUMPAGES 41  STYLEREF "Heading 1" \* MERGEFORMAT Appendices  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 Target Outcomes Measurement  STYLEREF "Heading 7" \* MERGEFORMAT Project Activities & Milestones (Version 0.A)  STYLEREF "Document Title" \* MERGEFORMAT Project Business Plan Version
Copy: Uncontrolled Page  PAGE 49 of  NUMPAGES 49  STYLEREF "Project Name" \* MERGEFORMAT Error! No text of specified style in document.  STYLEREF "Report Name" \* MERGEFORMAT Error! No text of specified style in document.:  STYLEREF descriptor \* MERGEFORMAT Error! Use the Home tab to apply descriptor to the text that you want to appear here. Page  PAGE 33 ,IKXY   I Z z { | a b ззНЕЕЏhWp h0J h0J h^0Jjh^Uhrhr0J hr0J5hrhr0J5hrh^0J5hWp hr0J hr0JhWp h^0Jhd h^6 hh^h^h'h^CJ,aJ$h^CJ,aJ$2.AY7 8 gdgd^ X^gd^gd^gd^$`]`^`a$gd^ '(*DF3Zj9NIi 4<=Xfgڣڜ䶪h8Ph8P6^J h V6^J h^6^J h8P^J hd^Jhh^6]^Jjhh^H*U^Jh8Ph8P^JhJ5h^6^Jhh^^Jhq,h^>* hh^h8 |D3D Ii$ & F Vd[$^`Vgd;pggdkT$ & F Vd[$^`Vgd;pg$ & F Vd[$^`Vgd;pggd^gd^gdhTd Egdwigd^gd^$ & F d[$gdOk$ & F Vd[$^`Vgd;pggdkT$ & F Vd[$^`Vgd;pgPSTdEPe.2>?FG-.1̸̲̬Ĥ̖̌ysj̸̖shhOk^J h^^J hwi^JhAzh^5\]^Jh2Nh^5^JhJ5h^6^Jhwih^hOk hOk^J h8P^Jhh^6]^Jhq,h^>*hh^^JhUh8PB*^Jphhh8P^Jh8Ph8P6^Jh8Ph^6^J%12ab|}~8HSi!""Y#\#i##############$%%ǼǼǷǰǰ{sjhhd^Jhq,h^>*h22hwi0J^JjhwiU^J hwi^J hwi6^JhJ5hwi6^Jhhwi^J hwihwi h V\hwihwi6\]hwihwi\hq,hwi>*hOkhh^^Jh22h^0J^J h^^Jjh^U^J% w !6!c!!\###$$%U% [$\$gddgd^gd^ & F^gd;pg & F[$^gd;pg\$gdwigdwigdwi%$%]%i%%,&&:';'X'''''''''(((w({(((((A)J)))=*F*c*e*g*q**++u+v+w+ýØýØØØØý~u~qmhg{hwihAh^0Jh^hZh^5 hq,h^ h^6^JhJ5h^6^JhhDhwi0J^J hwi^JjhwiU^J h^^Jhh^^Jhq,h^>*hhOk^J hd^Jh3.ehd0Jhhd^JhJ5hd5^J*U%.&[&&:';'X''w(()f*g*r$ & F d[$^gd^$ & F d[$^gd;pggd^ V^`Vgd^$ & F Wd<[$\$^`WgdOk$ & F d<[$\$^gdd$ & F <\$^gdd g*q*** +u+v+w+x+y+++tkb $Ifgd% $Ifgd2KBkd$$Ifl"&& t&644 la $Ifgd^ & FWd[$^`Wgdg{ & Fd[$^gd;pg & F^gd;pg\$gd^gd^ w+x+y++++++.------------......|..)/\/]/^/|/}///Ǽ{q{q{jqbbjh3DU h3D6]hh3D6] hh3Dh3D h^h^hBh V hi/h^h5oh^CJaJhZrh^0Jh^jh^Uh{h^0JCJhZrh^0J6hTh|CJHaJH h%h| h/h/h/hPqhTh2K5\h2K#++.-----.\SS $Ifgd^Ekd$$Ifl,"&& t&644 layt^ $$Ifa$gd^ $Ifgd^EkdM$$Ifl) "&& t&644 layt^.....|..^/////J0111 0$Ifgd}Ngd,pgdg{gdygd}Ngd3Dgd3D$a$gdBEkd$$Ifl"&& t&644 layt^////////0 0000#030V0c000111111111111112222222 2!2/2]2e2l2m22222ǼǼǴθθΫδ΍θθΫδδΉhG$h;pgh}N6KH ^J h#h}N h#h,ph3Dh;pgh}NCJh,ph Vhg{ h2h$> h2h}Nh}Nhyh$>h3D0J h}N0J h3D6]jh3DUhlh3D0J6]21111111 0$Ifgd}N1111290$$ 0$$Ifa$gd;pg 0$Ifgd}NkdF$$Iflִd "#&856 t6    44 lalyt;pg22222222zn 0$$Ifa$gd;pg|kdg$$Ifl1\d&8 t644 lalyt;pg 0$Ifgd}N222222222 2zzzzzzzz 0$Ifgd}N|kd$$Ifl1\d&8 t644 lalyt;pg 2!2/2M2m290$$ 0$$Ifa$gd;pg 0$Ifgd}Nkd$$Iflִd "#&856 t6    44 lalyt;pgm2222222222nid_V ($Ifgdlgd3Dgd3Dgdy|kd$$Ifl1\d&8 t644 lalyt;pg 0$Ifgd}N 0$$Ifa$gd;pg 2222222B7 $Ifgdlkdu$$Iflr9s& t0644 lalytl ($Ifgdl2222#3*33333344M4T4h4i4{4|4444444444444ƽƭƩyuyey`V`jh>UU h>Uj= h)h>U0JUh>Uh)h>U0Jjh)h>U0JUh$>h|0Jjh$>h|0JUh|h}Nh7 h3D\h6Ah3D6h3.eh3D0Jh3Dh Vh3.eh3D0J5CJaJh3D56CJaJh6Ah3D56CJaJh6Ah3DCJaJ2#30373G3K3 0$Ifgdl 0$Ifgd V"$If^"`gdlK3L3h3v333KF=== ($Ifgdlgd3DkdA$$Iflr9s& t0644 lalytl33333qhhh 0$Ifgdlkd $$IflFd^&t t06    44 lalytl3333333qlcccc ($Ifgdlgd3Dkd$$IflFd^&t t06    44 lalytl3344404^UUUU 0$Ifgdlkdi$$Ifl\3 0~&l/F t0644 lalytl041434445464^UUUU 0$Ifgdlkd- $$Ifl\3 0~&l/F t0644 lalytl64748494:4;4^UUUU 0$Ifgdlkd $$Ifl\3 0~&l/F t0644 lalytl;4<4G4M4Z4g4^UUUU 0$Ifgdlkd $$Ifl\3 0~&l/F t0644 lalytlg4h4i4{44_556`6^YTOMMMM61gd>Ugd|gd3Dkdy $$Ifl\3 0~&l/F t0644 lalytl444444455555 5<5=5>5X5Y5Z5\5]5^5_5`5a5}5~55555555555555555Ʋƭ魠זƆƭyזjh>UUj1h)h>U0JUh>UOJQJaJj h>UU h>Uj7 h)h>U0JUh>Uh)h>U0Jh>UOJQJjh)h>U0JU hhjh>UUj h>UU*55555566 6 6 6 6666,6-6.6/6=6>6?6Y6Z6[6]6^6_6`6a6b6~6666666666666Խʸ٪ٚԍʸ٪}pʸjh>UUjh)h>U0JUjh>UUj%h)h>U0JUh>Uh>UOJQJaJ hhjh>UUjh>UU h>Uh)h>U0Jjh)h>U0JUj+h)h>U0JU+`66777V88 9e99 :i::);;;6<< =^==>r>>*???6@@e61gd>U6666666666677777777747576777_7g7h7i777777777777ɿɲɿ|sh>UOJQJ]jh>UUh)h>U0J6jh)h>U0JUh>UOJQJaJ hhjh>UUjh>UU h>Ujh)h>U0JUh>Uh)h>U0Jjh)h>U0JUh>UOJQJ&7777777777777778888384858O8P8Q8S8T8U8V8W8X8t8u8v8w88888888888Խʸ٫ٛԎʸ٫~qʸj~h>UUjh)h>U0JUjh>UUjh)h>U0JUh>Uh>UOJQJ] hhjh>UUjh>UU h>Uh)h>U0Jjh)h>U0JUj h)h>U0JU,8888888888999 9 9 9 9 99*9+9,9-9B9C9D9^9_9`9b9c9d9e9f9g999999999йƴЍƴtjh)h>U0JUh>UOJQJ]jrh>UUjh)h>U0JUh>UOJQJaJ hhjxh>UUjh>UU h>Ujh)h>U0JUh>Uh)h>U0Jjh)h>U0JU*9999999999999999:::::: : : :':(:):*:F:G:H:b:c:d:f:g:h:i:j:k:::::İī髞Ďī髁qjh)h>U0JUj`h>UUjh)h>U0JUjfh>UU h>Ujh)h>U0JUh>Uh)h>U0Jh>UOJQJaJjh)h>U0JU hhjh>UUjlh>UU,:::::::::::::::::;;;";#;$;&;';(;);*;+;G;H;I;J;i;j;k;;;;;;;;;;;;xh>UOJQJaJjNh>UUjh)h>U0JUjTh>UUjh)h>U0JUh>Uh>UOJQJ]jh)h>U0JU hhjZh>UUjh>UU h>Uh)h>U0J.;;;;;;;;;;;;;;;;<<<<<</<0<1<3<4<5<6<7<8<T<U<V<W<<<<<<<<<<Խʸ٫ٛԎʸ٫~qʸjUUj h)h>U0JUjB h>UUjh)h>U0JUh>Uh>UOJQJ] hhjHh>UUjh>UU h>Uh)h>U0Jjh)h>U0JUjh)h>U0JU+<<<<<<<<<<<=== = = = = ==*=+=,=-=;=<===W=X=Y=[=\=]=^=_=`=|=}=~======ǽǰǽdžvǽj#h)h>U0JUj0#h>UUj"h)h>U0JUh>UOJQJ hhj6"h>UUjh>UU h>Uj!h)h>U0JUh>Uh)h>U0Jjh)h>U0JUh>UOJQJaJ+================ > > >>>>>>>/>0>1>2>O>P>Q>k>l>m>o>p>q>r>s>t>>>űק颕ŅŢxj&h>UUj%h)h>U0JUj$%h>UU h>Uh)h>U0J\j$h)h>U0JUh>Uh)h>U0Jh>UOJQJ]jh)h>U0JU hhjh>UUj*$h>UU*>>>>>>>>>>>>>>>>>>>?? ?#?$?%?'?(?)?*?+?,?H?I?J?K?`?a?b?|?}?~?????Խʸ٫ٛԎʸ٫~qʸj )h>UUj(h)h>U0JUj(h>UUj'h)h>U0JUh>Uh>UOJQJ] hhj'h>UUjh>UU h>Uh)h>U0Jjh)h>U0JUj&h)h>U0JU,???????????????????????@@@/@0@1@3@4@5@6@7@8@T@U@V@W@m@n@o@@@@йƴЎƴ~qj+h>UUj}+h)h>U0JUj+h>UUj*h)h>U0JUh>UOJQJ] hhj*h>UUjh>UU h>Uj)h)h>U0JUh>Uh)h>U0Jjh)h>U0JU,@@@@@@@@@@@@@@@@@@@@@@@AA A AAAA8A9A:AA?A@AAA]A^A_A`ArAsAtAAѽѸћѸ~Ѹjk.h)h>U0JUj-h>UUjq-h)h>U0JUj,h>UU h>Ujw,h)h>U0JUh>Uh)h>U0Jh>UOJQJ]jh)h>U0JUjh>UU hh.@@?AAA^BB0CCDqDDEkEE"FFFU6eAAAAAAAAAAAAAAAAAAAAAAAAABBBB;BUUj_0h)h>U0JUh>UOJQJaJj/h>UU h>Uje/h)h>U0JUh>Uh)h>U0Jh>UOJQJ]jh)h>U0JU hhjh>UUj.h>UU*}B~BBBBBBBBBBBBBBBBBB CCC)C*C+C-C.C/C0C1C2CNCOCPCQCCCCCCCCԽʸ٫ٛԎʸ٫viʸj3h>UUjM3h)h>U0JUh>UOJQJj2h>UUjS2h)h>U0JUh>Uh>UOJQJ] hhj1h>UUjh>UU h>Uh)h>U0Jjh)h>U0JUjY1h)h>U0JU)CCCCCCCCCCCCCCCCCCDDDDD D!D"DNDODPDjDkDlDnDoDpDqDrDsDDDDDDDDDֽֽ֛~th)h>U0J\j;6h)h>U0JUj5h>UUjA5h)h>U0JU hhj4h>UU h>UjG4h)h>U0JUh>Uh)h>U0Jh>UOJQJaJjh)h>U0JUjh>UU-DDDDDDDDDDDDDDDDEEEEEEEEE5E6E7E8EHEIEJEdEeEfEhEiEjEkElEmEEEűק颕Ņקxj8h>UUj/8h)h>U0JUj7h>UU h>Uh)h>U0J\j57h)h>U0JUh>Uh)h>U0Jh>UOJQJ]jh)h>U0JU hhjh>UUj6h>UU*EEEEEEEEEEEEEEEEEEEEFFFFFF F!F"F#F$F@FAFBFCFbFcFdF~FӼɷ⥡ӄɷz⥡jj;h)h>U0JUh>UOJQJaJj:h>UUj#:h)h>U0JUh>Uh)h>U0Jh>UOJQJ] hhj9h>UUjh>UU h>Uh)h>U0J\jh)h>U0JUj)9h)h>U0JU&~FFFFFFFFFFFFFFFFFFFFFFFFFFFFFGGG5G6G7G9G:G;GGZG[Gİī髞זĆīyj=h>UUj=h)h>U0JUh>UOJQJj<h>UU h>Uj<h)h>U0JUh>Uh)h>U0Jh>UOJQJaJjh)h>U0JU hhjh>UUj;h>UU*[G\G]GrGsGtGGGGGGGGGGGGGGGGGGGGGGGGGGHHHHBHCHDHEH_H`HԽʸ٫ٛԎʸ٫~tgj|@h>UUh)h>U0J6j?h)h>U0JUj?h>UUj?h)h>U0JUh>Uh>UOJQJ] hhj>h>UUjh>UU h>Uh)h>U0Jjh)h>U0JUj >h)h>U0JU(`HaHcHdHeHfHgHhHHHHHHHHHHHHHHHHHHHHHHHHIIIIIIIII5I6I7IҾҹҒҹ}mjBh)h>U0JUh>UOJQJjpBh>UUjAh)h>U0JUh>UOJQJaJjvAh>UU h>Uj@h)h>U0JUh>Uh)h>U0Jh>UOJQJ]jh)h>U0JU hhjh>UU*7I8IQIRISImInIoIqIrIsItIuIvIIIIIIIIIIIIIIIIIIIIIJJJJJJ!J"J#J$J%J&JBJCJj^Eh>UUjDh)h>U0JUjdDh>UUjCh)h>U0JUh>Uh>UOJQJ] hhjjCh>UUjh>UU h>Uh)h>U0Jjh)h>U0JU/CJDJEJZJ[J\JvJwJxJzJ{J|J}J~JJJJJJJJJJJJJJJJJJJJJJKKK2K3K4K6K7K8KԽʸ٫ٛԎʸ٫~qʸjLHh>UUjGh)h>U0JUjRGh>UUjFh)h>U0JUh>Uh>UOJQJ] hhjXFh>UUjh>UU h>Uh)h>U0Jjh)h>U0JUjEh)h>U0JU+J9KKK8LLLLLLLM'N(N:NJNKN^NNNNgd gdG$gdQH$ zd\$^`zgd/$ |dd[$\$^`|gd/gd)!gd|gdC1gd>U8K9K:K;KWKXKYKZKoKpKqKKKKKKKKKKKKKKKKKKKKKKKKKKLLLLLLL1L2L3Lɿɲɿɐɿsj:Kh>UUjJh)h>U0JUj@Jh>UUjIh)h>U0JU hhjFIh>UUjh>UU h>UjHh)h>U0JUh>Uh)h>U0Jjh)h>U0JUh>UOJQJ-3L5L6L7L8L9L:LVLWLXLYLfLgLhLLLLLLLLLLLL+M,M-M[M\MkMlM&N'N(N5N9N:N;NҾҹ۟}r}rnrgnch3D h2hNdhM[jh2h U h2h h2h/h/h$>h@0J h2h|jh$>h|0JUj4Lh>UU h>UjKh)h>U0JUh>Uh)h>U0Jh>UOJQJjh)h>U0JUjh>UU hh&;NJNKN^NNNNNOOOOOLQnQvQwQQQQQRRR0RkRlRmRRRRTTTTTAXBXCXSX*[j[[[[[[[[[\\\\&\.\\跱תhM[ h2h jh2h Uhog h2h/ hNd0Jh$>hNd0JhlhM[h/0J5h4 h/0J2hNd hNdhNd h/0Jh$>h/0Jh/ hG$hNdhG$8NOOOOOLQwQQQQRR0RlRmRRSTTTU |d1$\$^`|gd/$ zd\$^`zgd/$ |dd[$\$^`|gd/gd UVVWBXCXSXY*[[\\ \\\\] ^^^^_I_$ zd\$^`zgd/gd/gdQHgdNd |d1$\$^`|gd/gd \\\\\\$],]LaMaNa\aaabbbhv,0Jhv,hv,0J hv,0J hNdhNd h/0J hog0Jh$>h/0J h2hNdh/ h2h/hM[)I__`c``MaNa\aabfch3 <0Jh$>h/0J0llllllqhhhh 0$IfgdT_kdrP$$IflF(  t06    44 layt;pgllllll^UUUU 0$IfgdT_kdQ$$Ifl\( t0644 layt;pgllllmm^UUUU 0$IfgdT_kdQ$$Ifl\( t0644 layt;pgmm m m m m^UUUU 0$IfgdT_kdR$$Ifl\( t0644 layt;pg mmMmGnHndnop^YTT>TT$ zd\$^`zgd/gd :gdNdkdXS$$Ifl\( t0644 layt;pgp*pjpkpwpppp=q`r t t t$t/tuevvvvgdDgdhgdQH$ |dd[$\$^`|gdNd$ zd\$^`zgd/gd  |d1$\$^`|gd//tbttuuuuuuuevfvzv{v|v}v~vvvvvvvvvvvvvvvvvvvvxħ̕ՙ~wsoskbhv,h/0Jh/h7thD hy:hT_hT_j0hhUjCG hhUVhhjhhU hh0J h20JjTh2UjCG h2UVh2jh2Uh$>h/0JhhmHnHu h2h7tjh2h7tUh2h/0J h2h/$vvx~yyy{{}"2̄"#6Ɔm 0d1$\$^`0gd/gdQH |d1$\$^`|gd/xxxyyDyEyZy[ybygyhy}y~yyy{2̄ !"#6ƆꧠϧꜘDzy hNdhNd h/0J hog0Jh2jh2UhNdhv, h2h7tjh2h7tUh$>h/0J h/\ h2hNdh/hDhhmHnHu h2hT_jh2hT_U h2h/hv,h/0J hD0J/ƆNOijklm.9GՎ֎׎+,-.yypylhla hhhNdhv,hhhhmHnHujhhh7tU hhh7t hhh/ hog0Jh$>h/0J hNdhNdh/h2h/0J+jh2h/0J+U hv,0JjhDhv,0JUhv,hv,0JhDhv,0JhDh/0Jhv,h/0J h2h/&mv<؋"Z-.;ϐO̓gd  |d1$\$^`|gd/gdNdgd7tgdhgdQH.;OP['(WXrstuvw+œÜĜМ󨞘xjh }0J+6B* Uphp hNdhNdhGhNd0J hNd0JjhNd0JU hI0Jj&h$>h^0JUjh$>h/0JUjhU0J+6B* Uphp h2hNdhv, h2h/ h/0Jh$>h/0Jh//̓6ʔvw+\vÜĜМ3gdKu\$gdKugdNd |d1$\$^`|gd/gd gd/XYZq jklޣ#*+/0ʥ 9:TUVWtިߨ6"UDE_} 6˰ "#$ǺǺǺг梚hhmHnHujhW1UhW1hW1h/0JhNd h2hNdjhNdhNd0JUhNdhNd0JhNdh/0J hI0J h2h/h/ hNdhNd h/0Jh$>h/0J93YZqƟݟ ($Ifgd7tgd $ zd\$^`zgd/gdNdgd/  (;<KBBBBBB 0$Ifgd7tkd9$$Iflr;z$ t0644 lalyt;pg<=M]^ltKBBBBBB 0$Ifgd7tkd$$Iflr;z$ t0644 lalyt;pgϠKBBBBB 0$Ifgd7tkd$$Iflr;z$ t0644 lalyt;pgϠР KBBBBB 0$Ifgd7tkdg$$Iflr;z$ t0644 lalyt;pg klKFF0F |d1$\$^`|gd/gd kd!$$Iflr;z$ t0644 lalyt;pg*T5ʥVWtߦ%!ߨ6$ zd\$^`zgd/$ |dd[$\$^`|gdNdgdNdgd/ |d1$\$^`|gd/gd gd7t6/C"(:GHOaXO 0$Ifgd7t ($Ifgd kdێ$$Ifl4FB(M t06    44 layt;pg ($Ifgd7tgd Uh_ ($Ifgd kd$$IflFB(M t06    44 layt;pg 0$Ifgd7tϭDEqh__ 0$Ifgd7t ($Ifgd kd0$$IflFB(M t06    44 layt;pgEFOqh__ 0$Ifgd7t ($Ifgd kdِ$$IflFB(M t06    44 layt;pg_}qh__ 0$Ifgd7t ($Ifgd kd$$IflFB(M t06    44 layt;pg}~ 6qh__ 0$Ifgd7t ($Ifgd kd+$$IflFB(M t06    44 layt;pg67K˰qh__ 0$Ifgd7t ($Ifgd kdԒ$$IflFB(M t06    44 layt;pgmn}ͲQqlgQLGGGgd/gdZ$ zd\$^`zgd/gdNd:gdI