• Section 1 - Purpose of Policy
• Section 2 - Definitions
• Section 3 - Application and Scope - Exclusions or Special Conditions
• Section 4 - Business Case and Approval
• Section 5 - Project Plan
• Section 6 - Steering Committee
• Section 7 - Project Administration
• Section 8 - Document Management
• Section 9 - Implementation
• Section 10 - Post Implementation Review
• Section 11 - Roles and Responsibilities
• Section 12 - Appendix 1: The Business Case
• Overview
• Format of the Business Case
• Key Issues to be Addressed in the Business Case
• The Project Reasons, Objectives and Scope
• Review of Options
• Impact Statements
• Prospective Partners
• Comparison of Options and Recommendations
• Section 13 - Appendix 2:Discounted Cash Flow
• Section 14 - Appendix 3: Project Plan
• Project Plan
• Key Tasks to be Addressed in Project Plans

Section 1 - Purpose of Policy

(1) This Policy establishes a University wide process for the development and approval of projects.

Section 2 - Definitions

(2) Not Available.

Section 3 - Application and Scope - Exclusions or Special Conditions

(3) This Policy applies to projects in the University that:

1. involve the commitment of University funds (including recurrent funds or staff time of an equivalent value) with a value in excess of $200,000 in one (1) year; or
2. involve projected revenue in excess of $500,000.

(4) Projects covered by the scope of this Policy are referred to as “relevant projects” in the remainder of this Policy.

(5) Academic research grants or projects are excluded from the scope of this Policy.

(6) Relevant projects must comply with all requirements of the University’s Purchasing and Procurement Policy, i.e. selection of outside providers must be based on the appropriate methodology prescribed in that policy.

(7) This Policy applies to relevant projects in all areas of the University.

(8) The Policy prescribes minimum standards for the conduct of relevant projects. Units are able to implement more extensive processes or methodologies for projects within their area of responsibility. 

Section 4 - Business Case and Approval

(9) Relevant projects must be approved, at the outset, by a person with expenditure delegation at the necessary level. Where the nature or scope of an approved project changes significantly during the life of the project, such changes must also be approved.

(10) The request for approval must include a business case in the format specified in Appendix 1.

(11) The business case is to be accompanied by a cost benefit analysis that assesses the return on investment, in the form of the (discounted cash flow) model shown in Appendix 2. This assessment should include:

1. start up costs;
2. hurdle rate based on the University’s cost of funds;
3. any savings or increases in revenue;
4. likely life of the savings or new revenue;
5. potential savings or revenue.

(12) Each project must identify a Director, Dean or Senior Executive who is responsible for the project and who is designated as the project sponsor.

(13) Each project must identify a designated Project Manager who is to be responsible for the management and administration of the project and for conducting the project in accordance with this Policy.

(14) Each business case might include a budget for the project, including an identification of the proposed source of funds and a clear indication of any additional funds being sought.

Section 5 - Project Plan

(15) The business case shall be accompanied or followed by a project plan that:

1. sets out the principal tasks;
2. specifies milestones;
3. specifies proposed dates for the achievement of milestones.

Section 6 - Steering Committee

(16) A steering committee shall be established for all projects with a value (in terms of revenue or expenses) exceeding $500,000.

(17) The composition of the steering committee may be varied as required, but shall include:

1. Project Sponsor (who will normally chair the meetings);
2. client representation;
3. Project Manager (who will normally act as secretary to the meetings);
4. any other person appointed by the person who approves the business case.

(18) The role of the steering committee shall normally include:

1. reviewing progress of the project;
2. providing information, assistance and support to the staff involved;
3. monitoring compliance with the project budget.

(19) The steering committee shall meet on a regular basis and notes of the actions arising from the meeting shall be maintained and retained.

Section 7 - Project Administration

(20) A separate project account shall be established for all relevant projects for accounting purposes. External and internal costs shall be recorded against the project for the life of the project.

(21) Regular progress reports shall be prepared and submitted on the project. Progress reports shall be in writing. Progress reports shall be prepared at least once every two (2) months unless specific approval for a longer interval has been sought in the business case.

Section 8 - Document Management

(22) All aspects of the project shall be effectively documented in a single file that relates to the project.

(23) Documentation shall be of a high standard with a clear audit trail.

Section 9 - Implementation

(24) On completion of the project, a complete set of procedural documentation, in an accessible form, shall be made available to the relevant Dean or Director.

(25) All relevant staff shall be advised of the implementation of the project and of the changes involved and the impact for staff and students.

(26) Provision shall be made for appropriate training as part of the implementation of project outcomes.

Section 10 - Post Implementation Review

(27) At the completion of the project, a post implementation review shall be conducted. The post implementation review shall:

1. report on whether the project objectives have been met;
2. update the cost benefit analysis estimate.

(28) Such a post implementation review shall be conducted within 12 months of the completion of the project.

Section 11 - Roles and Responsibilities

(29) Not Available

Section 12 - Appendix 1: The Business Case

Overview

(30) Prior to commencing the detailed planning, development and implementation of a project, it is usual to complete a feasibility study or business case. The business case assists objective assessment of:

1. the reasons for undertaking the project;
2. the objectives and general scope/boundaries of the project;
3. the value of the proposed project to the organisation;
4. its relative merits in comparison with other existing or proposed projects;
5. comparison of the alternative approaches to completing the project;
6. the expected impacts of the project (including costs); and
7. the risks associated with the project.

Format of the Business Case

(31) The format of a business case will vary according to the nature of each project. Final formats may vary considerably, but would usually include the following items:

1. an overview setting out the reasons for the project and its scope/objectives;
2. a summarised set of the key options, including the advantages and disadvantages, and the costs of each;
3. a comparison of the options;
4. identification of the preferred option with a summary of the reasons;
5. impact statements where relevant; and
6. an executive summary of the content of the business case.

Key Issues to be Addressed in the Business Case

(32) Again, the issues addressed will vary according to the project being undertaken. The following issues are among those that would normally be addressed. 

The Project Reasons, Objectives and Scope

(33) The reasons for commencing a project should be identified. Flowing from these will be the project objectives and the scope.

Review of Options

(34) The key available options should be identified and valued. A summary assessment of each should also be identified, including the major advantages and disadvantages associated with their adoption. Options should address a full range of alternatives, including:

1. in-house completion of the project;
2. use of a mixture of external resources (including partnerships); and
3. outsourcing the project.

Impact Statements

(35) In the case of major projects, the use of impact statements for the key options should be considered. Impact statements should not be limited to the development and implementation processes, but should include ‘whole of life’ assessments. Impact statements may address, but are not limited to, the:

1. outcomes for the stakeholders and customers;
2. costs of the project in the development, implementation, and ongoing operation/management stages;
3. returns on the project in terms of income, productivity gains, competitive advantage and/or stakeholder and customer satisfaction;
4. legislative, environmental, and industrial issues that may be involved; and
5. marketing activities that may need to be addressed.

Prospective Partners

(36) The potential to attract business partners into the project should be considered. Effective use of interested private sector organisations could:

1. reduce costs and risks;
2. increase market impact;
3. introduce a broader range of operational skills to the project.

(37) Where a project involves other organisations, there must be a careful assessment of the merits and risks of such involvement and viability of prospective partners.

Comparison of Options and Recommendations

(38) The options that are presented should be compared, with a view to identify the most appropriate, and to provide a recommendation to the executive. The key items used to compare the options are those identified as important to the impact statements. 

Section 13 - Appendix 2:Discounted Cash Flow

(39) Discounted Cash Flow

Section 14 - Appendix 3: Project Plan

Project Plan

(40) The format of the plans will vary according to the size and nature of the project. In effect, the depth and size of a plan should be appropriately matched to the size of a project or its expected outcomes. Normally, a plan would include the following documents:

1. Executive Summary: Appropriate where the plan is to be approved, reviewed or monitored at an executive level.
2. Project Objectives: The plan should clearly state the project objectives so that there is no misunderstanding between the Project Manager, the team, and the key stakeholders.
3. Scope Statement: Where there may be limits on the scope of a project that may in turn impact upon expectations of the stakeholders, a clear statement of those limitations should be included in the planning document.
4. Tasks: The plan should contain a list of tasks that must be undertaken if the project is to be completed successfully. The normal process for identifying tasks is to apply a ‘top down’ assessment that identifies the primary outcomes and then ‘explodes’ those outcomes into tasks. The number of layers of ‘exploded tasks’ is discretionary, but planning should be limited to a level that ensures that the Project Manager can retain control of the project. In those cases where there are many tasks, the upper layers should be used to provide summary task lists for convenience of understanding.
5. Costings: The identified tasks should be costed for resourcing and additional goods/service purchase requirements. These costs should be supplemented with a list of additional costs that will be incurred as a result of completing the project. On-going service costs should be clearly and separately identified where they occur. Where costings are highly detailed, a summary sheet grouping the costings appropriately should also be provided.
6. Risk Analysis: A risk analysis should be completed to identify the risks that exist during implementation of the plan and after that process (where appropriate). A copy of the risk analysis should be incorporated in the plan.
7. Process Maps, etc: Where the project entails substantial redevelopment of processes, process-mapping documents should be included in the plan. This may not be possible in the initial stages, but should occur once those papers are available.
8. Project Plan: All plans should include a detailed project plan (such as a Microsoft Project Plan). This document is used to combine resource, timings and tasks into a working plan that is then used to drive and monitor the project.
9. Other: There is substantial benefit in including, where appropriate, other documents that clarify the planned tasks and the outcomes.

Key Tasks to be Addressed in Project Plans

(41) Depending on the nature of the project, there may be a number of tasks that need to be planned for. Those listed below would normally be catered for in an effective project plan.

1. Project Management: This is a mandatory requirement that involves determining resources, timings, coordination, and review tasks that will need to be addressed by the Project Manager.
2. Process Review and Mapping: A varying requirement depending upon the nature of the project, and entailing review of the existing process, function, etc, that is to be modified by the project, and mapping out the changes. Techniques could include process re-engineering, process mapping for changed and new processes, functional responsibility mapping, value analysis, statistical review and process documentation for user reference or training purposes.
3. Marketing: A mandatory requirement, which involves firstly identifying the key stakeholders and markets upon which the project may impact, and then planning steps to consult, involve and sell the project outcomes as appropriate. In its most complex form, this process may require the development of impact statements (i.e., staff, environment, etc.) and the planning of advertising and sales campaigns.
4. Risk Analysis: A mandatory requirement to assess all of the risks associated with a particular project and to set in place strategies and processes to address those risks. The risk analysis process should be completed to a level that is appropriate to the overall risk posed by the project.
5. IT Acquisition/Modification: This is a requirement when there will be changes to IT services as a result of the project’s completion. The specific areas to be covered include:
   1. Host Hardware - an assessment of the sizings and load requirements to be placed on host hardware resources, and subsequent planning for the replacement, upgrade or removal of host hardware;
   2. Client Hardware - as for host;
   3. Software - an assessment of the software needs resulting from the project and planning for the acquisition, alteration or removal of software applications;
   4. Network - assessment of network implications and planning to address revised needs; and
   5. Documentation - documentation of revised IT processes for maintenance, user and training purposes.
6. Consultancies: A requirement if external consultants are to be used as part of the project. Particular consideration should be given to the need for appropriately qualified legal and accounting advice, and to the costings surrounding the use of consultants.
7. Training: A requirement where processes will change as an outcome of the project. The training aspects of the plan should dovetail into the marketing plan where possible.
8. On-going Services: Where the outcomes of the project include an ongoing service requirement, planning should cater for the establishment, operation and continued costing of this service.
9. Contingencies: A mandatory requirement for all projects in which there is the possibility of “blowouts”. Appropriate margins addressing the possible need for physical resource and cost increases should be built into the plan.