Chapter 4 - From Executive Summary to Viable Options

Introduction

This chapter provides guidelines for preparing content for the first five parts of the recommended structure of a business case, as set out in Chapter 3. This chapter covers:

• Executive Summary
• Alignment
• Relevant Information
• Proposal
• Summary of Viable Options.

For detailed guidelines on preparing other parts of the recommended structure, see:

• Chapter 5 for Supporting Schedules for the Recommended Option
• Chapter 6 for Recommendations
• Chapter 7 for Appendices.

Section 4.1 - Summary, Alignment, and Relevant Information

Introduction

This section provides guidelines for preparing content for the following parts of the recommended structure of a business case:

• Executive Summary
• Alignment
• Relevant Information

Preparing the Executive Summary

What it should cover

The Executive Summary should cover the major points of the proposal, e.g. what is actually proposed for delivery. This would include:

• The need for the project, including its context and background
• the total costs and timeframe of the project
• summary of benefits
• significant legal and privacy implications
• key Risks and Issues.

It should be a sound, reasoned summary of the current position including:

• reference to the major merits of the proposal
• comment on the general effects including risks to the Crown, if the proposal does not proceed.

Condense major aspects

The Executive Summary should be as short as is reasonably possible, condensing the major aspects of the business case. It should not normally exceed three pages.

What to comment on

It is appropriate to comment on:

• What is being asked for, e.g. the authority or funding requested, the source of which may be controversial.
• What situation is being addressed by the proposal, e.g. what opportunity or problem is to be addressed, and what is the objective of the project.
• What are the effects on other areas of government interest, e.g. Privacy Act implications, other legislation or regulations.
• Why this proposal is being put forward, e.g. why the work should be done and why it should be done now.
• What are the linkages to strategic plans, e.g. sector, agency, all-of-government.

What may be commented on

It may also be appropriate to comment on the following:

• Why the proposal is value-for-money, i.e. worth doing, the price is appropriate, and the real measures available for later assessment of success.
• How this proposal relates to government priorities.
• How this proposal relates to the e-government strategy.
• The options considered, including the likely effect of not proceeding with the proposal.
• The cost, over what period, and how it is to be funded, both in the development phase and for ongoing operations.
• The benefits, which agencies will see them, and when.
• The significant associated risks/issues.
• Who has an interest in the proposal, or is affected by this work, and what consultation has been carried out and how.
• The significant implications, e.g. policy issues.
• The identified significant legal issues (direct and indirect, liability, service failure implications). Particularly include specific comment on legislative implications.
• The identified other issues, including the impact on privacy.
• What transition to business-as-usual is acknowledged, including reference to ongoing funding, support and long term ownership of the outcome, i.e. governance.
• The effects of the operational aspects of the proposal, e.g. future refreshes, upgrades and associated costings.
• What announcements of this initiative should be made and at what timing in the project.

Alignment

Align with vision and strategy

An important consideration is the alignment and fit of the business case proposal with the:

• vision and strategy of the agency and the sector within which the agency operates
• e-government vision and strategy.

This should include commentary on how the implementation of the business case will affect the operation of other Crown agencies.

What the alignment comment should cover

Comment on the alignment with agency and sector strategies should address:

• the agency’s core business, including the effect on this agency and on agencies involved in progressing this proposal
• how the proposal developed in the business case advances government’s goals and objectives, as defined in the agency or sector vision and strategy.

To demonstrate the degree of alignment with the e-government strategy, explain how the proposal meets the definitions of e-government activity, and how the project supports the e-government vision and strategy, including mapping the activity to the e-government work streams set out in the E‑government Strategy

Reference: For the E-government Strategy, see http://www.e.govt.nz/about-egovt/strategy/

Relevant Information - Background

Introduction

This section records the events, situation, reasoning and thinking that has led to developing the proposal and hence the business case. The section is to provide historic information relevant to the situation being addressed. It will leave the reader with a clear understanding of why the business case has been developed.

What to comment on

Information included should be as detailed as is needed to ensure readers correctly understand the proposal in its appropriate context.

The comment in the business case should provide positive information demonstrating:

• the problem/opportunity to be addressed and how this was identified
• the business rationale, i.e. that the proposal is a good idea, why the issue is one that needs government intervention, and why now
• evidence of support from the sector, management, internal and external stakeholders involved, i.e. successful consultation
• evidence of anticipated effectiveness, based on predicted results and the criteria used for determining that evidence, and
• the reasoning behind the development of the proposal, including providing any historic information relevant to the situation being addressed.

Relevant Information - Current

Introduction

This describes the ‘here and now’. It covers the situation as it is currently seen by Ministers or the agency. The section should comment as to why this action should be taken in the specified timeframe.

Comment may extend to ‘what will be’ if nothing is done, although this may be better sited in the description of the available options.

Why this business case now?

This part of the business case summarises why it is appropriate to prepare and present this business case now.

There are two basic propositions that will lead to such a task:

• There is a government goal to be achieved, i.e. a new (political) initiative being driven by Ministers, or
• There is a problem or opportunity that can or needs to be addressed.

The importance of the policy drivers, in and for, a cross-sector initiative should be explored. Cover the views of all stakeholders.

Current situation should include

The business case should clearly indicate:

• The agency that is to develop/operate the proposal. This may include indicating the other related agencies that may be involved either on the periphery or at a much closer level.
• The users of the new (or changed) service, e.g. members of the public, business users or other special interest groups.
• Any other stakeholders, including international considerations.

Section 4.2 - Proposal

Introduction

This section provides guidelines for the Proposal section of the business case.

The Proposal records the choice put forward out of the available options. It will be longer than the Executive Summary or Recommendations.

Proposal contents

The proposal outlines:

• what is to be done
• by whom
• how
• at what cost, and
• what discernible benefits will appear and over what time period.

Proposal Content

Introduction

The proposal should include ‘minimum but sufficient’ detail, enough to allow understanding, and providing comment at least on:

• the purpose of the proposal
• options
• the recommendation
• an implementation strategy
• quantification of costs, benefits and time frames
• funding approach
• risks and issues
• consequential effects
• legal and privacy issues
• governance
• reference to appendices.

Further details on some of these are given below.

Purpose

The purpose of the proposal should be set out, including:

• the opportunity/problem being addressed
• the actual proposal
• the objective
• achievement - how will we know it has/has not been achieved? (Key Success Criteria)

Options

These need to be realistic alternatives, one of which is the likely effect of non-acceptance of the proposal.

See Section 4.3 for a more detailed discussion of how to address Options.

Recommendation

A choice must be recommended.

Implementation Strategy

The approach to implementation should be outlined, including a change management strategy where required.

Quantification

The key elements of the business case must be quantified, including providing comment on levels of confidence and related sensitivities for each item. In providing information on each of the following, it is essential to:

• read and understand Section 5.8 in these guidelines about ‘range of possible outcomes’ rather than to provide only ‘single point numbers’.
• have thought through and understood the ongoing operational aspects and future implications of the proposal (staffing, future refreshes, upgrades and associated costings, etc).

Examples for quantification comment

Areas for quantification comment are:

Cost(s) - Direct and Indirect, e.g.

• staff
• capital (asset)
• capital (funding costs e.g. Depreciation, Capital Charge, GST handling, Rate of Return, etc.)
• construction consumables
• ongoing operation costs, etc.

Benefit(s) - Direct and Indirect, e.g.

• to government (agency or sector) or the community (the public or businesses)
• addressing quantifiable (dollars or time) and non-quantifiable (reduced complaints, better transparency, improved infrastructure, achievement of political goals, etc.)
• possible specific or general multi-agency deployment outcomes, possible protection to an agency of the impact of changing technology (future-proofing)

Time - developmental timeframe and operational lifespan, e.g. required for construction or until production is achieved.

Funding approach

The proposal should describe the approach to be taken to its funding, e.g. by:

• Vote: (indicating single or multi-year appropriation)
• User pays
• Public-Private Partnerships
• Joint Ventures.

Where different options involve different approaches to funding, then comment should be made on the rationale and associated benefits of each approach.

Risks and Issues

Significant Risks and Issues should be stated, demonstrating:

• probability (likelihood)
• consequence (impact) factors, and
• comment on available mitigation action.

A risk sensitivity analysis (possibly including political risk) should be included if appropriate.

Consequential effects

Consequential effects of undertaking the option should be stated. Include any significant impact(s) on the operation of other agencies or for government as a whole.

Legal Issues

Legal requirements should be stated, including comment and recommendations to address the various different legal risks, e.g. those associated with:

• liability
• service failure
• delivery repudiation
• audit and review.

Privacy Issues

Privacy impacts should be identified

Privacy Impact Assessments (PIA) should be prepared or their preparation proposed – see the PIA Handbook, as developed in 2002 and published by the Office of the Privacy Commissioner. Even if you think there are no Privacy Implications, we recommend you talk to the Office of the Privacy Commissioner. Further comment is contained in Section 5.3.

Reference: Copies of the handbook are available from the Office of the Privacy Commissioner. Requests via: enquiries@privacy.org.nz

Governance

Comment on Governance should be included to address the:

• proposed governance model for the project
• more complex multi-agency management arrangements
• management of the completed, implemented system.

An approach to deciding how to govern shared activities is available on the e‑government website.

Reference: http://www.e.govt.nz/docs/gov-shared-200406/index.html

Supporting Content

Introduction

There is a secondary level of information that should be addressed in the business case.

Depending on the relevance of any particular section, i.e. the context of the business case, additional detail or further new information may need to be provided, either by inclusion in the main body of the document or by using appendices or annexes.

Consultation

Address any consultation undertaken to support the proposal or intended to be undertaken as part of the project. This may include both agency and public consultation. The latter may require Cabinet prior approval.

Reference: Cabinet Manual Step-by-Step Guide Chapter 11

• http://www.dpmc.govt.nz/cabinet/manual/index.html
• http://www.dpmc.govt.nz/cabinet/guide/11.html

Independent Quality Assurance (IQA)

Include provision for an Independent Quality Assurance (IQA) function to undertake monitoring, follow-up and review work. The risk profile may indicate the extent of IQA needed.

The process is documented in Managing and Monitoring of Major IT Projects (http://www.ssc.govt.nz/ITguidelines).

Need for specialist skills

Comment on the need for ‘specialist skills’ for the particular project (e.g. programme manager skills, architect, security specialist). Include comment, if appropriate, about the availability of that skill within New Zealand.

Other possible inclusions

Other possible inclusions in the proposal are:

• a Māori Issues or Impact report
• other associated strategies, e.g. communications plan, change management strategy
• an assessment of architectural issues arising from new technology, particularly on existing infrastructure and planned strategic direction.

Appendices

Appendices should be referenced. They provide the additional supporting detail for the above items if needed as well as providing additional general information. Appendix examples include:

• assumptions
• glossary of specialist terms
• bibliography
• references.

See Chapter 7 for Recommended Appendices.

4.3 Options

Introduction

This section provides guidelines for preparing content for the Options part of the business case.

The Options section covers the alternative ways of achieving the proposal, not alternatives to the proposal (these will have been discussed and dealt with before the business case is prepared).

Provide a real choice

The Options section provides the detail of the choices available to Management (Ministers). The aim is to provide the decision makers with real choice, unless there is no real choice.

Summary and analysis

Options are presented in two parts:

• a summary, in which the presented options are outlined and the recommended option highlighted, and
• an analysis of the supporting detail for at least the recommended option, plus sufficient of the reasons why the other options are viable but are not recommended.

Presenting Realistic Alternatives

Viable alternatives

The business case should provide whatever number of real viable alternatives is available. At least two realistic alternatives should be presented, for example:

• Base case
• Action case, which can encompass further alternatives, based on:
• • Different strategies for approaching the solution, e.g. redefining business processes, re-using an existing application
  • Different approaches to achieving the purpose, e.g. different technologies, different conceptual approaches
  • Different scales of intervention, e.g. basic v full service, centralised v federated, different timeframes
  • Different acquisition approaches, e.g. off-the-shelf, custom-built, doing it in-house- Different funding options. e.g. baselines, user-pays, new funding, joint venture.

Another option to be considered is to stop doing the activity at all.

Base case

The Base Case identifies what will happen if no action is taken. It may not be sufficient to describe the Base Case solely as a continuation of the existing situation. It will need to reflect expected changes in the environment over time so that an effective comparison can be made with the other options, including the costs that could arise from making no changes, e.g. maintenance costs, as well as benefits, e.g. reduced training costs.

Action case – different strategies

There may be options which are based on making optimum use of existing systems or on altering or re-engineering existing procedures. These could include:

• Redefining the business process concerned to help clarify the extent to which new investment may be required.
• Re-use of an existing application or process within the agency, sector or elsewhere across government
• Re-engineer the existing system to deliver the required outcome or functionality.

An evaluation of the existing or desired process in terms of the outcomes sought and the stakeholders affected should be carried out to determine whether such strategies provide viable options.

In checking on the extent of potential re-use, the experience of other agencies will be an important source of information.

Action case – different approaches

There may be different technologies available to meet requirements, including existing technologies as well as new or emerging technologies.

The agency may also be familiar with a technology or conceptual approach so that any different technology will have additional costs, including training costs and costs relating to interoperability with existing systems and processes.

The use of new or unfamiliar technologies can introduce risks that need to be recognised and addressed.

Action case – different scales

The Action Case alternatives can sit inside scales of intervention or activity that range from:

• Limited intervention to full intervention.
• Centralisation of activity or responsibility to federated or dispersed action.
• Immediate and full roll out to phased implementation

The extent of intervention may be driven by:

• Political objectives
• There are no other players in the market
• The timeframe required for delivery

The alternatives around the extent of centralisation can reflect the roles undertaken by the agency, intermediaries or users in implementation, and can have a significant effect on the location of costs (and benefits).

A phased proposal could be undertaken as a series of increments, i.e. components which contain stand alone deliverables. If this approach is adopted, the relevant information should be presented for each increment.

Reference: See Chapter 5, Section 5.11, the topic ‘Early Exit Strategy’ for further information on ‘off ramps’.

Action case – different acquisition approaches

Acquisition options include:

• purchasing an off-the-shelf product
• custom-building a new application or process
• • doing it in-house
  • contracting out
• outsourcing

Description of options

The sections outlining the options should state, for each option:

• what is to happen under the approach concerned, and the total costs and benefits (including to users/stakeholders)
• The assumptions made, including the state of technology, the operating environment and organisational constraints should be outlined.

Summary of Viable Options

Summarise options

The available options should be summarised. A detailed analysis is required only for the recommended option. The key reason or reasons why other options offered are not recommended should be provided.

Note: The level of detail needed to support the recommended option is not required for those options not recommended.

Screening of options

A detailed analysis of all of the options is not required. A process for screening the options should be undertaken which establishes a basis for selecting and rejecting options.

Options should be excluded as soon as it becomes clear that alternatives better fit the criteria.

Grouping options on the basis of similar key features can help identify important differences, e.g. in cost/benefit, and will assist in early rejection of options.

Analysis of options

The analysis of the options should address:

• Policy Goals. How this proposal addresses government outcomes including comment to address the importance of cross-sector initiative policy drivers.
• Strategic priorities. How each option achieves these at the all-of-government and agency level.
• Key initiatives. How each option supports government, sector or agency initiatives.
• The immediate actions that would result from approval of each option.
• Comparative costs and benefits across each of the options, at a summarised level.

[ Previous | Next ]