ࡱ>  dgYZ[\]^_`abc} bjbj55   __kLoLo|||||#}#}#}~ #}p Á 6ۏۏۏ͕˥_L2|@"||ۏۏ*KKK(|ۏ|ۏKKK1ۏJ#}ӯ6@0pX|K(KpLo U{: PM 005 Project Execution Plan Template and Guide Version 1.1, April 2008 This guide is intended to be read in conjunction with the following template for the development of a Project Execution Plan. As such the Guide should be removed from the front of the final document. Templates for a large range of other project management documents are available at  HYPERLINK "http://www.egovernment.tas.gov.au" 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 Execution Plan? The Project Execution Plan is the road map used by the Project Team to deliver the agreed project outputs. It outlines the responsibilities of the Project Team and key stakeholders. Why would you develop a Project Execution Plan? A Project Execution Plan is developed to expand on the Project Business Plan by specifying the day-to-day (operational) management procedures and control plans including: detailed project plans; resource schedules; quality procedures; reporting procedures; product purchasing and development plans; risk management planning; and project budgets. The document enables those completing the tasks/activities in the project to deliver the expected results, as per the agreed Project Business Plan. When would you develop a Project Execution Plan? Approval to proceed to develop a Project Execution Plan is usually obtained from the acceptance or approval of a preceding stage such as a Project Proposal or Project Business Plan. The Project Execution Plan expands the proposals developed in these documents in order to: document the day-to-day (operational) management and control activities to be undertaken by the Project Team; and gain acceptance by the Project Sponsor to the suitability of these activities. What you need before you start: Agreement to proceed with the development of the Project Execution Plan from the Project Sponsor. Knowledge and understanding of developing detailed project plans, quality plans, implementation and delivery plans, resource scheduling, risk management planning and financial planning. Knowledge and understanding of the Key Elements, as outlined in the Tasmanian Government Project Management Guidelines. Also Advisable: Any of the following documents - Strategic Information Systems Plan, Project Proposal, Process Review Report or Feasibility Study. Departmental Project Management Guidelines. Integration Process: Any endorsed documents (for example a Project Proposal, Project Business Case or Project Business Plan) should be utilised to populate the Project Execution 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 Execution Plan is not a static process, and that all aspects described in the Execution 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 Manager and Project Team. The key is to obtain clear sign-off where scope changes are required during the life of the project. What you will have when you are finished: A completed Project Execution Plan that is ready for acceptance by the Project Sponsor or Proposer. 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. Text in normal font is intended as examples. Text enclosed in is intended to be replaced by whatever it is describing. Where to Get Additional Help Project Management tools and resources that can assist you through each step in your project are available at  HYPERLINK "http://www.egovernment.tas.gov.au" www.egovernment.tas.gov.au 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 strProjectName \* MERGEFORMAT  Project Execution PlanVersion: , Date: Copy: UncontrolledThe 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  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  DOCPROPERTY strVersion \* MERGEFORMAT Date:,dd-mm-yyyy> of the Project Execution Plan. The Project Execution 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 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,Heading 7,1,Heading 8,2,Heading 9,3,Heading,1"  HYPERLINK \l "_Toc196099032" 1 Introduction  PAGEREF _Toc196099032 \h 13  HYPERLINK \l "_Toc196099033" 1.1 Document Purpose  PAGEREF _Toc196099033 \h 13  HYPERLINK \l "_Toc196099034" 1.2 Intended Audience  PAGEREF _Toc196099034 \h 13  HYPERLINK \l "_Toc196099035" 1.3 Project Outputs  PAGEREF _Toc196099035 \h 14  HYPERLINK \l "_Toc196099036" 1.4 Scope of Work  PAGEREF _Toc196099036 \h 14  HYPERLINK \l "_Toc196099037" 2 Management Plan  PAGEREF _Toc196099037 \h 15  HYPERLINK \l "_Toc196099038" 2.1 Management  PAGEREF _Toc196099038 \h 15  HYPERLINK \l "_Toc196099039" 2.1.1 Introduction  PAGEREF _Toc196099039 \h 15  HYPERLINK \l "_Toc196099040" 2.1.2 Sub-Project Management  PAGEREF _Toc196099040 \h 15  HYPERLINK \l "_Toc196099041" 2.1.3 Reference Groups  PAGEREF _Toc196099041 \h 15  HYPERLINK \l "_Toc196099042" 2.1.4 Consultants  PAGEREF _Toc196099042 \h 15  HYPERLINK \l "_Toc196099043" 2.1.5 Working Parties  PAGEREF _Toc196099043 \h 15  HYPERLINK \l "_Toc196099044" 2.2 Status Reporting  PAGEREF _Toc196099044 \h 16  HYPERLINK \l "_Toc196099045" 2.3 Risk Management  PAGEREF _Toc196099045 \h 16  HYPERLINK \l "_Toc196099046" 2.3.1 Risk Assessment  PAGEREF _Toc196099046 \h 16  HYPERLINK \l "_Toc196099047" 2.3.2 Failure to Deliver  PAGEREF _Toc196099047 \h 17  HYPERLINK \l "_Toc196099048" 2.3.3 Acceptance and Review Periods  PAGEREF _Toc196099048 \h 17  HYPERLINK \l "_Toc196099049" 2.3.4 Issues  PAGEREF _Toc196099049 \h 17  HYPERLINK \l "_Toc196099050" 2.3.5 Non-availability of Resources  PAGEREF _Toc196099050 \h 18  HYPERLINK \l "_Toc196099051" 2.4 Provision of Facilities and Equipment  PAGEREF _Toc196099051 \h 18  HYPERLINK \l "_Toc196099052" 2.5 Skills and Resource Requirements  PAGEREF _Toc196099052 \h 18  HYPERLINK \l "_Toc196099053" 2.5.1 Skills and Resources  PAGEREF _Toc196099053 \h 18  HYPERLINK \l "_Toc196099054" 2.5.2 Training  PAGEREF _Toc196099054 \h 19  HYPERLINK \l "_Toc196099055" 2.6 Configuration Management  PAGEREF _Toc196099055 \h 19  HYPERLINK \l "_Toc196099056" 2.6.1 Change Control  PAGEREF _Toc196099056 \h 19  HYPERLINK \l "_Toc196099057" 2.6.2 Problem Reporting and Resolution  PAGEREF _Toc196099057 \h 19  HYPERLINK \l "_Toc196099058" 2.6.3 Incident Reporting  PAGEREF _Toc196099058 \h 20  HYPERLINK \l "_Toc196099059" 2.6.4 Issues Management  PAGEREF _Toc196099059 \h 20  HYPERLINK \l "_Toc196099060" 2.7 Confidentiality  PAGEREF _Toc196099060 \h 20  HYPERLINK \l "_Toc196099061" 2.8 Output Review and Acceptance  PAGEREF _Toc196099061 \h 20  HYPERLINK \l "_Toc196099062" 2.9 Updating this Plan  PAGEREF _Toc196099062 \h 20  HYPERLINK \l "_Toc196099063" 3 Quality Plan  PAGEREF _Toc196099063 \h 21  HYPERLINK \l "_Toc196099064" 3.1 Introduction  PAGEREF _Toc196099064 \h 21  HYPERLINK \l "_Toc196099065" 3.2 Methodologies and Standards  PAGEREF _Toc196099065 \h 21  HYPERLINK \l "_Toc196099066" 3.3 Development Environment  PAGEREF _Toc196099066 \h 21  HYPERLINK \l "_Toc196099067" 3.4 Inspection, Measuring and Test Equipment  PAGEREF _Toc196099067 \h 22  HYPERLINK \l "_Toc196099068" 3.5 Development Cycle  PAGEREF _Toc196099068 \h 22  HYPERLINK \l "_Toc196099069" 3.6 Outputs to be Developed  PAGEREF _Toc196099069 \h 22  HYPERLINK \l "_Toc196099070" 3.7 Project Evaluation  PAGEREF _Toc196099070 \h 22  HYPERLINK \l "_Toc196099071" 3.8 Records  PAGEREF _Toc196099071 \h 23  HYPERLINK \l "_Toc196099072" 3.8.1 Record Keeping  PAGEREF _Toc196099072 \h 23  HYPERLINK \l "_Toc196099073" 3.8.2 Records Required by  PAGEREF _Toc196099073 \h 24  HYPERLINK \l "_Toc196099074" 3.8.3 Retention of Records  PAGEREF _Toc196099074 \h 24  HYPERLINK \l "_Toc196099075" 4 Purchasing Plan  PAGEREF _Toc196099075 \h 25  HYPERLINK \l "_Toc196099076" 4.1 Purchasing Specification  PAGEREF _Toc196099076 \h 25  HYPERLINK \l "_Toc196099077" 4.2 Selection of Suppliers  PAGEREF _Toc196099077 \h 25  HYPERLINK \l "_Toc196099078" 4.3 Subcontractor Management  PAGEREF _Toc196099078 \h 26  HYPERLINK \l "_Toc196099079" 4.4 Inspection and Testing of Purchased Goods & Services  PAGEREF _Toc196099079 \h 26  HYPERLINK \l "_Toc196099080" 4.5 Records Required  PAGEREF _Toc196099080 \h 26  HYPERLINK \l "_Toc196099081" 5 Development Plan  PAGEREF _Toc196099081 \h 27  HYPERLINK \l "_Toc196099082" 5.1 Design and Development Activities  PAGEREF _Toc196099082 \h 27  HYPERLINK \l "_Toc196099083" 5.2 Organisation and Staffing  PAGEREF _Toc196099083 \h 27  HYPERLINK \l "_Toc196099084" 5.3 Design Methodology  PAGEREF _Toc196099084 \h 27  HYPERLINK \l "_Toc196099085" 5.4 Design Input  PAGEREF _Toc196099085 \h 27  HYPERLINK \l "_Toc196099086" 5.5 Design Output  PAGEREF _Toc196099086 \h 28  HYPERLINK \l "_Toc196099087" 5.6 Inspection and Review  PAGEREF _Toc196099087 \h 28  HYPERLINK \l "_Toc196099088" 5.7 Approval and Acceptance  PAGEREF _Toc196099088 \h 28  HYPERLINK \l "_Toc196099089" 5.8 Authorisation and Distribution  PAGEREF _Toc196099089 \h 28  HYPERLINK \l "_Toc196099090" 5.9 Updating and Changing  PAGEREF _Toc196099090 \h 29  HYPERLINK \l "_Toc196099091" 6 Test Plan  PAGEREF _Toc196099091 \h 30  HYPERLINK \l "_Toc196099092" 6.1 Introduction  PAGEREF _Toc196099092 \h 30  HYPERLINK \l "_Toc196099093" 6.2 Unit Testing  PAGEREF _Toc196099093 \h 30  HYPERLINK \l "_Toc196099094" 6.3 System and Integration Testing  PAGEREF _Toc196099094 \h 30  HYPERLINK \l "_Toc196099095" 6.3.1 Approach  PAGEREF _Toc196099095 \h 30  HYPERLINK \l "_Toc196099096" 6.3.2 Review  PAGEREF _Toc196099096 \h 31  HYPERLINK \l "_Toc196099097" 6.4 Acceptance Testing  PAGEREF _Toc196099097 \h 31  HYPERLINK \l "_Toc196099098" 6.4.1 Approach  PAGEREF _Toc196099098 \h 31  HYPERLINK \l "_Toc196099099" 6.4.2 Review  PAGEREF _Toc196099099 \h 31  HYPERLINK \l "_Toc196099100" 6.5 Certification of Test Results  PAGEREF _Toc196099100 \h 31  HYPERLINK \l "_Toc196099101" 7 Implementation and Delivery Plan  PAGEREF _Toc196099101 \h 32  HYPERLINK \l "_Toc196099102" 7.1 Implementation  PAGEREF _Toc196099102 \h 32  HYPERLINK \l "_Toc196099103" 7.2 Handling, Packing, Marking and Delivery  PAGEREF _Toc196099103 \h 32  HYPERLINK \l "_Toc196099104" 8 Output Management Plan  PAGEREF _Toc196099104 \h 33  HYPERLINK \l "_Toc196099105" 8.1 Output Register  PAGEREF _Toc196099105 \h 33  HYPERLINK \l "_Toc196099106" 8.2 Output Identification and Traceability  PAGEREF _Toc196099106 \h 34  HYPERLINK \l "_Toc196099107" 8.3 Version Control  PAGEREF _Toc196099107 \h 34  HYPERLINK \l "_Toc196099108" 8.4 Maintenance of Libraries  PAGEREF _Toc196099108 \h 34  HYPERLINK \l "_Toc196099109" 8.4.1 Migration  PAGEREF _Toc196099109 \h 34  HYPERLINK \l "_Toc196099110" 8.4.2 Backup  PAGEREF _Toc196099110 \h 34  HYPERLINK \l "_Toc196099111" 8.5 Non-conforming Output  PAGEREF _Toc196099111 \h 35  HYPERLINK \l "_Toc196099112" 9 Maintenance Plan  PAGEREF _Toc196099112 \h 36  HYPERLINK \l "_Toc196099113" 10 Project Evaluation Review(s)  PAGEREF _Toc196099113 \h 37  HYPERLINK \l "_Toc196099114" 11 Project Plan  PAGEREF _Toc196099114 \h 38  HYPERLINK \l "_Toc196099115" 11.1 Overall Project Plan  PAGEREF _Toc196099115 \h 38  HYPERLINK \l "_Toc196099116" 12 Appendices  PAGEREF _Toc196099116 \h 39  HYPERLINK \l "_Toc196099117" Appendix A: Name of Appendix  PAGEREF _Toc196099117 \h 41  Introduction Document Purpose Depending on the size and complexity of the project, the need for multiple Project Execution Plans (PEPs) for the Project may arise. Examples include where separate Project Teams are developing specific outputs for different business areas (i.e. as sub-projects). The Project Execution Plan (PEP) is the operational document for the project. It is owned, maintained and utilised by the Project Manager and Project Team to support the delivery of the agreed project outputs. The PEP is the responsibility of the Project Manager and is the road map enabling the effective day-to-day (operational) management and control of the project. The PEP expands on the Project Business Plan which is the approved plan describing what will happen in the project. The PEP details how the Project Team will carry out their tasks/activities to ensure that the what will occur. The document provides new Project Team members, or a new Project Manager with the ability to start during a project, and continue to perform the projects activities in a consistent manner. The document should be reviewed and amended to meet changed conditions during the projects life span. Intended Audience Clearly identify the intended audience of this document, as it may include key representatives from the business area(s), and other stakeholders who will be impacted by the planned outputs. State any assumptions regarding the document up front that may assist the reader, for example: Knowledge of the project and a basic understanding of project management principles and practices is assumed; As the document proceeds through a series of iterations during the life of the project (e.g. after each phase), its structure, emphasis and intended audience may change. Project Outputs Describe specifically the projects outputs. OutputDescriptionA.B.Table  SEQ Table \* ARABIC 1 : Outputs Scope of Work Briefly summarise the scope of the work involved in the project as defined in the Project Business Plan. Within ScopeOutside ScopeA.B.Table  SEQ Table \* ARABIC 2 :  DOCPROPERTY strProjectName \* MERGEFORMAT Project Name Scope of Work Management Plan Management This section may be covered by a reference to the Projects governance structure, i.e. management roles, functions and responsibilities that are defined within Section and Appendix of the Project Business Plan. The project will be managed by who is the Project Manager. The Project Manager is responsible to the Project Sponsor for the delivery of the agreed project outputs. The sub-headings under section 2.1 (2.1.1 2.1.5) may not be required if the above content is adequately covered in the Project Business Plan. Introduction This section expands the operational management of the Project, as defined within the Project Business Plan. Sub-Project Management Define the operational management of the sub- projects if this has not already been defined within the Project Business Plan. Reference Groups Detail any specific reference groups (i.e. function, objectives, membership etc) that are required and have not been defined in the Project Business Plan. Consultants Detail any consultancies (i.e. function, time frame, objectives, management, reporting etc) that are required and have not been defined in the Project Business Plan. Working Parties Detail any specific working parties (i.e. function, responsibilities, time frame, objectives, membership etc) that are required and have not been defined in the Project Business Plan. Status Reporting Describe the provision of project reporting requirements (e.g. content, frequency, audience etc) for the following (if not defined in the Project Business Plan): Project Manager Reference Groups Consultants Working Parties Quality Consultants Cross reference the above reporting requirements with status reporting in the Project Business Plan so as not to duplicate. Clearly define the purpose, content and frequency of project status reports. The following is a generic guide to minimum requirements: the status of the project, which includes monitoring of milestones and budget: for the last reporting period; for the next reporting period; for the remaining period of the project. an issues report (including areas of concern, specific problems, and any action that needs to be taken); and a risk management report (which will specify any changes to the risks identified and the strategies put in place to manage them). Risk Management All projects require on-going risk analysis to be undertaken regularly throughout the life of the project. Analysis should be undertaken with the critical stakeholders. If appropriate, describe how risk management will be conducted. Refer to the Tasmanian Government Project Management Guidelines that contain a section on risk management. Risk assessment and management strategy working documents may be attached as an appendix. Risk Assessment The Project Manager is responsible for: Scheduling and performing risk assessment and developing strategies to manage those risks for each phase of the project as identified within the Project Business Plan. Providing a risk review within status reports to the Steering Committee, which will specify any changes to the risks identified during each phase of the project and the strategies adopted to manage them. Provide details of the following: where the results of each risk assessment will be retained; the frequency of risk assessment; who will be involved in the risk assessment; how the risk assessments will be conducted; what will trigger the implementation of the risk mitigation strategies; how the effectiveness of risk mitigations strategies will be monitored; and the approval mechanism for risk mitigation strategies e.g. Steering Committee approval. Failure to Deliver In the event of the project suffering slippage of greater that then the project schedule and outputs to be delivered shall be reviewed by the Business Owners, Project Sponsor and the Project Manager. The Project Manager shall inform the Steering Committee of the situation and recommend the course of action to be followed. Agreement on how to proceed shall be negotiated by the Project Manager and Steering Committee. Acceptance and Review Periods All review and acceptances shall be completed within of the output being handed to . Should any agreed review period not be met and, in the opinion of the Project Manager, the project is unable to proceed the schedule shall be revisited. Any adjustments for the time lost should be negotiated by the Project Manager with all affected parties. Issues When issues arise which must be resolved between the Business Owner and the Project Manager then the issue shall be advised in writing (using the Open Issues Form) between the Project Manager and the Business Owner. The recipient of the issue shall be responsible for ensuring it is resolved and the resolution communicated in writing to the initiator. Non-availability of Resources Should any agreed resource not be made available as scheduled in the Project Plan (Refer Section X) and, in the opinion of the Project Manager, the Project cannot proceed the schedule shall be revisited. Any adjustments for the time lost should be negotiated by the Project Manager with all affected parties. Provision of Facilities and Equipment Describe what facilities are required by the Project Team (e.g. accommodation, office support, equipment etc) and any specific maintenance requirements. Document the projects environment baseline. Skills and Resource Requirements Skills and Resources The project resource requirements (for entire period or specific phases): Project Manager; Independent Quality Officer and/or Quality Review Consultant; Representatives of the Business Owners; and An external project auditor. Address whether resources are full or part time, as required etc. Describe any specific knowledge and skills required to undertake processes designed to achieve the project outputs (examples): managerial skills and knowledge; strategic and conceptual skills; sound communication, negotiation and consulting skills; capacity to develop innovative solutions; understanding of project and quality management principles and practices; etc The following things need to be addressed: the impact of resources being off-line on projects; how these resources will be released to the project; and from the project when no longer required. Formal agreements may be required to confirm the availability and timeliness of resources. Training What training requirements are there based upon the required skills and resources listed in 2.5.1? How is the training to be provided and conducted? Configuration Management This section may be expanded or condensed depending on the appropriateness to the project. Configuration management is a term often applied to change control procedures (e.g. change requests, problem reporting, issues management etc) undertaken at the project/implementation team level to control change and reduce its impact on the overall project. Change Control Change control shall be used by the Project Manager in accordance with . This process provides the means for: facilitating the introduction of specific project change; allowing the impact of the change to be assessed; providing a method of authorising change; and providing an audit trail of change. Approval of changes is by . Describe the process that will be used to raise, record, review and resolve change requests. Problem Reporting and Resolution Problem reporting is used to record a problem that has been identified in a project. Describe the process that will be used to raise, record, review and resolve problem reports. Incident Reporting Issues Management An issue is a point that requires noting, but is not considered a problem or change. It is anticipated that most of the issues raised within the development phase will be solved by the . However, issues arising which must be resolved between the Business Owner and the Project Manager are referred to the Project Sponsor for resolution (refer to 2.3.4). Describe the process that will be used to raise, record, review and resolve issues. Confidentiality All project members, agents, contractors and subcontractors shall respect the confidentiality of each others business and technology and shall not reveal any information concerning the other party without the written permission of the other party. All agreements and contracts entered into require inclusion of a confidentiality clause. Output Review and Acceptance Describe the process that will be used for the review and acceptance of each output and documentation product, including who is responsible for scheduling the reviews, who will be involved, what will be generated for each accepted output or documentation product. Updating this Plan This plan shall be updated at least at the end of each phase or phases. The updated plan shall be reviewed in accordance with and accepted and issued. The update process includes acceptance by the Project Sponsor. This shall be a new release in accordance with Output management (Refer Section 8). Any changes to standards and procedures and other information specifically documented in this plan shall result in a new release of the plan being prepared and issued. Day to day project plans shall be maintained outside of this plan to reduce the frequency of change. For the project, this document contains only the broad phase plans. Quality Plan Introduction (Cross reference the Project Business Plan to avoid duplication). The quality process is based on the following components: proven methodologies and standards; effective monitoring procedures; effective change, problem and issues management; and review and acceptance procedures. Methodologies and Standards Describe the methodologies and standards that will be utilised and for what purpose. The Project will utilise where appropriate: Quality Management ; Output Development Methodology for software development>; Project Management Methodology ; ; . Describe what will happen if a new version of a methodology or standard is released before the project is complete (ie will they be assessed and adopted if appropriate), how changes to the methodologies and standards will be initiated and implemented, and what will happen to superseded copies of standards and procedures. Development Environment Detail, or summarise if appropriate, the development environment that the project is working within. This effectively defines the projects environment baseline. The development environment is based on: Describe the process that will be used to record and change the development environment. Inspection, Measuring and Test Equipment Describe any special tools, techniques, or inspection, measuring and test equipment which needs to be acquired or developed for verifying the project outputs, or the process of developing those outputs. How will the equipment be verified? Development Cycle Where practical, the elements of the Project will be developed using the : What phases from the methodology will be used, or what life cycle will it follow? Outputs to be Developed The project will develop the following outputs: Examples include new legislation, new finance system, new computer applications, Market program, Functional Requirements Specification, Design Specifications, Test Specifications, User documentation, Maintenance documentation and Training material. All outputs (and components of outputs) shall be managed (Refer Section 8 Output Management Plan). Project Evaluation The measurement of the success of a project provides valuable input in to the continuous improvement for the following phases of a project, or for subsequent projects. This evaluation forms an important part of the Projects Quality Plan. Improvements may be identified in the areas of the planning process, the development process, the utilisation process, or to the project management processes in general. For further details regarding the types and timing of these reviews, refer to Section 10. Records Record Keeping Determine what records will be generated by the project team and retained by the Project Manager, and where they will be retained eg Project Quality Records, Departmental Records Management System. The following is a list of possible records that may be generated: Project Management Records: Project Proposal Project Business Case Feasibility Report Project Business Plan Project Execution Strategy Environment Baseline Client Supplied Output Register Project Execution Plan Incident Reports Incident Report Register Problem Reports Problem Report Register Change Requests Change Request Register Risk Register Open Issue Reports Open Issue Register Managed Output Register Output Distribution List Managed Output Identification Quality Assurance records Records Required by Which of the records created within the project, if any, does the Business Owner require access to? How and when will they access them? How long will they retain them for? The will be provided with copies of any records they request access to. Retention of Records Records shall be retained according to the Archives Act. Additional retention or access requirements may be identified by the Business Owner or Project Sponsor. Purchasing Plan Purchasing Specification This section is to describe the requirements for the purchase of goods and services (including subcontractors). The objective is to ensure purchased goods or services conform to documented requirements. Consider the following: What has to be purchased? Does this include subcontracted development? What is the procedure and processes to be followed for purchases, including approval and authorisation requirements? What guidelines or procedures currently exist that must be adhered to (eg departmental accounting procedures)? What is the process for purchases that arent acceptable (eg damaged goods)? What records are required (eg purchase orders, agreements)? Are there any potential occupational health and safety issues due to the proposed purchases? Selection of Suppliers This section is to describe the requirements for the selection of suppliers (including subcontractors). The objective is to ensure suppliers are selected on the basis of appropriate criteria. Consider the following: What is the criteria for selecting suppliers of off the shelf products (eg purchased through SPS Supply)? What are the criteria for selecting other suppliers, including subcontractors? Example criteria: subcontractors certified to relevant standards; historical performance of the supplier; ability to deliver in a timely and efficient matter; acceptable price for quality required. Subcontractor Management This section is to describe the requirements for the management and control of subcontractors. The objective is to ensure subcontractors are managed appropriately. Consider the following: What methods are to be used for managing and monitoring subcontractors (eg agreements, contracts etc)? What are their reporting requirements? What documents, if any, will the subcontractor provide (eg project schedule, quality plan etc)? Consider confidentiality, intellectual property and training issues. Inspection and Testing of Purchased Goods & Services This section is to describe the requirements for the verification of purchased goods and services. The objective is to ensure goods and services are inspected or tested/assessed upon receipt to ensure conformance with the purchase specification. Consider the following: Where are the verification requirements to be documented (eg purchase order, PEP, agreement etc)? Where will verification occur, and by whom? What inspection and testing is to be performed? What is to be the method of release? Is the performance of the supplier to be rated and documented? Records Required This section is to describe the requirements for the maintenance of purchasing records. Records may include: Purchase orders, agreements/contracts, supplier selection and performance documents, Requests for Information/Tender/Quotation, subcontractor records/documents etc. Project records required may be addressed in one section of this PEP or within individual sections/plans. The approach will depend on the demands of the project. Development Plan Describe the process to be undertaken in the design and development of the projects outputs, as defined in the Quality Plan. Consider the approach for this section, either by describing the design and development activities for each output, or summarising the minimum activities required. Design and Development Activities Describe the process that will be used to design, develop, review, accept, distribute and change outputs. Will all outputs delivered by the project follow the same process? Describe by exception? Example documentation products include Functional Requirements Specification, Design Specifications, Test Specifications, User documentation, Maintenance documentation and Training material. Other outputs may include developed software/systems. Organisation and Staffing If not already addressed within this document, ensure the following: that the skills required for design activities are identified; that the resources (eg staff) are identified and allocated for design activities; and that appropriate management of staff, clients and providers is defined (this may have been addressed in the Project Business Plan under Stakeholder Management Plan (Section 4). Design Methodology Describe the design methodology that activities will conform or reference to, if not already addressed in the Quality Plan. Design and development activities to be performed are to be listed in the project plan. Design Input Describe any design input that will be used. Ensure input is reviewed for applicability before commencing any design or development. Be aware that the development of an output may be input into the design of another output. examples of input may be project management documents (Project Business Case, Project Business Plan etc) or a Functional Requirements Specification. Design Output Describe any specific design output requirements (eg an iterative process will occur to produce a sequence of design specifications). Inspection and Review Describe the responsibilities and processes required. Consider the following: Reviewing outputs, ensuring conformance to methodologies and standards. Review/inspect for content and completeness. Process for defects, deficiencies, related issues, etc. If applicable, programming review strategy linkage to Test Plan. Documentation requirements. Approval and Acceptance Describe the responsibilities and processes required. Consider the following: Approval of output (eg by Project Manager), and acceptance (and non-acceptance) of output (eg by Business Owner). Documentation requirements. Authorisation and Distribution Describe the responsibilities and processes required. Consider the following: Authorisation (of output release) and distribution of output. Output management and maintenance requirements post-acceptance. Documentation requirements. Updating and Changing Describe the responsibilities and processes required. Consider the following: Updating the output (eg future releases following project milestones). Changing the output (eg client change in functional requirements). Requesting change and method of re-release. Documentation requirements. Test Plan If the project deliverables are other than an information system, then this section will require significant change. Ensure appropriate linkages to Purchasing (i.e. subcontract development) where development and/or testing is to be performed by subcontractors. Introduction Describe the testing strategy to be used. The project system deliverables shall be subject to the following testing: unit testing; system and integration testing; and acceptance testing. All testing shall show the version of the output being tested, the version of the test specifications being used and, for acceptance testing, the version of the design specification being tested against. Testing shall be conducted according to the . The activities to be performed are listed in the Project Plan for this phase (Refer Section Project Plan). Unit Testing The programmer shall test each testable unit of programming for conformance to the design by applying tests, recording the tests applied and the results of testing, and filing them in the . Each page used to record testing shall identify the unit of programming tested including the version (or date and time stamp of the load module) and a page number within the set of tests applied to the unit of programming. System and Integration Testing Approach System and Integration testing shall be performed using the system test specifications to ensure that the programming works as a homogenous unit before the acceptance test specifications are applied. Each test specification shall be annotated with the results of the test. Where the output fails to pass testing a Problem Report shall be raised. Incident Reports may be used to identify individual failures for later consolidation under a single Problem Report. Review When the tests have been successfully completed the results of testing shall be reviewed generally as defined in the Development Plan. Acceptance Testing Approach The Representatives shall nominate a person to apply the acceptance test specifications to the system. Describe processes, resourcing and responsibility for developing and approving the acceptance testing plan (eg Business Owners responsibility). The nominated acceptance test specifications shall be applied to the nominated version of the system to test that the system conforms to the nominated version of the design specification. Each test specification shall be annotated with the result of the test. Where the output fails to pass testing then a Problem Report shall be raised. Incident Reports may be used to identify individual failures for later consolidation under a single Problem Report. Review When the tests have been successfully completed the results of testing shall be reviewed generally as defined in the Development Plan. Certification of Test Results Describe the output required (eg acceptance certificate) from the whom the output is being delivered to. Will this be the same for all outputs and ? Ensure responsibilities are adequately defined for all parties involved in confirming and accepting the results of all phases of testing. Implementation and Delivery Plan Implementation Under the Tasmanian Governments project management methodology, implementation of project outputs signifies a major change in responsibility as the Business Owner(s) will utilise the delivered outputs. This stage of a project is often referred to as outcome realisation, as opposed to output delivery. The relationship between this document and any Implementation Plan and Outcome Realisation Plan(s) will need to be determined to ensure all implementation issues are defined within the projects management document set. Consider the following: What documentation will be required from the Project Team and Business Owners perspective for management of the implementation phase (the current methodology advocates a Project Business Plan for the Steering Committee, a Project Execution Plan for the Project Team, and an Outcome Realisation Plan for the Business Owner)? Who is responsible for implementation activities and where will the functions, roles and responsibilities be defined? Does the role of the Project Team, and therefore this document (PEP) cease upon the delivery of the projects outputs? What other specific resources will be required for implementation activities? It is recommended that the Outcome Realisation Plan template be considered prior to this section being developed, to gain an appreciation of the purpose of each project management template advocated by the Tasmanian Government Project Management Guidelines (i.e. Project Business Case, Project Business Plan, Project Execution Plan and Outcome Realisation Plan). Handling, Packing, Marking and Delivery Describe all output delivery requirements. Consider all areas of delivery including packaging, transport, communication, records required, acceptance etc. Output Management Plan Outputs will be identified and managed to ensure that all interested parties know that they have the correct version and can be advised of any changes and/or deficiencies. Output Register An Output Register may be maintained and printed as required. This may record: output identifier/name output type computer file program sub-system software system document: version and description. status: not built/awaiting start built/draft reviewed/inspected approved tested accepted released and nonconforming. status date Output Identification and Traceability Each output to be produced shall be uniquely identified on the Output Register. Where an output is assembled from one or more other outputs then it shall also be identified on the Output Register. All outputs shall be traceable to their parent output as well as the relevant specification and design item. Version Control Outputs and sub-Outputs for release shall be identified by a release number starting at one and increasing by one for each release. Outputs can be identified as follows: all should have a release number (and a revision letter if in draft). the original draft should be Release 0.A; subsequent drafts should be Release 0.B, Release 0.C etc; the accepted and issued document is Release 1.0; subsequent changes in draft form become Release 1.0A, 1.0B etc; and the accepted and issued second version becomes Release 1.1 or Release 2.0, as determined by the Project Manager. Computer file versions may be identified by date and time stamp coupled with file size. Maintenance of Libraries Migration Computer files subject to output management shall be kept in secure libraries. Migration of files into these libraries should be the responsibility of the Project Manager. Backup All documents relating to the project(s) under development and then the implemented system shall be backed up by the < > using the . Any other backup requirement is the responsibility of the Project Manager and should be defined in this PEP. Check the server backup procedure and incorporate it into the projects backup strategy. e.g. Define the frequency of backups, the backup media cycle, labelling requirements, backup/fault logs and other records, storage and security needs etc. Non-conforming Output Describe the process for an Output, which is found to be non-conforming. Maintenance Plan Describe responsibilities and processes for maintenance once project outputs have been accepted by the. Describe how modifications, enhancements, defects and/or deficiencies shall be notified (e.g. Problem Reports, Change Requests etc) and managed. Detail warranty and/or maintenance periods? Detail any options for extending these periods? Project Evaluation Review(s) 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; or A review of the success of the project; or A review of the processes used to produce the outputs; or A combination of the above. Who will perform the review(s)? Who is responsible for the post implementation review process? Who will the report(s) be delivered to? Will all relevant stakeholders be included within the review process? What action will be taken once the report(s) have been received? The Business Owner(s) will use the outputs of the project after successful Acceptance Tests and Implementation. The quality records resulting from the tests and any Problem Reports/Change Requests after implementation will be a major input into the post implementation review. Project Plan Overall Project Plan The Project Schedule is attached at . The Appendix is the baseline Project Schedule for the project. The working copy of the day-to-day project schedule will be maintained by in < >, to reduce the frequency of change to this document. Appendices The following documents and forms may be attached to the Project Execution Plan as appendices to enhance or meet specific project requirements. templates that become working documents in their own right, as they will be updated and managed during the life of the project (e.g. project plan); or additional information provided to support the summary content within the Project Execution Plan (e.g. project development methodology). For example: DefinitionsProvides explanations of terms and concepts used within the Project Execution Plan.Project PlanA snapshot of the Gantt Chart of major project phases, milestones, processes and tasks.Risk AnalysisProvides snapshot details of the current risk assessment and risk management strategies.Budget and ExpenditureProvide snapshot details of the current status of the projects budget and expenditure.Environmental BaselineProvides details of the projects environment (eg office equipment, software, hardware, communications etc) so as to define a baseline that is then managed accordingly.Stakeholder AgreementsIdentify the nature of the relationship to the project and what services or outputs are to be provided to or received from the project.Responsibility MatrixThis matrix summarises stakeholder responsibility for project deliverables. Name of Appendix Separate pages for appendix headers are optional Amend the style for Appendices to suit individual requirements      STYLEREF "Document Name" \* MERGEFORMAT Project Execution Plan  STYLEREF "Document Title" \* MERGEFORMAT Project Execution Plan  STYLEREF "Document Version No" \* MERGEFORMAT Error! No text of specified style in document. Page  PAGE 2 of  NUMPAGES 41 Inter Agency Policy and Projects Unit Department of Premier and Cabinet PM 005 Project Execution Plan: Guide Tasmanian Government Project Management Framework<>  PAGE \* MERGEFORMAT iii Department of   STYLEREF "Document Title" \* MERGEFORMAT Project Execution Plan Version Date: Page  PAGE 41 of  NUMPAGES 41  STYLEREF "Heading 1" \* MERGEFORMAT Appendices  STYLEREF "Heading 1" \* MERGEFORMAT Introduction : Project Execution Plan Version 0.A Page  PAGE 1 of  SECTIONPAGES \* Arabic \* MERGEFORMAT 21  STYLEREF "Heading 7" \* MERGEFORMAT Name of Appendix  STYLEREF "Heading 1" \* MERGEFORMAT Appendices : Project Business Case Version 0.A Page  PAGE 5 of  NUMPAGES41 9;<>CGHI   R d e c d ͿͿͱ͉͜͜͜rrrbhz0JCJOJQJ^JaJ-jhH.Shz0JCJOJQJU^JaJ$hH.Shz0JCJOJQJ^JaJ)jh hz0JCJOJQJU^Jh"#Y0JCJOJQJ^Jhz0JCJOJQJ^J h hz0JCJOJQJ^Jh=U| hhzhzh'hzCJ,aJ$hzCJ,aJ$ 1I #gd&#gdz#xgdz X^gdzgdzgdz$`]`^`a$gdz q LxK[_twEǸoofoooooffZfZh"#Yh"#Y6]^Jh"#Yh"#Y^J&h"#Yh"#Y6CJOJQJ]^JaJ h"#Yh"#YCJOJQJ^JaJh>h"#Y>*h\ hznH tH !h~`hzB*CJ^JaJphOh~`hz5B*^JphO hz^J$hH.Sh~`0JCJOJQJ^JaJh&0JCJOJQJ^JaJh~`0JCJOJQJ^JaJ# {gd"#Ygdz8$8x$d%d&d'dNOPQ[$\$^8`a$gd~`4$ / x$d%d&d'dNOPQ[$\$a$gd~`#gdz#gd& q LdxD[$$ & F<[$\$^`a$gdh[$$ & F[$\$^`a$gdh[$ & F<[$\$^`gdh[$$ & F<[$\$^`a$gdhgd"#Y#gd"#YGWK.: <[$\$gdzgdzgd;C#gd;Cgdpggdpg[$E<[$\$^Egdpg[$ & F<[$\$^`gdhgd=U|EGWmKv~}.:PĺĦęĐĐćvbvZQhhz^Jh>hz>*&h"#Yh"#Y6CJOJQJ]^JaJ h"#Yh"#YCJOJQJ^JaJh"#Yhpg^JhWhH^JhWhpg5\]^JhWhpg5^JhWhH6^JhWhpg6^JhWhpg^J hWhH hWhpgh>hpg>* hpg^J h"#Y^Jh>h"#Y>*h"#Yh"#Y^J9L`  26GIJR`b칱yryykyd hYah| hYah{C hYahYa hYah,kCjhYah,kCUhThX'5\ h%hX'h&h;ChAhz0JhzhZhz5 h>hzhhDhz0J^JjhzU^Jh>hz>* hz^Jh3.ehz0Jhhz^JhJ5hz5^J$9]xxx & FWd<[$\$^`Wgd;C & Fd<[$\$^gdh & F<\$^gdh\$gdzgdzgdz gdz$ & F d<[$\$^gdh$ & F <\$^gdh   Jayp $Ifgd% $Ifgd Ekd$$Ifl"&& t&644 laytz $Ifgd& & FWd<[$\$^`Wgd& & FWd<[$\$^`Wgd;Cab'j^^^ $$Ifa$gd;CEkd$$Ifl"&& t&644 layt;C $Ifgd;CEkdS$$Ifl"&& t&644 layt;Cbx}~Cg$ % & D E r s ϼϼϼϯ~vvjv`\XTh.vh hE*h;ChE*6]hlh;C0J6]jh;CU h;C6]h+h;C6]hh;C6] hh;Ch;C hzhzhzh;Ch;C0JCJaJ$jh;Ch;C0J5CJUaJh;Ch;C0J5CJaJh=U|0J6B*CJaJph$h;Ch;C0J6B*CJaJphCg& $Ifgd;C $Ifgd;Cgdz]gdE*Ekd$$Ifl"&& t&644 layt;C D!""""""""" 0$Ifgd5 0$IfgdE*SgdE*gdE*JkdL$$Ifl&& t&644 lalp yt;C !!!!!,!4!=!P!^!"""""""""""""""#### # # ##F#I#J#K###########($:$;$=$A$ظ˦؉h.vh.v0JhcDh5 ] h=U|] h0Sh5 h[h5 0JaJ hWuUh5 hcDhE*6KH ^J h#hE*h5 hcDhE*CJhcDhE*]h& h7 hE*h.vh=U|hE*jhE*U5""kd$$IflִTI "#&856 t6    44 lapP"""""""""YM 0$$Ifa$gdcDkd$$Ifl\TI&8 t644 lap(0$$Ifa$gd5 0$IfgdE*""""""#### #g^ 0$Ifgd5 kd$$Ifl1\TI&8 t644 lap( 0$IfgdE* # # 0$IfgdE* # #kd$$IflִTI "#&856 t6    44 lapP ##'#G#H#I#J#K#h#v#[VVQ^gdE*SgdE*kd$$Ifl\TI&8 t644 lap( 0$$Ifa$gd5 0$IfgdE* v#~##### ($IfgdE*####1(( 0$Ifgdhkd$$IflrF_& t0644 lap2##### 0$IfgdE* 0$Ifgd5 ## $$1,# ($IfgdE*^gdE*kd$$IflrF_& t0644 lap2$($:$;$<$=$m$ZQQQ 0$IfgdE*kd$$IflF&t t06    44 lap ($IfgdE*A$k$m$w$x$$$$$$$$$$$$$$ % %%%%%%%%%%%%%%%%%%%%%%%%%ν{h&5OJQJjh&Ujh&U h&jhskh&0JUh&hskh&0Jjhskh&0JUhvIjhvIUh| h=U|]h=U|h7 hE*\hE*hcDhE*]h.vhE*0J+m$n$|$$$$$c^UUUU ($IfgdE*^gdE*kdH $$IflF&t t06    44 lap$$$$$$KBB9B 0$Ifgd5 0$IfgdE*kd $$Ifl\ &l/F t0644 lap($$$$$$KBBBB 0$IfgdE*kd $$Ifl\ &l/F t0644 lap($$$$$$KBBBB 0$IfgdE*kd $$Ifl\ &l/F t0644 lap($$$$$ %KBB9B 0$Ifgd5 0$IfgdE*kd $$Ifl\ &l/F t0644 lap( % % %%%,&K=86461gd|-gdE*lkd $$Ifl\ &l/F t0644 lap(%%% & & &%&&&'&)&*&+&,&-&.&J&K&L&M&b&c&d&~&&&&&&&&&&&&&&&&&&&&&&&&&ԽٯٟԒٯقujh&Ujnhskh&0JUjh&Ujthskh&0JUh&h&OJQJaJjh&Ujh&U h&hskh&0Jjhskh&0JUjzhskh&0JU.,&&&1'''.(((=)))E***a++,,,K---U../v//100e16&&&&&'''*'+','.'/'0'1'2'3'O'P'Q'R'c'd'e''''''''''''''''''''Ѻְѓ֊zmjh&Uj\hskh&0JUh&5OJQJjh&Ujbhskh&0JUh&OJQJaJjh&Ujh&U h&jhskh&0JUjhhskh&0JUhskh&0Jh&*''''''''''' ( ( ('((()(+(,(-(.(/(0(L(M(N(O(k(l(m((((((((((((((((((мЖyjJhskh&0JUjh&UjPhskh&0JUh&OJQJ]jh&UjVhskh&0JUh&hskh&0Jh&OJQJaJjhskh&0JUjh&U h&.((((((((())) ))))6)7)8):);)<)=)>)?)[)\)])^)s)t)u))))))))))))))))űŔwj8hskh&0JUjh&Uj>hskh&0JUjh&UjDhskh&0JUh&hskh&0Jh&OJQJ]jhskh&0JU h&jh&Ujh&U.))))))))))) * ***"*#*$*>*?*@*B*C*D*E*F*G*c*d*e*f*{*|*}************İē}h&OJQJ]jh&Uj,hskh&0JUjh&Uj2hskh&0JUh&hskh&0Jh&OJQJaJjhskh&0JUjh&U h&jh&U,***************++++>+?+@+Z+[+\+^+_+`+a+b+c+++++++++++++++++Խٰ٠ԓٰكvjh&Ujhskh&0JUjh&Uj hskh&0JUh&h&OJQJ]jh&Ujh&U h&hskh&0Jjhskh&0JUj&hskh&0JU.++++++++,,,,,,,,,6,7,8,9,b,c,d,~,,,,,,,,,,,,,,,,,,,Ѻֱє֊zmj"h&Uj"hskh&0JUh&OJQJaJj!h&Uj!hskh&0JUh&OJQJ]j h&Ujh&U h&jhskh&0JUj hskh&0JUhskh&0Jh&*,,,,,,, - - --(-)-*-D-E-F-H-I-J-K-L-M-i-j-k-l-z-{-|------------------мЖyj$hskh&0JUjy$h&Uj#hskh&0JUh&OJQJ]j#h&Uj#hskh&0JUh&hskh&0Jh&OJQJaJjhskh&0JUjh&U h&.---------....2.3.4.N.O.P.R.S.T.U.V.W.s.t.u.v...............İךĊ}ךjg'h&Uj&hskh&0JUh&OJQJ]jm&h&Uj%hskh&0JUh&hskh&0Jh&OJQJaJjhskh&0JU h&jh&Ujs%h&U*....../////////9/:/;/5?5[5\5]5^5z5{5|5555555555555555555555Խٰ٠ԓٰylj:h&Ujr:hskh&0JUh&OJQJaJj9h&Ujx9hskh&0JUh&h&5OJQJj8h&Ujh&U h&hskh&0Jjhskh&0JUj~8hskh&0JU*5555566668696:6T6U6V6X6Y6Z6[6\6]6y6z6{6|66666666666666666 7 77(7)7*7ƼƯƼߟƼƒƼ߂Ƽuj=h&Uj`=hskh&0JUj<h&Ujf<hskh&0JUj;h&Ujh&U h&jl;hskh&0JUh&hskh&0Jh&OJQJaJjhskh&0JU.*7,7-7.7/70717M7N7O7P7b7c7d7~7777777777777777777777777 8 888,8-8.8H8мЖyjN@hskh&0JUj?h&UjT?hskh&0JUh&5OJQJj>h&UjZ>hskh&0JUh&hskh&0Jh&OJQJaJjhskh&0JUjh&U h&.H8I8J8L8M8N8O8P8Q8m8n8o8p888888888888888888888888888889999/909İēvj;?;}h&5OJQJjHh&UjHhskh&0JUjGh&Uj$Ghskh&0JUh&h&OJQJaJjhskh&0JUjFh&Ujh&U h&hskh&0J.?;@;A;Q;R;S;m;n;o;q;r;s;t;u;v;;;;;;;;;;;;;;;;;;;;; < < <'<(<)<+<,<-<.</<0<ԽٯٟԒٯقujKh&Uj Khskh&0JUjJh&UjJhskh&0JUh&h&OJQJaJjIh&Ujh&U h&hskh&0Jjhskh&0JUjIhskh&0JU. ;t;;.<<<*=|==1>>>\??@}@@4AAA4BBB@CCCNDPDQDgdEP1e60<L<M<N<O<]<^<_<y<z<{<}<~<<<<<<<<<<<<<<<<<<<<<<<<<== =#=$=%='=(=)=ѺֱєֱwjwNh&UjMhskh&0JUj}Mh&UjMhskh&0JUh&OJQJ]jLh&Ujh&U h&jhskh&0JUjLhskh&0JUhskh&0Jh&-)=*=+=,=H=I=J=K=Y=Z=[=u=v=w=y=z={=|=}=~=====================>>>*>ǽǰǽǽNJǽzǽjPhskh&0JUjkPh&UjOhskh&0JUh&OJQJ]jqOh&Ujh&U h&jNhskh&0JUh&hskh&0Jjhskh&0JUh&OJQJaJ+*>+>,>.>/>0>1>2>3>O>P>Q>R>t>u>v>>>>>>>>>>>>>>>>>>>>>>>>>> ? ?İךĊ}jYSh&UjRhskh&0JUh&5OJQJj_Rh&UjQhskh&0JUh&hskh&0Jh&OJQJaJjhskh&0JU h&jh&UjeQh&U* ? ??9?:?;?U?V?W?Y?Z?[?\?]?^?z?{?|?}????????????????????@ @ @ @ @ԽٯٟԒٯyljGVh&UjUhskh&0JUh&5OJQJjMUh&UjThskh&0JUh&h&OJQJaJjSTh&Ujh&U h&hskh&0Jjhskh&0JUjShskh&0JU* @@@@@-@.@/@0@Z@[@\@v@w@x@z@{@|@}@~@@@@@@@@@@@@@@@@@@@@@@AAA-A.A/AƼƯƼߟƼƒƼ߂Ƽuj5Yh&UjXhskh&0JUj;Xh&UjWhskh&0JUjAWh&Ujh&U h&jVhskh&0JUh&hskh&0Jh&OJQJaJjhskh&0JU./A1A2A3A4A5A6ARASATAUAdAeAfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBB-BмЖyj[hskh&0JUj)[h&UjZhskh&0JUh&OJQJ]j/Zh&UjYhskh&0JUh&hskh&0Jh&OJQJaJjhskh&0JUjh&U h&.-B.B/B1B2B3B4B5B6BRBSBTBUBgBhBiBBBBBBBBBBBBBBBBBBBBBBBBBB C CİךĊ}ךj^h&Uj]hskh&0JUh&5OJQJj]h&Uj\hskh&0JUh&hskh&0Jh&OJQJaJjhskh&0JU h&jh&Uj#\h&U* C CCCCC9C:C;C=C>C?C@CACBC^C_C`CaCzC{C|CCCCCCCCCCCCCCCCCCCCCCԽٰ٠ԓٰyljah&Uj`hskh&0JUh&OJQJaJj `h&Uj_hskh&0JUh&h&5OJQJj_h&Ujh&U h&hskh&0Jjhskh&0JUj^hskh&0JU*CCCCC D DDD+D,D-DGDHDIDKDLDMDNDODQDRDpDyEFHHHIJJEKFKGKWKKKKKKKǽǰǽ顝xogghcDhY]h0WhC0J h&h& h=U|h=U| hY0Jh0WhY0JhYh@h|jhvI5UmHnHujah&Ujh&U h&jahskh&0JUh&hskh&0Jh&5OJQJjhskh&0JU(QDRD_DpDyELFFHHHII.JJFKGKWKKKK ($Ifgd0W$gd0Wgd&gdYgdYgdYgdYgdEPKKKK{pp 0$$Ifgd0Wkd|b$$Ifl0|&  t0644 lapKKKK{pp 0$$Ifgd0Wkd c$$Ifl0|&  t0644 lapKKKKKKKKKKKKKKKKKKWLLLLLLLLLLLLLLLLLLLLL MMNNYNwNN6O7OίΨίÙՂՂ| hN0J h0WhNh0WhN0J hNhNh#Th{Nh{NmH sH  hYahYajhYahYUh0WhY0J h&h&h=U| hYahYh&hRrfmHnHujhYah0WU hYah0WhcDhY]hY/KKKK{pp 0$$Ifgd0Wkdc$$Ifl0|&  t0644 lapKKKKKWLdLrL{vqlg^^ ($IfgdYgdYgdYgd&:gd=U|kdhd$$Ifl0|&  t0644 laprLsLvLwL~~ 0$IfgdYxkd e$$Ifl0|&  t0644 lawLxL{L|L~~ 0$IfgdYxkde$$Ifl0|&  t0644 la|L}L~LL~~ 0$IfgdYxkd&f$$Ifl0|&  t0644 laLLLLL MMN7O8OEOOO}xsnnnninngdNgdNgdNgdNgd&:gd=U|xkdf$$Ifl0|&  t0644 la 7O8OEO|OOOOOOWPXPYPjPQQQQQQQQRRRRS3S.V/V0V@VWWWXXYb[c[d[[[[\#\$\&\úúú}v h#Th% h#ThLh&hL0J h#Th#Th% hL0Jh1hL0J hLhL h=U|0J h j0Jh1h j0J hLh jh1hN0J h&h& hN0Jh&h&0Jh&hN0J hNhN h=U|h=U|.OOXPYPjPQQQQQQRRR5SESVSbSrSSTTTTUgd jgd jgd jgdLgd jgdLgd jgdNgdNU@UU/V0V@VVWWWX)XXYYYZJZvZZ [c[d[w[gd#Tgd/Cgd/CgdLgdLgdLgdLgd=U|gd jgd j&\5\+],]-]]]]]]^^G_f_aaabbbbccdejfkflfuf g g g%ghhhiii jejfjgjj9k:k;kMkNkž˵ž曔hhK hhK0Jh1hhK0J hBhhK hhKhhK h 2&0Jh1h 2&0Jh 2&h#Th#k0J h%h% h#k0Jh1h#k0Jh&h#k0Jh&h&0Jh#kh&hL hLhL h#ThL0w[,]-]K]]^^^A`_`aaaUbbbbbccRc~ccc\d}ddgd#kgd#kgd#kgd#kgd/CddeJeNeyeeefkflfuf g g%gghhhiQiiii jfjgdhKgd 2&gd 2&gd 2&gd 2&gd#kgd#kfjgjjj:k;kNkOkakkkl3m4mDm=nnnnoooqqfrsrgdgdgdgdhKgd1gdhKgdhKNkOkakkkkl4ll2m3m4mmmnnnnoooPpdperfrrrssss t t tttGtJuSuFwGwHw`wxxx.xxxܿʱ|| h8{1h8{1 h8{10Jh [ h#Th#T h0J h1h [ h1hh1h0J hh h [hh hhKh [hhK hhKh1 h [hhK h%h% hhK0Jh1hhK0J hhKhhK h1h10srrrr sAsvssss t tGtttVuuvGwHw`wxx-x.xxxxgd [gdgdgdxxxyyyyyyyyyyyz&zwzxzyzzzz{{{{{{"|#|6|*~+~,~C~fg678MN] 7ɂƺƺƺƺƴϤϠh hy6]h1h0J h0J h [0J hy0Jh1hy0Jhy hhh1h8{1h [ h0Jh1h0Jh h8{1h8{1?xyyy$z&zxzyzzzz{{"|#|6|}+~,~4~C~ Lhygdygdygdygdygdygdgdgd0IYq΀78] }4gdygdygdgdgdygdy345^RSTkĈňވ͊Ίϊ456G ./0R )ȓ!"#1Ζ'()A=$%&<[\]^hlmnľľľľľľľľľľ hk%0JhR{hk%0J hk%hk% hKL0Jh1hKL0JhKL h0J hh hzo0Jh1hzo0J hzohzoh#ThhyB4E^*B\mSTk,DAiňވgdgdzogdzogdzogdzo)Ίϊuь56GY /0RgdFtgdFtgdFtgdzogdzogdgdzo)nȓ"#1Ζdɗ ()gd zgd zgdgdFtgdFtgdFt)Aw=sə %&<rњ@\]hݛmngdk%gdk%gdgd zgd zgd zn{"6wxhopw#$gdk%gdk%gdk%gdk%n{vwxnop"#$yz{123[˯mno¹¹Ưƨڨ h,hBh, h,0Jhh,0JhR{h,0J h,h,h#T hU`0JhR{hU`0JhU` hh h#Th#T hk%0Jh hk%hB hk%hhk%hR{hk%0J hk%hk%3$(z{dS/GyǬ23[gdU`gdU`gdU`gdU`gdk%gdk%gdk%˯2>LT_oyҰ۰gdgd,gd,gd,gd,gd,gdU`;no)oӳH+5HCDgd,gd,gd,gd,BCDEVٸڸɹʹ˹̹6>|bc#$&'()*;<huh,CJ aJ hcDh,6]hx*h,0JhBh hR{0J hB0Jh#T hU`0J hh h,0JhR{h,0J h,hBh, h,h, h,h#T9DV۸ʹ˹޺@zcɽ޽(gd9gd9gd9gd9gd9,pxkd@g$$Ifl0F & t0644 la 0$Ifgd9 ($Ifgd9gd9~u 0$Ifgd9 ($Ifgd9xkdg$$Ifl0F & t0644 lab~u 0$Ifgd9 ($Ifgd9xkdZh$$Ifl0F & t0644 labcz#~u 0$Ifgd9 ($Ifgd9xkdh$$Ifl0F & t0644 la#$;~u 0$Ifgd9 ($Ifgd9xkdti$$Ifl0F & t0644 la&~u 0$Ifgd9 ($Ifgd9xkdj$$Ifl0F & t0644 la&'()*<m}tomo)gds >gd%_gd9gd9xkdj$$Ifl0F & t0644 la -.?DEFGxyмǼxxh [mHnHsH ujh [UmH sH h [mH sH h [5\mHnHsH uhRrfh [\mHnHsH u h^I]h [jh^I]h [Uh [mHnHuh [jh [Uhf<jhf<U h%_h,h%_ hh h%_0J,F?sgd& $dNgdz3gdz$$dNa$gdz$a$gdz $xa$gdz)gds>?pqrstɳskkbk[NhZrh [B*CJph hD!h [h>mHnHujh [Uj *h [<U*j *h[h [<U* h[h [h [ h\ h [ hH.Sh [5B*CJaJph*jh [5B*CJUmHnHphuh [5B*CJaJph hX0h [5B*CJaJphh [B*CJphhX0h [B*CJph)JnoPQRSgd%_ (#$dN $dNgd%_gd%_xgd%_ $dNgds3gd;C$$dNa$gd;C"'()IJOPVWYZ^_ijlmnopȽȶ~~l_lh%_h [B*CJph"jh%_h [B*CJUphh>mHnHsH ujh [UmH sH h [mH sH h>mHnHuh>h>\mHnHsH u h^I]h [jh^I]h [Uh [jh [UmHnHu hD!h [h [5B*CJaJph hZrh [5B*CJaJph #$KLNOPSTyz¹²ʩ{e{¹+h>h>B*CJ\mHnHphsH uh%_h [B*CJphh [0JmHnHu h [0Jjh [0JU h [aJh [6]aJ h [6]h [mHnHujh [Uh [h%_h [6B*CJ]ph"jh%_h [B*CJUphh>B*CJmHnHphu' >gd%_ (#$dN &dPgdd>  h%_h,hf<h [h [0J6]aJmHnHuh [0J6]aJjh [0J6U]aJ h [6]6&P 1h:pz. A!n"n#$%nn =0&P 1h:pz. A!n"n#$%nn P 9 0&P 1h:pbrL. A!n"n#$% 6&P 1h:pz. A!n"n#$% 9 0&P 1h:pbrL. A!n"n#$% 6&P 1h:p5 . A!n"n#$% 9 0&P 1h:pbrL. A!n"n#$%nn 9 0&P 1h:pbrL. A!n"n#$% 9 0&P 1h:pbrL. A!n"n#$%n0 FWAw 'ֺ{?5JFIF,,KExifMM*bj(1r2i-'-'Adobe Photoshop CS2 Windows2006:11:06 17:44:07b$&(.HHJFIFHH Adobe_CMAdobed            " ?   3!1AQa"q2B#$Rb34rC%Scs5&DTdE£t6UeuF'Vfv7GWgw5!1AQaq"2B#R3$brCScs4%&5DTdEU6teuFVfv'7GWgw ?TI%)$IJI$RL5995 S_3V]NI`3&c_=Oi]7Yz^?nnM8<>k[\dm[9G5^ϭ_z@?f[ِ-}?cϥ?z~S׮}e~t: }<ֱF=^RL_RJlt/tZ3335/"DL(jOu?^Y$6U>2)oK}?*n/H遒^1w6Uq?eǤ=/;t 7T"w4;[Hʲ RRnn7D++uw`CI4+C˟sc,P8Icr1g͔ILI$JTI%)$IJI$SOuU1D<ss1`eUO:6 T4nu6}oweTW갖U vʄ aC&Bxe? 1H /{1+"컜yuֽWZg}e;q`MF(sfYj7OXƱhhư'I$ӯ7m&Kw~T}Ǐ~ܚōn{|D9 d Q'`{5bprl˲]Hk^]@n A.wo%ە'heHҔ9qJԒI+ TI$TI%)$IJX[^`᭠!F1m;ctiۻ*{Vy:~%hskUsa};s{5ybt2Xt6F~muxU'c1r7oz|"lO jgq_&{}kkv5r:oͮGܢߠm?_xl臨g=u[]kxmtqU[?oCX3}|eOݕk3]>m/_kC@k@ u2C!I$3$IOTI%)$*? ?hĮovm{{nĔi.zV'Tg je-p9vEw{}QU餧m$;1vFEXkZ0YOvcCvi)Xc@d ]M'Ӷyg-Vr諒X9oR1>Ey~5X>+*sm(N5 TYlg]'T aic~>¡#'cV 2ǀvߡ]vYg yd*rnSM4ThcjZ8kkZ>3 1[p_nsލOSͧV6׆rY_zIQsv32\zٻo+)I$JTI%)dlįY_Ŭu|ԺVoNf=no-ݷ$ft>- ?,?OuapzUԹ􌷀VZ_]Xc]M?Vf}[˰H\c]{~?XT '+6;>N{}~SҺ^=Ay{Pf.c}=%z:~?Vt|}mulPʳhk>=?ߡZXTՎ:V8y9xe[`qbf W5S·S'ܚ1}o̳#gوp9=ZJV{ I@W%+Uf.jr+zMuggV?I:_@=?oW8Sov:ާyZsznm1Aoo%8xITj:7s+sѳ,o~؃o\NOϫxOzqmC%}{-ȱY=J mn6Jr=_Wwz~Stv;t~~ϥc۩qTm$#WmQ>bXW\PMU=l[W~}^^qܛe l~wo;zgԻ0:Z5מnCۓh/6s~Զz-ΙӎF鞧qqb7zlm>vwmޒ5ȶĶq{`$ϵvW[[aOKu]>qǥ7:Ykoƨ?"8Rk?.=W{?Vz~g\o_}?fʮŵ[X!wWc#U~Jpq1'Ve3qrk0,c^ߵ9챵ע.SUo,Ժ1kj5c1j#YzRI$_iNz n+#[?Y/RӮ;1z9cmyݞ>g˫'EZެՙR ]eQunu|;kqOlR{SfuwE_h֗2힣t^ޫ0Z3)wm/hs W2~d +s8}BfUFp>S݆gwz޵o7t\'u.!{j猛*7ݕWekIO}pį;{+pGWso}omV^s>WUk몿>a1<}g}IO{NFm$o;kU^_\ƬQwٝK'.fU[r=MS<7! sYit+s}>=?DufdlL[N;Gk}+eε؍ʿF_S#i)z\q7m lkXeϴ?,_*jޢX-ͱ_(uYƷrj})-01f˺59b8~S߾/S^'9U^z0[t:׏krrg.UbS R=?~g>+E:Hos߶w%fc^_a۟}._J뎦˻#dfg櫟UO}###߉г5^:ckv[q#Y}>J{:vمaxǵ^ױeVW{k~T :[r[^FCij-m#ސsߌގFocme5m2oS7u^NVgTsv́Y/6X{7ъ톶fowN~+YvV2lJwhՋf5VbUޡY4YS/n.@mMvUgb)Skq6=ofE{/mMok}F7dtvtjvgռ[@]߷ލ$TOXٴ7iơ-n@ȺcQ2U]>%>oYz~Nel±SqZSϿPKYnO')g_-UQu^-(9SZʬud=ϧbJ53=ogqLWw߱_9wmwާ ^I%?C}\?'o}ߩ3;~Gai{}?R#ԟlw_-$Z?joٟk66Ii'r$I_/O잛~ǧO~f?o;lGS&G7SOw>mV>fG=OS$eO0~/Wf76-n`WnV#|7~[I%?H/?6}?z{I6~.4ٕ_mgwI_7$o}ԗ"a{?K\Ɠ_+$t>ʾ7oz_EI)GV;}z;ϻOf@b?fgvz;9>6kWΩ$ Photoshop 3.08BIM8BIM%F &Vڰw8BIM/JHH@Rg(8BIMxHH@Rg(8BIM,,8BIM&?8BIM 8BIM8BIM 8BIM 8BIM' 8BIMH/fflff/ff2Z5-8BIMp8BIM@@8BIM8BIMQ$bTasGov_Vert(C)b$nullboundsObjcRct1Top longLeftlongBtomlong$RghtlongbslicesVlLsObjcslicesliceIDlonggroupIDlongoriginenum ESliceOrigin autoGeneratedTypeenum ESliceTypeImg boundsObjcRct1Top longLeftlongBtomlong$RghtlongburlTEXTnullTEXTMsgeTEXTaltTagTEXTcellTextIsHTMLboolcellTextTEXT horzAlignenumESliceHorzAligndefault vertAlignenumESliceVertAligndefault bgColorTypeenumESliceBGColorTypeNone topOutsetlong leftOutsetlong bottomOutsetlong rightOutsetlong8BIM( ?8BIM8BIM 1JFIFHH Adobe_CMAdobed            " ?   3!1AQa"q2B#$Rb34rC%Scs5&DTdE£t6UeuF'Vfv7GWgw5!1AQaq"2B#R3$brCScs4%&5DTdEU6teuFVfv'7GWgw ?TI%)$IJI$RL5995 S_3V]NI`3&c_=Oi]7Yz^?nnM8<>k[\dm[9G5^ϭ_z@?f[ِ-}?cϥ?z~S׮}e~t: }<ֱF=^RL_RJlt/tZ3335/"DL(jOu?^Y$6U>2)oK}?*n/H遒^1w6Uq?eǤ=/;t 7T"w4;[Hʲ RRnn7D++uw`CI4+C˟sc,P8Icr1g͔ILI$JTI%)$IJI$SOuU1D<ss1`eUO:6 T4nu6}oweTW갖U vʄ aC&Bxe? 1H /{1+"컜yuֽWZg}e;q`MF(sfYj7OXƱhhư'I$ӯ7m&Kw~T}Ǐ~ܚōn{|D9 d Q'`{5bprl˲]Hk^]@n A.wo%ە'heHҔ9qJԒI+ TI$TI%)$IJX[^`᭠!F1m;ctiۻ*{Vy:~%hskUsa};s{5ybt2Xt6F~muxU'c1r7oz|"lO jgq_&{}kkv5r:oͮGܢߠm?_xl臨g=u[]kxmtqU[?oCX3}|eOݕk3]>m/_kC@k@ u2C!I$3$IOTI%)$*? ?hĮovm{{nĔi.zV'Tg je-p9vEw{}QU餧m$;1vFEXkZ0YOvcCvi)Xc@d ]M'Ӷyg-Vr諒X9oR1>Ey~5X>+*sm(N5 TYlg]'T aic~>¡#'cV 2ǀvߡ]vYg yd*rnSM4ThcjZ8kkZ>3 1[p_nsލOSͧV6׆rY_zIQsv32\zٻo+)I$JTI%)dlįY_Ŭu|ԺVoNf=no-ݷ$ft>- ?,?OuapzUԹ􌷀VZ_]Xc]M?Vf}[˰H\c]{~?XT '+6;>N{}~SҺ^=Ay{Pf.c}=%z:~?Vt|}mulPʳhk>=?ߡZXTՎ:V8y9xe[`qbf W5S·S'ܚ1}o̳#gوp9=ZJV{ I@W%+Uf.jr+zMuggV?I:_@=?oW8Sov:ާyZsznm1Aoo%8xITj:7s+sѳ,o~؃o\NOϫxOzqmC%}{-ȱY=J mn6Jr=_Wwz~Stv;t~~ϥc۩qTm$#WmQ>bXW\PMU=l[W~}^^qܛe l~wo;zgԻ0:Z5מnCۓh/6s~Զz-ΙӎF鞧qqb7zlm>vwmޒ5ȶĶq{`$ϵvW[[aOKu]>qǥ7:Ykoƨ?"8Rk?.=W{?Vz~g\o_}?fʮŵ[X!wWc#U~Jpq1'Ve3qrk0,c^ߵ9챵ע.SUo,Ժ1kj5c1j#YzRI$_iNz n+#[?Y/RӮ;1z9cmyݞ>g˫'EZެՙR ]eQunu|;kqOlR{SfuwE_h֗2힣t^ޫ0Z3)wm/hs W2~d +s8}BfUFp>S݆gwz޵o7t\'u.!{j猛*7ݕWekIO}pį;{+pGWso}omV^s>WUk몿>a1<}g}IO{NFm$o;kU^_\ƬQwٝK'.fU[r=MS<7! sYit+s}>=?DufdlL[N;Gk}+eε؍ʿF_S#i)z\q7m lkXeϴ?,_*jޢX-ͱ_(uYƷrj})-01f˺59b8~S߾/S^'9U^z0[t:׏krrg.UbS R=?~g>+E:Hos߶w%fc^_a۟}._J뎦˻#dfg櫟UO}###߉г5^:ckv[q#Y}>J{:vمaxǵ^ױeVW{k~T :[r[^FCij-m#ސsߌގFocme5m2oS7u^NVgTsv́Y/6X{7ъ톶fowN~+YvV2lJwhՋf5VbUޡY4YS/n.@mMvUgb)Skq6=ofE{/mMok}F7dtvtjvgռ[@]߷ލ$TOXٴ7iơ-n@ȺcQ2U]>%>oYz~Nel±SqZSϿPKYnO')g_-UQu^-(9SZʬud=ϧbJ53=ogqLWw߱_9wmwާ ^I%?C}\?'o}ߩ3;~Gai{}?R#ԟlw_-$Z?joٟk66Ii'r$I_/O잛~ǧO~f?o;lGS&G7SOw>mV>fG=OS$eO0~/Wf76-n`WnV#|7~[I%?H/?6}?z{I6~.4ٕ_mgwI_7$o}ԗ"a{?K\Ɠ_+$t>ʾ7oz_EI)GV;}z;ϻOf@b?fgvz;9>6kWΩ$8BIM!UAdobe PhotoshopAdobe Photoshop CS28BIM:http://ns.adobe.com/xap/1.0/ image/jpeg Adobe Photoshop CS2 Windows 2006-11-06T17:44:07+11:00 2006-11-06T17:44:07+11:00 2006-11-06T17:44:07+11:00 uuid:4101FB14626DDB11B2EEC042F774E7EE uuid:4201FB14626DDB11B2EEC042F774E7EE uuid:501134F2593C11DB8BDDCDA9EFA7DE98 uuid:7694CAF0593A11DB8BDDCDA9EFA7DE98 3 sRGB IEC61966-2.1 1 3000000/10000 3000000/10000 2 256,257,258,259,262,274,277,284,530,531,282,283,296,301,318,319,529,532,306,270,271,272,305,315,33432;B2C832A48C3409D236D01C3EF73E0836 354 292 1 36864,40960,40961,37121,37122,40962,40963,37510,40964,36867,36868,33434,33437,34850,34852,34855,34856,37377,37378,37379,37380,37381,37382,37383,37384,37385,37386,37396,41483,41484,41486,41487,41488,41492,41493,41495,41728,41729,41730,41985,41986,41987,41988,41989,41990,41991,41992,41993,41994,41995,41996,42016,0,2,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,20,22,23,24,25,26,27,28,30;4085A3FFBAE14923DFEA6514CAE55648