Business Case Development Guidelines and Template for ICT-Enabled Projects

Chief Minister, Treasury and Economic Development Directorate

December 2015

Quality Management SystemCorporate Management

ContentsPurpose..........................................................................................................3Scope.............................................................................................................3Context...........................................................................................................3Introduction....................................................................................................3What is a business case?................................................................................4Guidelines for developing a business case.....................................................4

Structure of the business case................................................................................4Presentation of the business case...........................................................................5Completing the template........................................................................................6Business case sign-off.............................................................................................7Document control...................................................................................................8Table of contents....................................................................................................81. Executive summary...........................................................................................92. Project Overview...............................................................................................9

2.1 Objective.................................................................................................92.2 Target outcomes.....................................................................................92.3 Business need.........................................................................................92.4 Impact of not proceeding........................................................................92.5 Scope....................................................................................................112.6 Description............................................................................................112.7 Conformity with policy and strategy......................................................122.8 Implementation strategy.......................................................................122.9 Deliverables..........................................................................................122.10 Project governance...............................................................................132.11 Project timing........................................................................................13

3. Summary of Costs and Resources...................................................................133.1 Costs.....................................................................................................133.2 Resources..............................................................................................14

4. Funding strategy.............................................................................................144.1 Investment or funding sought...............................................................144.2 Source of funds.....................................................................................15

5. Risk assessment..............................................................................................156. Impact and change management...................................................................15

6.1 Impact statement..................................................................................156.2 Change management............................................................................16

7. Control issues..................................................................................................168. Benefit realisation...........................................................................................169. Consultation....................................................................................................1610. Linkages and dependencies............................................................................1711. Comparison of options....................................................................................17

11.1 Description of options...........................................................................1811.2 CBA.......................................................................................................1811.3 Risk assessment comparison................................................................1811.4 Recommended option...........................................................................18

12. Feasibility studies............................................................................................1812.1 Two-phased approach...........................................................................1912.2 The feasibility study..............................................................................19

13. Attachments to the business case...................................................................19A. Financial impact............................................................................................19B. System specification.....................................................................................19C. Project schedule............................................................................................19D. Risk management tables..............................................................................19E. Cost-benefit schedules..................................................................................20F. References to other project documentation..................................................20

Page 1 of 50

G. Glossary........................................................................................................20Appendix A: Funding Strategies...................................................................21

Joint ventures........................................................................................................21Budget allocation..................................................................................................21Repayment schedule.............................................................................................21

Appendix B: Risk Management.....................................................................22Appendix C: Cost Benefit Analysis................................................................23

Economic.............................................................................................................24Social Analysis.......................................................................................................26Environmental Analysis............................................................................................26

Economic Analysis Guidelines (further technical advice on undertaking a CBA)..................27Appendix D: Realisation of Benefits.............................................................33Appendix E: Consultation and Collaboration................................................35Appendix F: Checklists.................................................................................37

Cost components..................................................................................................37Benefit Components..............................................................................................38Risk Items.............................................................................................................38

Appendix G: Forms.......................................................................................40Cost - Benefit Analysis...........................................................................................41Risk Register.........................................................................................................42Risk Identification Log...........................................................................................43Benefit Realisation Register..................................................................................44Document Control.................................................................................................46

Appendix H: Contacts...................................................................................47Appendix I: Business Case Template for ICT-enabled Business Projects......48

Page 2 of 55

PurposeThis document and its associated template provide assistance in the preparation of a business case that complies with the Management of Projects with an IT Component Policy (Project Management Policy) which can be found at http://sharedservices/actgovt/ICTpolicies.htm. This requires that all projects must have a business case of appropriate detail relative to the expected size, scope, complexity, risk and cost of the project.

ScopeThese guidelines and the associated template should be followed whenever a business case is completed for an ICT-enabled business project including: as required under sections 4.2 and 5.2 of the Management of Projects with a

Significant ICT Component Policy and/or where required by funders and decision makers, for example Chief Minister, Treasury

and Economic Development Directorate may stipulate the use of the format for initiatives seeking budget funding and/or

where required by an ICT policy, to implement non-standard ICT Services.

These guidelines complement the Capital Framework guidance material and the steps outlined in that Framework extend to ICT Capital Works with this guidance however being specific for business cases for ICT enabled capital investments.

ContextWhile the preparation of a Business Case will have considerable benefit in the initial stages of any project – specifically in identifying costs, benefits and risks – it can be a significant and costly exercise in itself. Therefore it is often best to begin with preparation and approval of a short concept brief, which will allow decision makers to determine if there seems to be enough merit to expend resources on a Business Case. Also, these Business Case Guidelines and Template have a special significance in the ACT Budget process.

The Central Costing and Strategic Analysis Unit in Shared Services ICT can assist from the very early stages of concept definition right through the business case process. All ICT costing must be reviewed by the Central Costing Unit (CCU) whether it is for internally supplied services or externally supplied (vendor) services. This assurance is to ensure that the approach to whole of life investment mapping remains consistent throughout the lifecycle of an initiative and is considered in the context of whole of government ICT investments (whether through the budget process or other means of funding).

For more information about the Budget process, contact Finance and Budget Division of the Chief Minister, Treasury and Economic Development Directorate. For more information on the CCU email ssictccu@act.gov.au.

Introduction These Guidelines aim to aid development of a Business Case that addresses whole of life costs and risks and that considers the wider context of a proposed ICT investment, including whether other areas of the ACT Government may have or need similar ICT investments or whether current capability can be reused. The business case should enable those assessing it to understand the investment logic for the project, to consider its value, to analyse its chances of success and to assess it against other projects or options competing for limited funding. The business case may be required either for a project proposal seeking funding or for an on-going project that requires a decision about its continuing value.

Page 3 of 55

Before initiating a project with an external ICT service provider, and before initiating any procurement activity, agencies should ensure that the project has an approved budget and has a clear and complete specification of benefits to be realised, benefit measures, and high level business outcomes. Agencies should seek advice from the CCU in SSICT to ensure that the initial investment strategy for an initiative is developed in a valid and viable way.

This business case template sets out the information required for a major project needing capital funding through the Budget process. If a project is to be funded through an agency’s recurrent operating budget, then the business case format and approach may differ from this template at the discretion of the relevant Funding Approver and Project Sponsor.

What is a business case?A business case is an evolving document that defines a proposed or ongoing project, providing sufficient information for readers to understand the scope and rationale of the project, to analyse its chances of success and to later measure whether or not the implementation project(s) have achieved stated objectives. A well written, properly used, business case provides the information against which key decisions for the project can be based, such as whether or not to: commit funding to, or maintain funding for, the project; commence projects; adopt a particular direction with the project; continue or change the current direction of the implementation projects following

changed circumstances or the realisation that previous assumptions were incorrect, exceptions were encountered or unfunded risks were realised;

cease the project(s); and/or assess the project as successfully completed.

Guidelines for developing a business caseStructure of the business caseUse the Business Case Template as a framework for drafting the business case. These guidelines follow the template numbering structure for ease of reference. The template structure shown below indicates those sections that are mandatory for all business cases.

Page 4 of 55

Section of Business Case Mandatory?

Cover Sheet YesBusiness Case Approval YesDocument Control NoTable of Contents No1. Executive Summary No2. Project Overview Yes

2.1.Objective Yes2.2.Target Outcomes Yes2.3.Business Need Yes 2.4.Impact of not proceeding Yes2.5.Scope No2.6.Description Yes2.7.Conformity with Policy and Strategy No2.8.Implementation Strategy No2.9.Deliverables Yes2.10. Project Governance Yes2.11. Project Timing Yes

3. Summary of Costs and Resources Yes3.1.Costs Yes3.2.Resources Yes

4. Funding Strategy Yes4.1.Investment or Funding Sought Yes4.2.Source of Funds No

5. Risk Assessment Yes6. Impact and Change Management No7. Control Issues No8. Benefit Realisation No9. Consultation Yes10.Linkages and dependencies Yes

10.1. Relevance to other directorates & existing systems in ACT Government

10.2. Linkages and dependencies with other programs or projects

11.Comparison of options Yes11.1. Description of options Yes11.2. Cost-benefit analysis Yes11.3. Risk assessment comparison Yes11.4. Recommended option Yes

12.Feasibility studies No13.Attachments NoA. Financial impact YesB. System specification NoC. Project schedule NoD. Risk management tables NoE. Cost-benefit schedules NoF. References to other project documentation NoG. Glossary No

Presentation of the business caseThe business case should be easy to read and understand. Specifically: use the recommended template and complete it in a concise and logical manner. provide a level of detail commensurate with the size, scope and sensitivity of the pro-

ject. avoid duplicating discussion under different headings.

Page 5 of 55

use appropriate graphs or charts to convey complex information such as a project schedule or comparative Cost Benefit Analysis (CBA).

if using an executive summary, briefly outline the key requirements, findings and re-commendations. Do not include extensive arguments in the summary.

ensure that a thoughtful approach has been taken to the identification and analysis of alternative options. Consider options that explore more cost-effective approaches to delivery of outcomes.

In general, provide assurance that the business case has been developed with an appropriate degree of rigour, objectivity and consultation.

Completing the templateComplete all sections

Note: Do not re-order or delete any sections of the template.

It can be tempting for writers to change the template to account for personal style preferences or to make it easier to complete on a case by case basis.

However a consistent structure makes it easier for decision-makers to find key information in your business case. It is especially helpful for executives who are trying to compare or choose between different proposals competing for the same resources if they can turn to the same numbered sections and compare like-with-like information. So do not disadvantage your project by making this difficult for them. If you have no data to enter for a particular section either explain why in no more than a sentence or simply type – Not Applicable.

Tracking Sheet

The cover sheet provides key information to enable quick identification of the business case and to assist in workflow. A cover sheet is mandatory and should not exceed one page in length.

Name of Proposal: Provide a short title or subject of the proposal.

Submitted to: Indicate who the business case is being submitted to.

e.g. Cabinet, Agency IM/ICT Committee, Project Steering Committee.

Date of Submission: Show the date the proposal is submitted for funding / approval.

Purpose of Submission: Specify whether the submission is for funding or for approval to proceed.

Owner: Provide the name, title, business unit and contact details of the owner.

The owner is accountable for the project’s outcomes. They will take delivery of the project’s products, be accountable for the ongoing care and maintenance of those products and for ensuring that they are used to deliver the project’s benefits. For example if the products of the project include a new ICT business system, the owner is the person that will take delivery of the system. The owner will also be the Senior Responsible Office (SRO) on the project board if they are not the Sponsor. As such they are the promoter of the business case and therefore drive its preparation. This will normally be an Executive or Senior Manager and in the case of a multi-agency proposal it will normally be an Executive from the lead agency.

Page 6 of 55

Note: No business case, no matter how promising, should ever be put forward without an owner.

Sponsor

In many cases, but not always, the owner and sponsor will be the same person. The sponsor is a person who wants the project to succeed, and is either in a position to be able to fund it or is in a position with enough influence to have a reasonable chance of success in obtaining funding. This may change on a case by case basis, depending on chain of command protocols within the agency, the proposed funding source, and who the funder will accept submissions from. For example in the current ACT Budget process, only Agency Director-General’s can submit a budget proposal and therefore the Director-General would become the sponsor of a business case to support a budget proposal even if they are not the owner.

The Project Sponsor is accountable for the governance of projects arising from an initiative. It is the responsibility of the Project Sponsor to ensure a Project/Initiative Board is convened for the continued governance of the initiative until outcomes have been achieved or abandoned. The Project Sponsor is also accountable for any assurance activities that the project/initiative undertake.

Business Case ContactProvide the name, title, business unit and contact details of the person preparing the Business Case. This person will act as an agent of the Sponsor to handle correspondence, questions, amendments and responses.

Business case sign-offThe business case sign-off page provides evidence that those that need to see the business case have seen it and that they support the business case. In particular:

Proposed Owner: The owner signs the document because they are accountable for the achievement of the outcomes promised in the business case. By signing the business case, the Owner is providing an assurance that:

the proposal meets a valid business need for a business unit of the agency, is aligned to the strategic direction of the agency and whole of government and will deliver measurable outcomes that are a priority for the agency or whole of government.

the business case is sound, is based on a thorough approach to investment logic, cost benefit analysis of competing options and has a rigorous risk assessment as well as cogent and measurable benefits.

value for money options have been sufficiently explored for suitability. potential cross over and value for other directorates and agencies has been

considered. the business case indicates how the investment builds on, or relates to, existing

investments or current capability across government. the Owner’s agency has the capacity to govern and manage the project and deliver

its promised benefits within the scope, costs and timeframes outlined in the business case inclusive of contingency funding commensurate with the risk profile of the initiative.

if the project proceeds, the Owner will take delivery of the project products (e.g. ICT business systems) and be responsible for upkeep, recurrent and ongoing funding through whole of life, and be accountable for realising the benefits promised in the business case.

The Director, Business Development in Shared Services ICT, or Executive Director, SS ICT signs the document because they need to know about proposed ICT developments across

Page 7 of 55

the Government (noting the Statement of Responsibilities for ICT Services mandates involvement of Shared Services ICT in business cases for ICT-enabled projects). By signing, they are attesting that they were consulted through the CCU and believe any ICT-enabled approach proposed for adoption appears to be sensible; and that at the whole of government level, the project is aligned to ICT strategy, represents a best value approach and that Shared Services ICT has capacity to undertake its role in the project.

Agency Chief Finance Officer: The CFO signs the document as they need to know about proposed financial commitments of the agency. In signing, they are attesting that they were consulted and that, subject to the accuracy of the financial assumptions in the business case, and subject to funding being provided as proposed in the business case, the agency will be in a financial position to proceed with the project and fund the whole of life maintenance of any products delivered by the project.

Agency IM/ICT Executive or Committee: The Agency IM/ICT Executive or IM/ICT Committee signs off on the document because they are responsible for the IM/ICT direction in the agency. In signing the document they are stating:

their belief that the proposal is sound, meets a valid business need of the agency, is aligned with other initiatives and opportunities in the agency and is a priority worthy of consideration by the sponsor.

their confidence that the agency has capacity to govern, manage and deliver an additional ICT-enabled project together with its existing projects.

Sponsor: The sponsor signs the document because they are the person who is authorised to seek funds for the project and therefore they are accountable to the funder for the soundness and accuracy of the business case. In signing the business case they are attesting to all of the above and that they believe that the proposal outlined in the business case is a priority worthy of consideration by the funder.

Note: A mistake that occasionally occurs is to commence a project on the basis of a Sponsor’s signature on a business case. This is a high-risk course of action as the Sponsor’s signature does not mean that the project is funded or ap-proved, it merely means that the Sponsor supports the business case and that it can be submitted to the funder.

Document controlIncorporate a document control section for business cases that are likely to go through several drafts and be circulated to a range of stakeholders prior to finalisation. A document control sheet identifies the version number, its current status and amendment history. It helps keep track of versions and ensures the correct one is in use.

Table of contentsIncorporate a table of contents in larger documents (10 pages or more) for improved readability.

1. Executive summaryAn executive summary should be used in larger documents (10 pages or more). It is advisable to complete the body of the business case before the executive summary.

Some principles that should be applied in drafting an executive summary are as follows:

report the key issues and findings without going into detailed analysis provide a concise argument for the overall recommendation use bullet points, short tables or simple charts to illustrate key points

Page 8 of 55

ensure the summary can stand alone, without reference to the rest of the document. Use cross-references to the body of the business case only to allow the reader the op-tion of “drilling down” to find the underlying detail. Keep these references to a min-imum

avoid using jargon

2. Project Overview2.1 ObjectiveThis is a one-line statement that captures what the project is about.

2.2 Target outcomesState the business outcomes that the project is attempting to achieve. Avoid confusing outputs (such as acquiring a particular technology) with outcomes (achieving benefits for the business or for constituents). Examples of outcomes are:

to improve client service by… to improve revenue collection by… to reduce operating costs by…Show how these business outcomes relate to agency or ACT Government business object-ives, plans or strategies. Show the relationship to relevant ICT strategic plans and WhOG Roadmaps.

2.3 Business needDescribe the current problem, deficiency or opportunity that this project will address. Show how this is significant in the agency’s business plans, strategy or obligations. This section should be kept brief, but will provide a necessary background to the project ob-jective.

2.4 Impact of not proceedingBriefly outline the impact of not proceeding with the project, or deferring it. Aspects to consider include: business operations and business plans government policy or political implications financial implications service delivery in particular please indicate if there is likely to be any community ef-

fect from not proceeding with the investment at this time (e.g. risk of existing system failure preventing someone in the community doing what is required).

ICT implications.

Page 9 of 55

2.5 ScopeWhat is a scope section?

A scope section defines and communicates the boundaries of a project. It states explicitly what functions, processes, organisational units and deliverables are included and what are excluded.

What should be included in a scope section?

The scope section should summarise the core components, business functions and participants in the project, and should pay particular attention to any potential for uncertainty around the edges. It should deal with the questions “What is in, and what is out?” Make sure there is a sub-section dealing with what is out of scope, as this can be just as instructive as noting the in-scope items.

Consideration should be given to a separate scope section where

the project is medium to large in size, or is wide ranging the project crosses agency boundaries there is some reason to anticipate uncertainty of disagreement over scope, for ex-

ample where there are other, related initiatives.A separate scope section is not required for small projects, provided scope is covered adequately under 2.6 Description.

2.6 DescriptionProvide a high level description of the project including new or changed:

business processes. business rules. products and services delivered by the organisation. organisational structures. systems and infrastructure.

In respect of the ICT Services provide a high level description of:

the scope and main functions, including system inputs, governance and outputs; user access — who will use the service and what communication or access channels

will be made available; whether the project is self-contained or is part of a larger initiative. For example

there may be several phases or related projects necessary for the long-term success of the initiative;

an outline of the technology requirements, including ICT infrastructure, development technology and use of existing systems or data stores. In particular note any new or non-standard ICT requirements;

the approach to project implementation, e.g. managed service, internal hosting, use of COTS software, tendered development and systems integration, partnering with other agencies, multiple vendors and cloud tenancies;

how the initiative will be governed across multiple suppliers. how the initiative contextually relates to the ICT Roadmap for Whole of Government; how change management and business process redesign will be managed;

Page 10 of 55

RACI matrix; Licensing and contract management responsibilities; how the cost of the service funding ongoing is modelled for a cost recovery service –

subscription, shared hosting amongst directorates, amortised recovery on uptake etc; and

any significant assumptions or constraints.

2.7 Conformity with policy and strategyIdentify relevant ACT Government policies and strategies and demonstrate how the pro-posed project conforms or does not conform with them. Note any ACT or national stand-ards that may be applicable and the extent of conformance with those standards, e.g. enterprise architecture. Note any costs of divergence (which should also be listed in the summary of costs and CBA). This includes alignment with Whole of Government ICT Strategy and Records Management policies and legislation.

2.8 Implementation strategyInclude this section where there is a significant procurement process or partnership ar-rangement. Otherwise the implementation strategy can be briefly described under 2.6 Description.

.Describe any significant procurement arrangements and demonstrate how they conform with procurement policy.

Document any major partnership or alliance with another agency, community group or commercial operation. Describe the nature of the relationship, how it is to be formalised and managed, the contributions made by each partner and the benefits received by each. Summarise the approach to critical roles such as contract management, project manage-ment, quality and configuration management and systems integration. Explain how the governance will work across multiple suppliers and jurisdictions.

2.9 DeliverablesList all project deliverables to the extent that this is known. These differ from the target outcomes of the project. The deliverables are the outputs or products of the project. They are the things that the project owner will take delivery of and use in order to realise the target outcomes that the project is intended to achieve. The better the deliverables are defined, the better the project can be costed and scoped and vice versa.At the business case stage each deliverable should be described in one or two lines. Time frames must be noted against each deliverable. Examples:

“Replacement of the current legacy system with a web-enabled application, incorpor-ating dedicated links to … by 1 December 20XX”

“New business processes associated with <an agency function>… by 1 June 20XX” “Implementation of Software as a Service (SAAS) to deliver key functions to Govern-

ment by 1 November 20XX” “New services comprising … by 12 December 20XX”

2.10 Project governanceDescribe how the project will be governed. A schematic diagram is useful for this purpose.

Page 11 of 55

Note: The Project Management Policy specifies minimum requirements for Project Gov-ernance and that Shared Services ICT has published Project Governance Guidelines, which provide further assistance including a suggested project governance structure. These documents are available at http://sharedservices/actgovt/ICTpolicies.htm.

2.11 Project timingProject timing should be addressed in two respects:

Project schedule. Show the indicative start and end dates of the project, and any significant milestones. For larger projects include a GANTT chart as an attachment, showing the project phases, key activities and milestones. Allow time for Change Management and other whole of government approvals and include contingency for changes in scope or troubleshooting in the schedule.

Expected system life. Indicate the expected life span for the service and enabling business systems. This information may then be used to update the Configuration Management Data Base to assist in whole of government financial and lifecycle man-agement of our ICT capability.

3. Summary of Costs and Resources3.1 CostsProvide a summary of all project costs for the recommended project outputs. Ensure that whole-of-life costs and business-related costs (such as change management) are addressed. For larger projects and large or unusual cost items provide supporting notes. All significant direct or indirect costs should be identified.

Consider, as a minimum, costs under the following headings of acquisition and construction:

Planning, evaluation and project management, Engineering and development, Environments, hosting infrastructure, platform applications, Testing and piloting, Rollout and tuning, Warranty and transition to service, Project closure, Documentation, Implementation user support, Consultants, External Services, Data transformation, data conciliation and migration costs, Security and privacy threat assessments, Configuration management costs, Compliance, governance and risk management, and Licensing, contracts and procurementA useful checklist of cost items can be found at Appendix F.Note: CCU also have costing tools for Return on Investment and Effort Ratio Calculator for ICT projects that will assist in the development of your business case .

Page 12 of 55

Indicate how value for money options have been considered and whether some costs for the proposed investment could be avoided or minimised.

A financial impact statement must also be completed in consultation with the Chief Finance Officer of your Agency. The financial impact statement will also be used if the Director-General agrees that the project should progress to the budget initiative process. The template can be found at http://incmtd/ACTPS_CFO/SitePages/Budget%20Officers.aspx

3.2 ResourcesState which resources will be deployed in project execution. For example, this may include:

skills required for the project including training staff from the agency administering the project communication staff resources staff or other resources from agencies co-operating in the project the development team from a successful tenderer consider staffing and resource options including outsourcing governance resources Shared Services ICT resources.

For larger projects with a complex organisational structure (e.g. multi-agency) it is advisable that all major roles in the project should be identified through a RACI Matrix (responsibility, accountability, consultation, information) and provisionally assigned. If the resource for a key role has not been assigned, state the strategy for acquiring a resource for that role.If using external resources during project implementation, indicate how necessary skills and knowledge transfer or guaranteed on-going access to support and maintenance would be achieved throughout the life of the investment.

4. Funding strategyRefer to Appendix A for an outline of potential Funding Strategies.

4.1 Investment or funding soughtBriefly state the amount of funding sought (if any), whether it is sought as an allocation or a capital advance, and any special arrangements that might apply.For capital advances, detail the repayment schedule, year by year.For projects that require a funding allocation over more than one budget cycle include a schedule of the expected funding requirements for out years. Separately identify Capital and recurrent funding.

4.2 Source of fundsWhere a number of different funding sources are proposed list these in a funding schedule.For joint ventures, specify the contribution to be made by each partner and whether it is to be made to a project budget or as a direct payment of project costs. Include any “in-kind” contributions to the project made by project partners.

Page 13 of 55

5. Risk assessmentIt is important to demonstrate in the business case that a rigorous risk assessment process has been followed and that all identified risks have been taken into account in forming the proposal. While a general risk assessment should be carried out for each option considered under Comparison of Options, the recommended option should receive a more detailed risk assessment here.Two key areas of risk that should be assessed are data migration and integration with existing systems. This includes any Cloud implementations that need, for example, security credentials passed from ACTGOV or information and reports being fed back into ACTGOV. There may also be opportunities associated with the investment for which it is recommended you identify associated risks that those opportunities are not pursued and exploited. All Assumptions and the Risk loading of the project should be costed at a high level and appropriate contingency funding made available in the funding request.Refer to Appendix B for a more detailed discussion of risk management and how to undertake a risk assessment for the business case.Document those items with a significant risk rating, based on the probability of occurring and potential impact. These risks will require explicit risk treatment, which should be summarised here. Use the risk management template provided at Appendix B.Risks can apply to both small and large projects. The extent of detail in this section, however, will vary considerably according to the amount of risk in the project. Riskier projects will require extensive analysis and documentation of risk. In these cases the detailed risk identification and treatment tables should be included as an Attachment to the business case and only a summary of the main risk items and the overall risk management strategy should appear in the body of the business case.

6. Impact and change managementAn impact is some expected significant effect of the project or system that is not readily shown as a cost, benefit or risk, for example the need for job redesign or business process re-engineering.

Significant impact, even if not perceived as negative, usually requires some form of change management strategy. Where there is a negative impact, there will be a need for some form of counter measure or management strategy.

6.1 Impact statementIdentify any areas of significant impact, including potentially negative or neutral ones. Areas of impact that might be considered are:

clients and service delivery staff suppliers business rules and processes organisational structure environment technology and infrastructure.

6.2 Change managementSummarise the change management strategy if there is likely to be extensive organisational change or impact on staff, clients, suppliers or business practices. Change

Page 14 of 55

management may include such measures as communication and consultation, training, identification of change agents, marketing, revised legislation, policy and guidelines etc.

7. Control issuesThe project may have particular or unusual control issues that may impact on the form of the proposal. You should consider and detail the major issues under these headings:

Security Privacy Confidentiality Intellectual Property (IP) Disaster Contingencies Other.

8. Benefits realisationAll projects should define the benefits they are expecting as part of the investment logic and description of the return on investment. The benefits should have associated measures and dates for those measures as well as a project implementation review date to assess progress against the benefits. This is the responsibility of the Project Sponsor. Part of the CCU assessment process is to examine the benefits and investment logic of proposals for ICT enabled business initiatives.

Ensure that responsibility is allocated for the realisation of all major benefits. Use a Benefit Realisation Register where there is wide range of benefits.

Refer to Appendix D for further discussion of Benefit Realisation.

9. ConsultationEffective consultation is a key activity in developing a robust business case and delivering better value for money across the ACT Government. Consequently the business case will be closely scrutinised for evidence of effective consultation.

Indicate the extent of consultation that has taken place. This should cover the following categories:

There needs to be consideration of other initiatives or opportunities for a shared approach. These may provide advantages in terms of cost saving, faster de-velopment, shared investment, optimised service delivery and so on. They may be planned, current or completed projects elsewhere within the agency or the ACT Gov-ernment, or they may simply be a business need that has not yet been acted upon.

Show that there has been consideration of relevant agency and ACT Government policy, and that the proposal supports or is consistent with that policy. This will be in addition to any direct rationale for undertaking the project, covered under the “Ob-jective”.

State what consultation has been undertaken with the appropriate assurance agen-cies in Shared Services ICT and what consideration has been given to current capabil-ity across government, and the extent to which the proposal conforms with applicable standards. Any proposed divergence from the enterprise architecture should be dis-cussed with the appropriate assurance agencies in Shared Services ICT to identify risks and increased costs, and these documented in the business case.

Page 15 of 55

At a minimum, specify who was consulted, what their interest or relevance is, what form the consultation took and the outcome of the consultation.

See Appendix E for further discussion of Consultation and Collaboration.

10. Linkages and dependenciesThe business case should indicate whether options have been explored that leverage from existing software and services available either online, from other parts of government or other jurisdictions. It should indicate whether the investment is relevant to other directorates or existing systems in ACT Government, since co-ordinated re-use or extension of existing investments and enabling wider access to common systems across Government can maximise value from limited investment funds and resources.

Indicate in this section whether and how the project builds on, or relates to, existing investments and whether it provides a potential building block for shared foundation ICT capability across ACT Government.

Sometimes the success of one project is dependent on the completion of another project or there are synergies between initiatives, so these possible linkages and dependencies should be addressed.

Where such relationships exist, decision makers must know about their implications.In most cases this can be achieved with a simple list or table setting out the linkages or dependencies, explaining their implications, and describing how they will be managed.

11. Comparison of optionsThis section examines each of the options considered, taking into account the CBA and risk assessments, and provides the reasoning for selecting the recommended option.

If an options paper was completed prior to the business case, this can be annexed to the business case. In that case it will only be necessary in the business case, to cover any matters that were not covered in the options paper.

Whether the comparison of options is contained in the body of the business case or annexed in an options paper, it should include at least the recommended option and a “base case”, which is the minimum necessary to meet the business need or solve the problem. In many cases a “do nothing” option may be one of the options compared, for instance where an opportunity to enhance a service is not taken up. In circumstances where the “do nothing” approach is not a legitimate option, for instance when responding to a legislative change, this should be fully explained under heading 1.4 “impact of not proceeding”.

The identification of alternative options is an important activity in developing a business case. It provides an opportunity to consider innovative approaches, which may be more cost-effective or less risky than the approach that first suggests itself. The Comparison of Options section should identify the range of options considered. If some were ruled out before the comparative assessment, note briefly the reason for their elimination.

11.1 Description of optionsProvide a brief description of each significant option. Highlight the key areas of distinc-tion between the options.

Page 16 of 55

11.2 CBAFor all projects over $10 million a comparative summary of the CBA conducted against each of the identified options should be provided. Ensure that significant non-financial costs and benefits are included in the analysis. Depending on the level of analysis the cost-benefit details for each option may be included here, or alternatively they may be provided in a cost-benefit schedule in one of the attachments to the business case.

A more extensive discussion of how to approach CBA is provided in Appendix C.

11.3 Risk assessment comparisonProvide a short comparative assessment of the risks associated with each option. Docu-ment significant risks to cost, timeframe and scope only. Ref to:

Appendix B for further discussion on risk assessment; and the http://www.cwd.act.gov.au/act-insurance-authority/risk-management for further

advice on Risk Assessment/Management.

11.4 Recommended optionState the recommended option and provide reasons. Refer, as necessary, to the findings of the CBA and risk assessment.

12. Feasibility studiesLarger, more complex or politically sensitive projects need a two-stage approach. Small to medium sized projects can usually be researched, assessed and approved on the basis of a single business case. However, very large projects often require special treatment. They typically have several or all of the following characteristics:

developed as a whole-of-government or multi-agency project extensive business process re-engineering, often across several agencies, and a cor-

responding requirement for change management developed over two or more budget cycles high level of investment broad scope and high complexity of chosen approach innovative use of technology, and use of emerging technologies potential for high public visibility and political sensitivity.

Naturally, these characteristics mean that the project has significant levels of risk from the outset. In these circumstances a two-phased approach should be adopted.

12.1 Two-phased approachA two-phased approach addresses the inherent risks in large projects by progressively committing resources as greater knowledge and confidence in the approach are developed. This approach can save considerable cost and effort, and can help in establishing the strategic direction.

The first phase, the feasibility study, aims to develop a comprehensive view of the proposed approach, establish more exact costs and plans, and ascertain that the approach is commercially and technically feasible. The second phase is the full project.

Page 17 of 55

The business case for the full project will be drawn from the detailed information provided by the feasibility study.

12.2 The feasibility studyThe feasibility study must be separately approved and funded as a recurrent activity, so it requires a business case of its own. This business case need not be lengthy but it does have some unique requirements. Its deliverables are not ICT systems but a set of specifications and plans. Nonetheless, it must maintain a perspective of the entire project, in terms of both the intended business outcomes and the multi-stage project planning.

13. Attachments to the business caseA. Financial impactUse the template at http://incmtd/ACTPS_CFO/SitePages/Budget%20Officers.aspx to provide details of the Financial Impact for the Agency/Territory. You should ensure that recurrent expenses, capital injections, and depreciation have all been accurately reflected. Your Chief Finance Officer should be able to assist in this process or provide a copy of the template and guidance relating to what is appropriate to capitalise or expense for the project.

B. System specificationIf a system specification has been developed it can be included here. This will not normally be necessary for small proposals, and is not applicable if the business case is to conduct a feasibility study.

C. Project scheduleInclude a high level project schedule, preferably in diagrammatic form such as a Gantt chart. Ensure that the schedule can be readily understood — if it is particularly complex provide explanatory text.

D. Risk management tablesProvide the risk identification and risk register tables here (refer to Appendix G). For smaller projects it may be practical to combine them into one table. List items in the risk register table in descending order of risk exposure.

E. Cost-benefit schedulesProvide the cost-benefit schedules for each option considered.

F. References to other project documentationIdentify relevant project documentation or background information that was used or developed in the creation of the business case. This documentation should be available for examination on request.

G. GlossaryList all acronyms, special terminology (such as ICT or specific business terms) and abbreviations, along with a short definition.

Page 18 of 55

Note: Knowing what an acronym stands for does not always help. An explanation of the term is often required.

Page 19 of 55

Appendix A: Funding StrategiesA project may be funded from one or more of the following sources: self-funding, i.e. savings generated by the project pay for the project agency resources such as cash reserves or existing revenue streams external sources such as joint ventures and commonwealth payments budget allocation by the ACT Government capital advance from the ACT Government, subject to a repayment schedule.

Generally, all projects should aim to minimise any need for additional capital investment from Government, and maximise the use of existing revenue streams.

Joint venturesJoint ventures with other ACT Government agencies offer opportunities to streamline client services, rationalise resources and provide economies of scale. Funding strategies with other agencies may be based on sharing direct costs on an agreed basis, but may also comprise some “in kind” contributions such as use of existing resources or facilities. The business case should show the full extent of such arrangements and should identify the full costs, including the overheads of the joint venture.

Joint ventures may also be undertaken with an agency in another arm of government (i.e. Federal, State or local) or with private enterprise.

Budget allocationWhere agencies are unable to fund an ICT-enabled project from within existing resources, business case development should be timed to allow Government to consider the project during the budget development cycle.

Repayment scheduleIn certain circumstances, a project may require a capital advance. The business case should show:

that the agency has the capacity to repay an advance. This capacity may be identi-fied in the project’s financial benefits. Where the financial benefits from a project are not sufficient to meet the proposed repayment schedule, agencies must clearly identify capacity within their established revenue streams.

a proposed repayment schedule, including details of the repayment arrangements and any potential risks.

Page 20 of 55

Appendix B: Risk ManagementThe ACT Insurance Authority has been tasked under the Insurance Authority Act 2005 with promoting good risk management practices and giving advice to the Minister about the management of Territory risks. See the following link for details: http://www.cwd.act.gov.au/act-insurance-authority/risk-management

Risk is any factor that could adversely affect the project, or the costs and benefits associated with it. It is assessed in terms of likelihood and potential impact. Risk management is a systematic approach to identifying, analysing, assessing, treating and monitoring risk.

The business case is concerned with the identification, analysis and assessment of risk, and proposing a risk treatment regime. The ongoing monitoring and treatment of risk is a function of project management. New risks may also be identified during project execution.

It is important to demonstrate in the business case that a rigorous risk assessment process has been followed and that all identified risks have been taken into account in forming the proposal. While a general risk assessment should be carried out for each option considered, the recommended option should receive the most detailed risk assessment.

The process adopted by the ACT Government for risk management accords with the AS/NZS ISO 31000:2009 Risk management - Principles and guidelines, available from the Government and Assembly Library.

Page 21 of 55

Appendix C: Cost Benefit AnalysisA cost-benefit analysis is an assessment tool used to determine whether an option is beneficial relative to the base case. The key principle of cost-benefit analyses is to convert the costs and benefits into dollar terms, allowing them to be weighed up against each other. An option will be considered more desirable if it delivers benefits over and above its costs, which is typically expressed in net present value (“NPV”) terms.

The cost-benefit analysis differs from traditional financial analysis in that it is performed from the viewpoint of society; specifically the community of the ACT. For example, it considers the road safety benefits of a road improvement project. It goes beyond just looking at just the fiscal impacts by examining social welfare impacts too.

A Cost Benefit Analysis (“CBA”) quantifies (in monetary terms) all the major costs and benefits of project options. Thus the outcomes for a range of options are translated into comparable terms to facilitate evaluation and decision making. The technique also makes explicit allowance for the many costs and benefits which cannot be valued.

Where supporting data is available, every effort should be made to put a value on the monetary or quantifiable benefits and impacts. For some projects, a combination of the three evaluation techniques (monetary, quantitative and qualitative) may be adopted requiring a weighting of impacts to be applied across the three types of analysis. This enables the complete merits of an investment ranging from financial quantitative impacts to qualitative non-financial impacts to be considered.

Given the role and functions of Government, many proposed projects will be non-revenue generating or revenue-generating proposals which will not reflect positive net present values on the basis of their cash flows alone, but are undertaken to deliver other significant benefits to the community.

The business case should seek to place a quantifiable value on the extent of project benefits as much as feasible. That said, it is acknowledged that some non-financial costs, benefits and risks are difficult to measure given their subjective nature and it is not expected that all will be quantified or capable of being translated into monetary terms. All significant non-monetary and non-quantifiable costs, benefits and risks relating to each project option should be reported upon in an appropriate form in the business case.

The non-financial evaluation of a project option can be a complex process. Whilst in some instances the Directorate will have the requisite skills to undertake its own evaluation, some project options will require the services of an external consultant. As a minimum the project team should be in a position to identify the type and nature of the likely non-financial impacts which may result from each project option prior to engaging an external consultant.

A suggested framework for the non-financial analysis for projects over $10 million is illustrated below.

Page 22 of 55

Identify and classify non financial impacts (environmental, social

or environmental)

Review non financial impacts to detect

duplication

Select and apply a tool for the assessment of non-financial impacts

and apply

Step 1 Step 2 Step 3

Figure: Framework for non-financial analysis of options

Guidance on each step is provided in the following sections:

Identifying and classifying non-financial impactsNon-financial analysis in a general sense covers three broad areas: economic, social and environmental impacts. The first step in the non-financial analysis involves the project team identifying and classifying the impacts. This includes the following tasks:

Identify non-financial impacts: Identify all potentially significant non-financial impacts (economic, social and environmental) of each project option should be identified; re-gardless of how difficult they may be to measure (otherwise only a partial evaluation may be carried out). A further task is assessing the extent to which a project option achieves the broad objectives.

Classify impacts: Allocate all impacts under either an economic, social or environ-mental impact and further identify under each category whether the impact is a cost or a benefit to the broader community.

The following sections provide an overview of the economic, social and environmental areas of impacts.

Economic A project option may not be seen as 'financially' viable (with a positive net present value) but it may still be 'economically' viable to execute it. On this basis, the option will deliver a return from the perspective of the community. Two key economic considerations for a project option are:

o Whether it is economically efficient (whether the economic benefits of an option exceed the costs)

o The extent to which it contributes to Gross Regional Product (or its impact on the regional economy)

The economic analysis should demonstrate which option offers a greater economic return to the ACT community.

Identify quantifiable costs All economic appraisals should be based on incremental costs and benefits associated with a particular project. Changes which would have occurred anyway should be excluded. Assumptions underlying all capital and recurrent cost estimates should be made explicit in the evaluation.

The degree of accuracy desirable will vary with the significance of the project, data availability and cost of obtaining missing data. Best estimates are often sufficient but if there is doubt as to whether such will be acceptable, advice should be sought from Treasury.

Page 23 of 55

Identify quantifiable benefits The following may be relevant: Avoided costs-incremental costs which are unavoidable if nothing is done, but may be

avoided if action is taken; Cost savings-verifiable reductions in existing levels of expenditure if a program proceeds; Revenues-incremental revenues from introduction of the project; Benefits to project beneficiaries not reflected in revenue flows-while difficult, attempts

should be made to quantify these, with assumptions and methodologies clearly explained; and

Residual value of asset (if any).

Calculate net benefits Quantifiable costs and benefits over the project life - a 20 year analysis period is recommended for consistency - are expressed in Net Present Value terms.

Costs and benefits should be valued in real terms over the 20 years: that is, they should be expressed in constant dollar terms and not include nominal increases due to inflation. The stream of costs and benefits should then be discounted by a real discount rate of 7%, with sensitivity testing using discount rates of 4% and 10%.

The discounting process takes account of the fact that initial investment costs are borne up-front, while benefits or operating costs may extend far into the future. Discounting the value of future costs and benefits brings these back to a common time dimension - present value - for the purpose of comparison. The process of discounting is simply a compound interest calculation worked backwards.

The process of discounting real costs and benefit values reflects, even in the absence of inflation, the concept of time preference for money. People normally prefer to receive cash sooner rather than later and pay bills later rather than sooner. The existence of real interest rates also reflects this time preference.

Using the discounted stream of costs and benefits the following decision measures should be calculated:

o Net Present Value (NPV)-the sum of benefits minus costs; a project is potentially worthwhile (subject to the availability of funds) if the NPV is greater than zero.

o Net Present Value per $ of capital investment (NPV/I)-the highest NPV may involve very high capital expenditure and capital availability is normally constrained. Projects with the highest ratios would be potentially worthwhile.

o Benefit Cost Ratio-a project is potentially worthwhile if the BCR is greater than 1 i.e., the present value of benefits exceeds the present value of costs). It has become con-ventional to deduct ongoing costs from benefits to produce a net benefit stream, and to use initial capital costs as the denominator. This is the required basis on which res-ults should be provided. In cases where BCR calculations are done on another basis, for example to satisfy requirements of other Governments for jointly funded pro-jects, results should be shown on the two bases and clearly identified.

o Internal Rate of Return (IRR)-this is the discount rate at which the Net Present Value of a project is equal to zero (i.e. discounted benefits equal discounted costs). A pro-ject is worthwhile if the IRR is greater than the test discount rate.

o Sensitivity analysis should be undertaken to test the robustness of results under dif-ferent scenarios, using different assumptions about some or all of the key variables.

Identify qualitative factors and summarise results

Page 24 of 55

Quantifiable costs and benefits are only part of an economic appraisal. Other aspects such as environmental considerations, social or regional impacts, resource availability, funding, distribution of benefits and costs, etc, will also have to be taken into account in choosing between competing options and projects.

Some of these may be quantifiable to some extent but where they are not, qualitative aspects of options or projects should be discussed in the appraisal.

The report on the appraisal should include a clear summary of results, and indicate the preferred option.

Sensitivity testingSensitivity testing of the cost benefit analysis is a key element of risk assessment. The purpose of the sensitivity analysis is to acknowledge that there is always a degree of uncertainty and ultimately risk surrounding a proposal. Typically there are four sources of uncertainty surrounding a proposal:

o Capital costs; o Construction duration and therefore opening date; o Operating (including maintenance) costs; and o Under and over estimation of the benefits (typically demand for the service).

A risk assessment should be undertaken to estimate the typical variations around these inputs with the sensitivity testing undertaken based on the variations.

Social Analysis Most investments are undertaken to deliver services and, as a result, will have some social consequences. The business case should analyse social outcomes, unless it is clear that the external impacts are minimal. Social analysis identifies and quantifies social issues and opportunities arising from a project option. The analysis should explain the nature and extent of the social impact (and, where possible, quantify them). This might include:

Policy implications; Employment opportunities or likely redundancies/termination of existing contracts;

and Community.

Environmental Analysis Legislative requirements and community concerns drive the need for an environmental analysis. The environmental analysis should assess the extent and nature of environmental consequences and opportunities surrounding each project option. Issues include:

The extent to which a project option requires a departure from the ACT Govern-ment’s environmental policies;

Known environmental issues arising from the option (e.g. contaminated site); Consents or approvals required; and Whether an Environmental Effects Statement (EES) or a Commonwealth Environ-

mental Impact Statement (EIS) is required and issues arising from such requirements.

Page 25 of 55

Economic Analysis Guidelines (further technical advice on undertaking a CBA)

This provides further guidance material to support Directorates in undertaking a CBA.

The purpose of a CBA, like any policy analysis, is to provide information that will materially assist decision-making. The assessment involves identifying, quantifying and, where possible, valuing in money terms the costs, benefits and uncertainties of each option. It also involves quantifying costs and benefits that occur at different points in time on a comparable basis.The key steps in the CBA process are set out below.

Determine scope and objectives Identify the constraints Consider the alternatives Specify and quantify costs and benefits Calculate the NPV and BCR Sensitivity analysis.

Determine scope and objectivesThe first step for a CBA is to outline the nature of the problem to be addressed: its background, context and rationale. The information presented should also provide an initial indication of how appropriate the objectives of the initiative are in relation to current Government priorities. Following this, the outcomes expected from undertaking the proposal should be identified. They should be clearly distinguished from the means of meeting them.

Identify the constraintsThe next step is to identify the constraints in meeting the objectives to ensure all alternatives examined in the analysis are feasible. Constraints may be financial, distributional, institutional, managerial, environmental and political in nature.

Consider the alternativesA CBA involves the identification and specification of a set of alternatives. In most cases, a ‘do nothing’ or ‘status quo’ option should be included as a base case. This option is generally required because costs and benefits are nearly always measured as incremental to what would have happened had the project not gone ahead.

The process of developing and analysing a range of options can be expensive and time consuming. It may be appropriate to outline various potential options and have decision-makers select, after a preliminary screening, a smaller number for detailed appraisal.

Specify and quantify costs and benefitsA critical step in the CBA process involves identifying and quantifying the costs and benefits of each alternative. The types of benefits and costs will depend on the project. Typical costs of a proposal would include:

• initial capital costs;• capital costs of any buildings, equipment, or facilities that need to be replaced during the life

of the project;• operating and maintenance costs over the period of a programme or project; and• Costs which cannot be valued in money terms (often described as 'intangibles').

Typical benefits of a proposal would include:• benefits which can be valued in money terms, in the form of revenues, cost savings or non-

market outputs; and

Page 26 of 55

• Benefits which cannot be valued in money terms (also described as ‘intangibles’).

Estimating the magnitude of costs and benefits can be difficult and will normally involve input from economists and other technical specialists.

Intangible costs and benefits are those that cannot be assessed realistically in monetary terms, for example, some health and education benefits. Such costs and benefits should be identified and quantified to the extent possible.

Costs and benefits occurring at different time periods need to be set on a comparable basis. Normally they should be expressed in ‘real terms’ (this is, in constant prices) at the price levels prevailing in the year the analysis is carried out because inflation simply raises the values of all costs and benefits of future years by a given percentage. However, where the price of a particular good or service is expected to increase or decrease significantly more or less than the general rate of inflation (for example, oil prices may be expected to move faster or slower than general inflation), these changes in relative prices also need to be accounted for in the analysis.

Undertaking a CBA generally involves a degree of judgement. Individuals involved in an evaluation can often hold overly optimistic views in setting the costs, benefits and time profile of a project or activity. This behaviour is known as ‘optimism bias’. To counter this bias, appropriate adjustments can be made to the costs, benefits and time profile of the project or activity. Calculating adjustments for optimism bias is beyond the scope of these guidelines. [The UK Treasury’s Green Book - Appraisal and Evaluation in Central Government (pp.85-87) and Supplementary Green Book Guidance – Optimism Bias provides useful guidance on optimism bias.]

Valuation of Costs and BenefitsThere is an important distinction between the costs and benefits involved in a financial analysis and those included in an economic analysis.Financial analysis implies the notion of the Directorate maximising its net financial surplus over time. This will generally differ from the maximisation of the economic "surplus" generated for the community as a whole whenever prices do not fully reflect the benefits or costs associated with an activity (in some cases there may not even be any prices because benefits and costs are not traded).In estimating the economic costs and benefits of a project, values will often have to be estimated where no direct price is charged and will generally have to consider a wider range of costs and benefits than occurs in a financial appraisal.When considering how impacts should be valued in practice, it may be convenient to classify impacts into three categories.

• Costs and benefits which can be readily identified and valued in money terms (e.g. value of additional electricity supplies to users, travel time savings).

• Effects which can be identified and measured in physical terms but which cannot be easily valued in money terms because of the absence of market signals and con-sequential disagreement as to the rate of valuation (e.g. museums, reduction in pol-lution).

• Impacts which are known to exist but cannot be precisely identified and accurately quantified, let alone valued (e.g. crime prevention effects of police programs, com-fort improvements in new trains, aesthetic effects of beautification programs).

Costs and benefits which can be expressed in monetary terms will normally include estimated initial outlays and running expenses on the cost side and, estimated receipts and cost savings on the benefit side. In practice, the items to be included on the cost and benefit sides of the monetary calculations will include:Costs

• capital costs (estimates of the cost of land, buildings and equipment)• Operating costs (running costs for the whole life of the option).

Benefits

Page 27 of 55

• revenue from traded output generated by the asset• revenue from non-traded outputs• Benefits to users of the service not reflected in the price paid but which can be val-

ued.• cost savings• residual value of asset (if any)• Benefits to the broader community which can be valued.

Care must be taken to ensure that all investment-related costs and benefits are included, even those which do not actually involve spending or receiving cash.Benefits and Costs Which Can Be Quantified But Not Readily ValuedThere are many areas where some quantification can be achieved, but it is very difficult to place monetary values on them. For example, the number of children passing through a school or the number of people entering a national park can be measured, but valuation is far more difficult.In some cases these benefits or costs may be regarded as relatively minor in terms of the project. In these cases they can simply be described and taken into account in a subjective manner. Further consideration needs to be given to these benefits and costs when they represent the main or a major impact of a project. Benefits and Costs Which Cannot Be QuantifiedIn the public sector there are many areas where it is impossible even to measure the benefits and costs. Examples are the effect on law and order of the courts or the aesthetic impact of sewage works in an area of natural beauty. Again these items can simply be described if they are relatively minor.Costs to be excluded from analysisCBAs are conducted on a cash accounting basis. A number of items which are included as costs in accounting reports or financial appraisals should not be included in an economic evaluation of an investment proposal.Sunk Costs: In an evaluation, all costs must relate to future expenditures only. The price paid 10 years ago for a piece of land or a plant item is of no relevance; it is the opportunity cost in terms of today's value (or price) which must be included. All past or sunk costs are irrelevant and should be excluded.Depreciation: Depreciation is an accounting means of allocating the cost of a capital asset over the years of its estimated useful life. It does not directly reflect any opportunity cost of capital. The economic capital cost of a project is incurred at the time that labour, machinery and other inputs are used for construction, or in the case of an existing asset, when it is diverted from its current use to use in the project being evaluated. These project inputs are valued at their opportunity cost. This is why depreciation should not be included in the economic evaluation.Interest: As future cash flows are discounted to present value terms in economic evaluations, the choice of the discount rate is based on various factors which include the rate of interest and associated finance charges. The discounting process removes the need to include finance charges in the cash flows.

Project life and terminal/residual valueA project or program should generally be appraised over its projected life. This often accords with estimated physical lifetime of the assets. When conducting a CBA, all of the benefits and costs should generally be discounted over the life of the project. However, when assessing projects with long lives, it may be appropriate for the CBA to be conducted on the basis of a shorter timeframe (the useful life). Adopting a shorter time frame may be a valid approach as uncertainty with forward estimates increases with extended time.Where a shorter timeframe is adopted, a terminal/residual value is to be included in the CBA, to reflect all subsequent benefits and costs. The preferred approach for the BCR calculation is develop the residual value by applying a straight-line depreciation method. The alternative method is to calculate the residual value using an approach which estimates the future benefit stream provided by the asset (to the end of the asset life). This may be may be presented as additional information.

Calculate the NPV and BCR

Page 28 of 55

NPVIn CBA, the excess of total benefit over total cost is represented by the net present value (NPV) of the proposal.

Before determining the value (or NPV) of a proposal, the costs and benefits need to be quantified for the expected duration of the project.

Valuing each alternative by calculating NPVs facilitates comparison between proposals that exhibit different timing of their benefits and costs. Programmes with positive NPVs generally indicate an efficient use of the community’s resources.

The NPV of a proposal is determined by applying a ‘discount rate’ (discussed below) to the identified costs and benefits. It is necessary to ‘discount’ costs and benefits occurring later relative to those occurring sooner. This is because money received now can be invested and converted into a larger future amount and because people generally prefer to receive income now rather than in the future.The NPV is calculated as follows: tNPV = ∑ (Bt- Ct)/(1+r)t

0Where:Bt is the benefit at time t;Ct is the cost at time t; andr is the discount rate.

Where all projected costs and benefits are valued in real terms, they should be discounted by a real discount rate. If nominal (current price) values are used for projected costs and benefits, they should be discounted by a nominal discount rate.

The discount rate can also be varied to test the sensitivity of the proposal to changes in this variable and, implicitly, to the phasing of costs and benefits. Sensitivity analysis is discussed further below.

Setting the discount rateIt is necessary to discount costs and benefits occurring later relative to those occurring sooner since money has an opportunity cost – money received now can be invested and converted into a larger future amount. While discounting costs and benefits is integral to conducting a CBA, a critical consideration is the discount rate used. While there may be no universally accepted "correct" discount rate, interpretation of appraisal results will be impossible if different Directorates use different discount rates. The solution is the application of a standard set of real discount rates. For the purposes of the CBA the discount rates should be:

A real discount rate of 7% Sensitivity tests on the use of 4% and 10% to see if the outcome is sensitive to such vari-

ations. These rates are consistent with those required by Infrastructure Australia and the guidelines in New South Wales.

BCRFollowing the calculation of the NPV, the BCR for the project options is to be derived. It is recognised that there are two ways to estimate the BCR: 1) calculate the present value of benefits to the present value of costs or 2) calculate the ratio of the present value of net recurrent benefits to the present value of capital costs.

Page 29 of 55

Given the former is used more and established in the Infrastructure Australia guidance material, Directorates should use this approach, whereby the BCR is calculated as:BCR = Benefits / (Construction Costs + Operating Costs)

The benefit and cost measures are incremental to the Base Case and discounted over the evaluation period.

A ratio of greater than 1 (one) shows there is net benefit to a particular project having considered the present values of the costs and benefits. The BCR should always be greater than 1 in order for the benefits of a proposal to exceed the associated costs.

Sensitivity analysis The values of future costs and benefits on which the NPV is based are forecasts that cannot be known with certainty. While they should be forecast expected values, it is important to test the NPV for ‘optimistic’ and ‘pessimistic’ scenarios. This is achieved by changing the values of key variables in the analysis, such as the discount rate, costs and benefits, and measuring the impact of the changes on the NPV. This is known as sensitivity analysis and is a critical component of any CBA. Where the NPV is shown to be very sensitive to changes in a variable, the analyst should check on the appropriateness and impact of this variable, and whether any changes to the design of the programme or underlying assumptions are warranted.

Typically there are four sources of uncertainty surrounding a proposal: • Capital costs; • Construction duration and therefore opening date• Operating (including maintenance) costs• Under and over estimation of the benefits (typically demand for the service).

A risk assessment should be undertaken to estimate the variations around these inputs with the sensitivity testing undertaken based on the variations.

Additional guidance material on how to undertake cost benefit analysis can be found at the following links:

o the Department of Finance Handbook of Cost Benefit Analysis, January 2006 which can be found at: http://www.finance.gov.au/sites/default/files/Handbook_of_CB_analys-is.pdf

o The Green Book – Appraisal and Evaluation in Central Government, Treasury Guidance, London 2004 : http://www.hm-treasury.gov.uk/data_greenbook_index.htm

Page 30 of 55

Appendix D: Realisation of BenefitsPlan for benefit realisation especially in the larger business cases. This involves:

identifying the benefits quantifying them where practicable benchmarking them if necessary determining a realisation date or period this information can be represented in a Benefit Realisation Register (see Ap-

pendix   G ).This discipline can enhance the business case and the project in many ways:

clear owner accountability increases the likelihood that the benefit will be achieved it strengthens the business area’s ownership of the business case and the project as a

whole it promotes greater rigour in the identification and assessment of benefits it improves the accuracy and reliability of the CBA it sharpens focus on risks relating to benefits and enhances overall risk management it draws attention to the need for ICT deliverables to be converted to business bene-

fits. Sometimes this is immediate or easy to achieve, but often it will involve imple-mentation of new business processes and organisational change

it helps define how and when the project should be reviewed after implementation it may highlight the need to obtain baseline data before project implementation.Performance indicatorsIdeally, all benefits will be quantifiable and objective. In practice, this is not always the case. For example, “improved staff morale” is not easily measured.Benefits should be expressed in some objective and quantifiable way wherever possible. To use the same example, reasonable performance indicators for staff morale may be staff surveys or attrition rates. There are often costs associated with measurement of benefits — in establishing a measurement technique, performing a baseline measurement and then performing subsequent measurements. These costs can be significant — do not undertake costly baseline measurements for small projects. The costs associated with benefit realisation — including the measurement of benefits — should be included in the cost summary for the project.

Establishing a benefit realisation registerThe benefit realisation register should be created in consultation with the beneficiaries of the project. An owner must be identified for each benefit, and must have the authority and resources to ensure benefits are realised. Where multiple business units (or agencies) are expected to receive a single benefit type it may be better to create a separate benefit line for each business unit. This will allow each business unit to be separately accountable for its part of the benefit.

Page 31 of 55

Information to be incorporated in a benefit realisation register:

description of the benefit (e.g. “Reduced Operating Costs”, “Improved Client Service”)

the owner of each benefit the performance indicator — how the benefit will be measured, e.g. in

dollars, service times, frequency of errors, by client survey, etc. This may include a reference to national benchmarks for performance of similar functions

the current baseline measurement, if known and applicable the expected performance or measurement after implementation the required frequency of measurement the net benefit the realisation date or period. If there will not be a consistent rate of

realisation this may have to be explained in some detail. This informa-tion will be needed in calculation of Net Present Value and in establish-ing review criteria

who the benefit realisation reports will go to.

Page 32 of 55

Appendix E: Consultation and CollaborationEffective consultation is vital not only in the development of a robust individual business case but also in the achievement of best value for ICT investment across the ACT Government. This comes about in a number of ways.Stakeholders

Consult key stakeholders including customers, staff, suppliers, beneficiaries and any others likely to be affected by the project. If community consultation is required please refer to the ACT Community Engagement guidance material available at: http://www.timetotalk.act.gov.au/storage/communityengagement_FINAL.pdf

Shared opportunityThe initial impetus for an ICT project usually arises from the need to meet a specific business goal or solve a problem within a single agency or business “silo”. This may give rise to a valid business case but, by its nature, the project will only improve service delivery or deliver efficiencies within the line of business or agency. Also, it may fail to take account of similar initiatives already being undertaken elsewhere in Government.ICT strategic planning may already have identified areas of common need, common delivery mechanisms or a common client base, from which a beneficial joint approach could be developed. In practice, this may not always happen. For example, ICT strategic plans might not exist, they might not have a cross-agency perspective or they might not reflect recent changes in the business and technology environments.Effective consultation across agencies will help identify these opportunities. This may result in a project that delivers broader benefits, has greater economies of scale and provides better value for money to the ACT Government.

Parallel developmentsWhere there is a common business need or opportunity there may already be an ICT initiative under way elsewhere in the ACT Government. Effective consultation (e.g. with Shared Services ICT) can help prevent the duplication of effort and investment and the lack of integration that follows.

Policy and standards complianceConsultation must include reference to those policies and standards with which the project must comply. These policies or standards could be financial, business, legal or technological in nature. An example is conformance with any ICT architecture stipulated by Shared Services ICT for any system that is to be integrated into the ACT network. There may also be national standards that are relevant to the project, such as call centre standards.

Subject matter expertiseSubject matter specialists can provide a clearer insight into costs, benefits, risks and approaches. For example, Chief Minister, Treasury and Economic Development Directorate should always be consulted for guidance on financial analysis in high cost projects.

Breadth of viewsIn general the more consultation that takes place the greater the likelihood that a comprehensive set of risks, costs, benefits, stakeholders and opportunities will be identified. However, consultation has its own costs, so the extent of consultation should be commensurate with the scale of the project being considered, and governed by common sense.

Page 33 of 55

CollaborationWhere a joint approach is adopted (or a whole-of-government approach) one agency should take the lead agency role. This agency will typically be the one receiving the most benefit from the project or best equipped to provide project skills and resources. While a joint approach has the potential to yield greater benefits and provide better value for money, it should be recognised that such an approach also brings greater complexity and risk to a project. Time and resources must be identified in the business case for the management of cross-agency issues, communication and coordination.

Page 34 of 55

Appendix F: ChecklistsWhile each project will have its own unique characteristics there are cost, benefit and risk items that are common to many projects. The following checklists are provided as an aid, but are not necessarily exhaustive.

Cost componentsManagement overheads: tendering and procurement contract negotiation and contract management partnership management and co-ordination project governance.

ICT facilitiesGenerally, Shared Services ICT manages ICT facilities including hardware, software licensing, networks, operations, support services and call centre. These services and facilities are provided on a full cost recovery basis so they will become real costs to the project. Shared Services ICT can assist in identifying the relevant cost components and should be consulted for pricing details.

Development and implementationThe procurement process may account for much of the development cost but there will still be significant additional costs to be considered: any software development costs not covered by the procurement acceptance testing development of test plans and test data staff costs in assistance with analysis, design and review of staged deliverables training of staff — provision of training and staff time spent on training additional software packages not covered under Shared Services ICT arrangements

(e.g. specialist tools) change management strategies — marketing, communication, consultation, etc documentation of new business practices and policies project management audit data entry, conversion, initial load and verification systems integration (possibly provided by Shared Services ICT) provision of office space and facilities for the project team.

Recurrent costs: ongoing Shared Services ICT costs (see above — ICT facilities) training revision of documentation support for periodic upgrades of hardware and software, including project manage-

ment, impact analysis, testing and verification, review, etc change control audit

Page 35 of 55

consumables application administration and advice.

Benefit ComponentsCost savings: reduction in labour and tasks — corresponding staff reductions/redeployment reduction in maintenance costs removal of any direct costs currently incurred increased revenue or reduced revenue leakage reduced inventory requirement.

Productivity: ability to handle increase business volume with existing resources improved or faster service delivery better use of staff better use of assets.

OpportunityThese tend to be the least conducive to accurate monetary measures but are still important: implementation of government policy or strategy better planning and decision making improved public image environmental (“green”) benefits improved morale better access to information transparency of government processes avoidance of future costs avoidance of future risks.

Risk ItemsTechnology and integration: new or unproven technology products with small market share, uncertain future unproven integration of products complex integration of systems and processes high performance characteristics required for system viability.

Skills and resources: loss of key personnel scarcity of specialist skills.

Political issues: high project cost and visibility

Page 36 of 55

high public interest, contentious policy potential for adverse side impacts probity, conflicts of interest.

Financial risks: potential for cost blow-out potential for delays in completion (deferral of benefits) inability to lock down variables (e.g. market driven forces, exchange rates).

Project management: scale of project number of partners, stakeholders and participants complexity of tasks uncontrolled variables compressed delivery schedule due to urgency inadequate definition of deliverables and scope poor control of changes in scope or specification.

Change management and benefit realisation: extensive change to business processes extensive impact on staff and clients changing business environment changing government policy or strategy.

Inter-agency or whole-of-government projects: lack of common objectives communication and co-ordination (difficulties, delays, costs, decision making) lack of ongoing ownership or commitment from one or more stakeholders different culture or practices from one agency to another integration of business practices and client interface.

Contractual and vendor: poor contract specification inability to agree to contract variations vendor financial viability.

Page 37 of 55

Appendix G: Forms Cost-benefit Analysis

Risk Register

Risk Identification Log

Benefit Realisation Register

Document Control

Page 38 of 55

Cost - Benefit AnalysisSuggestion: Reproduce this table on an excel spreadsheet for each option considered.

OPTION A (E.G. BASE CASE)

Year 1 2 3 4 5 6 7

BENEFIT ITEM 2016/17$’000

2017/18$’000

2018/19$’000

2019/20$’000

2020/21$’000

2021/22$’000

2022/23$’000

TOTAL$’000

Benefits to consumersSalary SavingsAssociated On-Cost SavingsIncreased RevenueCosts AvoidedOther financial and economic benefits

TOTAL BENEFIT

COST ITEM 2016/17$’000

2017/18$’000

2018/19$’000

2019/20$’000

2020/21$’000

2021/22$’000

2022/23$’000

TOTAL$’000

Salary CostsAssociated On-CostsConsultant CostsCapital OutlaysMaintenance CostsOther financial and economic costsTOTAL COSTNet Cash FlowDiscount Factor (7%)PRESENT VALUE of future cash flow (Net cash Flow * Discount Factor)

Page 39 of 55

Risk Register

Project Name: Project Manager:

Project Sponsor: Agency:

Description of Risk: Risk Id:

Risk Owner:

Probability: Low ( < 10%) / Medium (10 – 50%) / High (> 50%)

Potential Impact: Low / Medium / High

Impact Description:

Overall Risk Rating (Exposure):

Assumptions:

Risk Treatment Plan:

Residual Probability: Residual Impact: Residual Risk Rating:

Additional Comments:

Page 40 of 55

Risk Identification Log

Risk Id Risk Description Probability Impact Rating Treatment Plan

1

2

3

Page 41 of 55

Benefit Realisation Register

Project Name: Project Manager:

Project Sponsor: Agency:

Description of Benefit: Benefit Id:

Benefit Owner:

Performance Indicator (how benefit will be measured):

Current Baseline Performance (if applicable):

Expected Performance:

Net Benefit:

Assumptions:

Frequency of Benefit Measurement: Realisation Date or Period:

Distribution of Benefit Reports:

1.2.

Page 42 of 50

Additional Comments:

Page 43 of 55

Document ControlDocument name:

<project name> business case

Document status:

Draft / Final / Revision

Version No.

File Name: <filename>.doc

Date:

Authorised by: <approver>

Distribution:

DOCUMENT VERSION CONTROL

Version Date of Issue

Author Reason for Change

Table 1 – Change History

Page 44 of 55

Appendix H: ContactsShared Services ICT

Shared Services ICT should be consulted in developing any business case for an ICT enabled business project. Engagement should take place in the first instance through the Shared Serviced ICT Enterprise Technical Architecture and Strategy Section. DeanShared Services ICT can assist with matters concerning ICT infrastructure, costs, timing, risks, integration and compatibility with the existing computing environment. It can also assist more generally with:

better practice in the development of business cases identification of other projects with common objectives, clients or subject matter identification of opportunities for a collaborative approach with other agencies ICT-related ACT Government policy.

Contact Details: William Mudge, Senior Manager Enterprise Technical Architecture and Strategy (SSICT) 6205 0902

ACT Chief Minister, Treasury and Economic Development Directorate ContactsFor assistance with Cost-Benefit Analysis, please contact Kathy Goth, Director Chief Minister, Treasury and Economic Development Directorate, Economics Branch, x50772.

For assistance with general questions in relation to the budget process please contact Paul Hutchinson, Senior Manager, Chief Minister, Treasury and Economic Development Directorate, Finance and Budget Division, x50068.

Page 45 of 55

Appendix I: Business Case Template for ICT-enabled Business ProjectsPlease read these important hints for completing this template

To maintain consistent numbering, complete all sections of this template. If no data is provided in a non-mandatory section, enter – Not Applicable.

After you have finished preparing your business case, for neatness, delete all of the explanatory text that relates to how to complete this template, including this page.

Page 46 of 55

Cabinet-in-Confidence2016-17 CAPITAL WORKS PROGRAM

NEW ICT – ENABLED PROJECTBusiness Case Template for Information, Communication and

TechnologyAgency: Minister: Project Reference No. and Title:Physical Location of Project:Financial Impacts Summary: (if the purpose of this business case is only to seek approval to proceed please enter N/A below).

Impact2016-17 2017-18 2018-19 2019-20

$’000 $’000 $’000 $’000Requested Funding - Recurrent (GPO / EBT) - Capital InjectionOther Recurrent Impact - Depreciation - Revenue

Staffing Impacts Summary

Impact 2016-17 2017-18 2018-19 2019-20Total Additional FTEs

Summary of Estimated Project Costs (excl. GST)

Breakdown of Construction Project Costs:

Cost $000Feasibility <Please specify where funded in

prior year>Design and Supervision <Please specify where funded in

prior year>Contingency (if any)ConstructionProcurement Fees of 4%1

Insurance (Approximately 1% of construction costs)Other (specify)Total

Page 47 of 55

Breakdown of Annual Costs:201617$’000

2017-18$’000

2018-19$’000

2019-20$’000

Depreciation (not funded)Ongoing Maintenance2

Ongoing Operational2Other (please specify)Total1 Mandatory fee payable to Procurement Solutions (excludes Plant and Equipment purchases).

2 Maintenance and ongoing operational costs are generally not applicable in the first year.

Timeframe and Site Indicate proposed project timeline including procurement, milestones and deliverables. Indicate identified site/location; is there any impediment to the project commencing early in the

financial year(e.g. planning approvals not assessed, consultation risk etc.)?

Page 48 of 55

ICT BUSINESS CASE TRACKING SHEET

1. Name of Proposal:

[short name of proposed project]

2. Submitted to:

[identify the board, committee or executive]

3. Date of Submission:

[date submitted for funding or approval]

4. Purpose of Submission:

[state whether submission is for funding or approval to proceed]

5. Owner:

[name, title and contact details of the Owner]

6. Sponsor:

[name, title and contact details of the Sponsor]

7. Business Case Contact:

[name, title and contact details of the main contact person for the business case, normally the person preparing the business case]

Page 49 of 55

ICT Business Case Sign-OffOwner:I propose the initiative outlined in this business case. I have assessed the business case as sound, based on a thorough approach to cost benefit analysis of competing options and a rigorous risk assessment. In my view the proposed initiative would deliver measurable outcomes that are a priority.If the resources outlined in the business case are made available to me I agree:

that I have, or can acquire, capacity to govern and manage the project within the costs and timeframes outlined in the business case;

to be accountable for delivering the benefits promised in the business case; and

to take delivery of the end-products of the project (e.g. ICT business sys-tems) and be responsible for their ongoing maintenance.

Name: Signed: Date:

Director Business Development SSICT or Executive Director SSICT

In my view the ICT-enabled component of this business case is sound, aligned to ICT strategy and represents a best value approach at the whole of government level. Also, in my view, Shared Services ICT has capacity to undertake its roles in relation to this additional ICT-enabled project together with its other existing projects.Name: Signed: Date:

Agency IM/ICT Executive or Chair of Agency IM/ICT Committee:In my view, the ICT-enabled component of the proposal outlined in this business case is sound, aligned with other initiatives and opportunities in the agency and is a priority worth consideration by the sponsor. Also, the agency has capacity to undertake this ICT-enabled project together with its other existing projects.Name: Signed: Date:

Agency Chief Finance Officer:In my view, subject to the accuracy of the financial assumptions in the business case, and subject to funding being provided as proposed in the business case, the Agency will be in a financial position to both proceed with this project and fund the ongoing care and maintenance of the products that are proposed to be produced by the project.Name: Signed: Date:

Page 50 of 55

Sponsor (if applicable):This is a sound proposal for an initiative that is worth undertaking and is a priority for my agency. I request that the initiative be funded from the source outlined in the business case, if funds are available.Name: Signed: Date:

Page 51 of 55

Document Control- Use for business cases likely to go through several drafts and which will be widely cir-

culated. Use the Document Control template- Version number and status- Amendment history

Table of Contents- Use for large business cases only.

1. Executive Summary- Use for larger documents only (10 pages or more)- Provide a brief description of the proposed construction project

o This section should provide a brief description of the project and be limited to approximately 3 sentences.

- Define the operational or business need, or problem to be solvedo Provide information on the demographic/service delivery need for your pro-

posal.o Is the operational need identified in your agency’s asset management plan

or service delivery plan?o Is there any variation from Government’s election commitment?

(scope or $).

2. Project Overview- Mandatory. Do not include any text here. See major sub-sections below

2.1 Objective- Mandatory. A one line statement that captures what the project is about

2.2 Target Outcomes- Mandatory. State the business outcomes the project is intended to achieve

2.3 Business Need- Mandatory. The current business problem, deficiency or opportunity

2.4 Impact of Not Proceeding- Mandatory. Impact of deferring or not proceeding with the project

2.5 Scope- Use for large business cases only- In scope business functions- In scope business processes- Organisations and business units involved- Out of scope functions, processes or organisations

2.6 Description- Mandatory- Scope of project (small business cases only)- System users and their access channels- Is the project self-contained or part of a larger initiative- Summary of required technology- Implementation approach (small business cases only)- Significant assumptions and constraints

2.7 Conformity with Policy and Strategy

Page 52 of 55

- Conformity with relevant ACT Government policies and standards- Conformity with national standards- Conformity with Shared Services ICT architecture

2.8 Implementation Strategy- Use for large business cases only- Summary of procurement arrangements- Partnerships or alliances, and how they are to be managed- Approach to contract management, project management and systems integration

2.9 Deliverables- Mandatory. List and describe all project deliverables and estimated completion dates - This should include a breakdown of hardware

2.10 Project Governance- Mandatory- Describe how the project will be governed. Include a graphic representation of the

proposed governance structure

2.11 Project Timing- Mandatory- Project schedule (may be attached as an appendix)- Expected system life span

3. Summary of Costs and Resources

3.1 Costs- Mandatory- Summary of all major cost items- Overall project cost - Attachment A – Financial Impact at http://incmtd/ACTPS_CFO/SitePages/Budget

%20Officers.aspx

3.2 Resources- Mandatory. Major resource groups to be used on the project

4. Funding Strategy- Mandatory (do not include text in this text box). See major sub-sections below.

4.1 Investment or Funding Sought- Mandatory- Total Project Budget- Type of funding sought (if any)- Amount of funding sought- Repayment schedule if a capital advance- Schedule of required funding in future years

4.2 Source of Funds- Use for large business cases only- Funding schedule showing different funding sources- Contributions of each partner in a joint venture- “In kind” contributions

5. Risk Assessment- Mandatory. Use the Risk Management templates for large projects

Page 53 of 55

- Significant risk items for the recommended solution, with their probability, impact and overall risk rating

- Two key areas of risk that should be assessed are data migration and integration with existing systems

- Australian Standard on Risk Management (AS/NZS ISO 31000:2009)- Risk treatment plan- Risk Assessment summary for the recommended solution

6. Impact and Change Management

6.1 Impact Statement- Impact statement (clients, service, staff, processes, technology, etc)

6.2 Change Management- Change management strategy (for changing roles, organisation, culture)

7. Control Issues- Security- Privacy- Confidentiality- Intellectual Property- Disaster Contingencies

8. Benefit Realisation- Use for large business cases only. Use the Benefit Realisation template- Register of expected benefits and timing- Performance indicators

9. Consultation- Mandatory- Consultation schedule (partnership opportunities, consultation on standards, policy,

architecture)

10. Linkages and Dependencies- Mandatory- Include details of how proposed investment may be relevant to other directorates and

to any existing system(s) used elsewhere in ACT Government- Include details of any dependencies and any related projects, their implications and

how they will be managed

11. Comparison of Options- Mandatory. (do not include any text in this text-box)- If an options paper was completed prior to the business case, and it covers attach

this as an annexure. Complete the sections below only to the extent they are not covered in the options paper

- Otherwise complete the sub-sections below

11.1 Description of Options- Mandatory- Overview of each option considered. Ensure low cost option has been canvassed.- Key areas of differentiation

Page 54 of 55

11.2 CBA- A Cost-Benefit Analysis should be completed for all projects over $10 million.- CBA schedule for each option- Comparative CBA Table- Summary of CBA findings

11.3 Risk Assessment Comparison- Mandatory- Comparative risk assessment for the range of options considered

11.4 Recommended Option- Mandatory- Recommended option including principal reasons for recommendation

12. Feasibility Studies- If a feasibility study has been carried out, summarise the outcomes and attach a copy

13. Attachments- Use attachments as appropriate for readability and separation of extensive detail from

the main body of the business case. Examples of attachments are (please note At-tachment A is mandatory)

A. Financial Impact- Mandatory – Use the template at http://incmtd/ACTPS_CFO/SitePages/Budget

%20Officers.aspxB. System SpecificationC. Project ScheduleD. Risk Management TablesE. Cost-Benefit SchedulesF. References to other project documentationG. Glossary

Page 55 of 55