Chapter 2 - E-government Business Cases

General Guidelines

Introduction

This chapter gives general and background information to assist in the preparation of e-government business cases.

All business cases are different. What to include and what to exclude is the prerogative of the proposing agency, but it is the prerogative of Central Agencies and the governing body to ask for further detail.

These guidelines are provided to assist in minimising the need for additional effort by ‘getting it right the first time’.

Apply common sense

Sufficient work and research needs to be undertaken to support assertions made in the business case. What constitutes 'necessary and sufficient' cannot be determined in advance, or by the use of a specific form of approach. There is no substitute for thinking about the proposal and applying common sense when considering what to include and what to exclude.

The documentation that results from the research programme and leads to the preparation of a proposal should support all aspects of that proposal – i.e. the business case. The document should leave the business case writer, and its readers, comfortable with:

• answering questions related to the case
• knowing where to get the answer to such questions.

Read this chapter first

You are urged to read this chapter before studying the content of later chapters. It is designed to give you the background information, to guide your thinking before you undertake the approaches detailed in later chapters of this document.

Section 2.1 - About E-government Business Cases

Introduction

This section defines and gives background information about e-government business cases. It provides information on the necessary content, and gives a broad overview of some issues connected with the preparation of e‑government business cases.

E-government

E-government is about using technology to transform:

• the delivery of government services and information to users
• the way different parts of government work together and with others
• the way that people can engage with government.

A business case needs to demonstrate that it has taken into account:

• the e-government vision and milestones, defining the government’s intentions, directions and estimated timeframes
• the e-government strategy, that sets out the approach being taken across government to achieve transformation and how success will be evaluated.

See:

http://www.e.govt.nz/programme/vision.asp

http://www.e.govt.nz/programme/strategy.asp

What is a Business Case?

Business Case is defined as follows:

The business case presents a detailed explanation of the purpose and objectives for the project. It explains the approach and implications for the business along with the costs, benefits and risks associated with the project and the impacts on staff, the department and its clients.

The business case contains all the information necessary for Ministers to make a decision.

See also Section 3, page 26, of Guidelines for Managing and Monitoring Major IT Projects (http://www.ssc.govt.nz/it­guidelines).

E-government project

An e-government project uses ICT to assist the achievement of the e-government vision and strategy, as referred to in the overview to this section.

In this context, 'ICT' refers to information and communication technologies – the use of electronic devices and applications to convert, store, protect, process, transmit, share and retrieve information.

See http://www.e.govt.nz/resources/glossary/glossary-ij.html

Benefits from technology

The e-government business case proposes the delivery of benefits through the use of ICT. It covers individual and cross-agency initiatives and needs to adequately explore, identify and document any multi-agency (all-of-government) benefits, as well as benefits to the users of government.

Quality, not quantity

The business case should reflect quality rather than quantity in the material it presents. The aim is to be succinct while providing a complete and accurate picture. The reasons why specific items are included or excluded in a business case should make sense beyond meeting the needs of Central Agencies.

Logical, evidence-based, sound

A business case should be a logical, information-rich exposition at the minimum length necessary to present convincing evidence for the need to expend government resources such as:

• cash
• time
• incurring public discomfort.

The business case will be:

• sound
• comprehensive
• tailored to the location and risks of the project concerned.

The business case will demonstrate that the Crown, as owner, should invest in the project, providing a high degree of confidence in the delivery of what is proposed.

Timing of business case

Consider the timing of the presentation of the funding request. While out-of-cycle bids for funding are not prohibited, they are reserved for unusual circumstances when reasonable foresight could not have identified the issue and any related need for funds.

Sensitivity to the time issue should recognise the Budget process, including bilaterals.

Review the proposal

The developing/proposing agency should require an informed and considered review of the proposal. The extent of the review will vary according to the fiscal and/or strategic significance of the proposal. The review may be undertaken by:

• management
• an independent quality assessor
• Central Agencies.

Content of a Business Case

Introduction

This topic gives a broad view of the required content of an e-government business case. Detailed guidelines of the content are contained in Chapters 3 to 8 of this document.

What an e-government business case covers

An e-government business case covers the use of ICT by government, and will usually cover:

• electronic services and information initiatives undertaken by government agencies either individually or jointly
• infrastructure and standards for ICTs
• wherever reasonably possible, the reuse of government technology and electronic systems either by:
• sharing in construction and operation of back-office systems (the ‘create once, use many times’ approach)
• the joint operation of the client-facing aspect of electronic access systems.

Context

The context in which an e-government business case is presented is highly relevant. It should contain material appropriate for the various audiences that will review and make decisions, e.g.:

• the project manager - who will try to ensure all bases have been covered
• a member of line management - who will evaluate the case for submission to the next stage
• the agency Chief Executive - who decides whether to accept or reject the proposal
• Central Agencies - who will consider the all-of-government aspects and prepare recommendations to go with the funding request
• Cabinet/Ministers – who will be making the ultimate decisions about funding and about accepting risk.

Problem, outcome, governance and funding

The e-government business case should document the:

• reasoning behind the desire to undertake a programme, i.e. what is the problem to be solved or the opportunity to be grasped
• intended outcome of the programme, i.e. the basis upon which the later measurement of actual outcomes will be undertaken
• governance processes to be applied in the development phase
• the process for the future operation of the completed system
• funding mechanisms for the project itself and potentially, for ongoing funding needs.

Content

An e-government business case:

• Includes either plans or reference to the significant consultation effort that is required to ensure that the implications of the proposal for multiple agencies (or all-of-government) are clearly understood by all.
• Fits the various agency or sector strategies, and the government’s overall strategy, as well as fitting within the ICT Infrastructure for the agency, sector and government. ‘Infrastructure’ covers the subordinate and component parts of an ICT installation, undertaking or operation, e.g.:
• • hardware
  • software
  • protocols
  • communications
  • support
  • Disaster Recovery Plan (DRP)
  • Business Continuity Plan (BCP).
• Describes the benefits that will arise from the implementation of the proposal.
• Provides perspective (particular emphasis or comment) on areas likely to be significant to Central Agencies as they consider the proposal in the light of the government’s overall e-government strategy.
• Acknowledges relevant government requirements, e.g. the Ministry for the Environment-led initiative Govt3: Towards sustainable practice (http://www.mfe.govt.nz/issues/sustainable-industry/govt3/).

Business Case Development Process

Process

A business case goes through a development process. Depending on the size, complexity and inherent risk of the proposal, the process can be relatively minor.

If major policy development and/or funding is involved, the process can be significantly more formal, comprising for example, the stages set out in the table below.

These Guidelines can be used for any of these stages:

1. Initial assessment

A review by the agency’s own internal process, possible in consultation with Central Agencies. This review effectively establishes the need or desire to investigate the work proposed.

2. Bid for funds to research and prepare the full business case

The funding may be provided from:

• an agency’s internal baseline, or
• a specific source, e.g. the Growth and Innovation Fund, or
• a joint cross-agency pool.

3. Full business case

When the initial case is confirmed as viable and desirable, a formal business case is prepared for the funding body to assess. That body may be:

• a Board
• the Agency Chief Executive
• the Agency’s Responsible Minister, or
• Cabinet.

Note: The degree of Central Agencies’ involvement will depend on the proposal and how it is to be funded. Refer to the Guidelines for Managing and Monitoring Major IT Projects (http://www.ssc.govt.nz/itguidelines).

What a Business Case Must Provide

Introduction

A business case must clearly identify:

• who the case is written for, and

• what they are requested to do with it.

  See Chapter 3 for the suggested structure of a business case.

Questions a business case must answer

A business case must provide answers to the following questions:

• About the business case
• • What is the business case?
  • Why is it being proposed?
  • Why is it being proposed at this particular time?
  • What is the scope of the proposal?
  • Who is the business case owner?
  • Who is the business case sponsor?
  • What are the dependencies of the proposal?
  • What are the constraints of the proposal?
  • What background research has been undertaken?
  • How will success be identified?
  • What are the options?
  • What are the proposal confidence levels and sensitivities?
• About the costs and benefits
• • What investment is needed?
  • What benefits will be realised from the investment
• About governance
• • What governance process is to be applied?
  • How is funding to be obtained?
  • How does this proposal align with the e-government strategy and with an individual agency’s e-government programme?
  • What is the strategic framework under which the work/results will fall?
• About effects and implications
• • What are the downstream implications of the proposal?
  • What other related ‘e-’ systems are affected?
  • What are the identified significant legal issues? Include specific comment on legislative implications.
  • What other issues need to be identified, e.g. implications for privacy, Treaty of Waitangi?

Stakeholders

Introductions

The importance of gaining stakeholder involvement and commitment to the business case cannot be over-emphasised.

The stakeholder audience comprises those for whom the business case is prepared, i.e.:

• the agency(s)
• the users
• other participants.

Agency(s)

‘Agency(s)’ are those that develop and/or operate the proposal. It includes both decision and opinion-makers, i.e. those with an interest in the implemented process.

This group will have formal responsibilities which may include the views of other related agencies that may be involved either on the periphery or at a much closer level.

Users

‘Users’ or beneficiaries of the new/changed service includes:

• members of the public
• business users
• other special interest groups.

  The users may be:

• • direct
  • intermediary
  • interested lobby groups involved in undertaking the approved proposal.

Other participants

‘Other participants’ covers:

• review agencies
• any considerations arising from New Zealand’s place or role in the international environment
• the opinions of non-user special interest groups (lobby or pressure groups).

Benefits

Two kinds of benefits

As the business case is essentially a compilation of business decision support material, readers should be clear about benefits and distinguish the Rationale of the Business Case from Benefits of the Initiative.

Rationale of the business case

A Business Case should make sure that the stakeholders are left with a sound understanding of what is proposed, i.e.:

• why we need to do this, and
• why it is worth taking the risk.

All parties should have a clear, consistent understanding of what is to be achieved.

Benefits of the initiative

Benefits of the initiative as documented and evidenced in the business case, usually form two distinct groups:

• Benefits for the agency (or agencies) involved in the development and operation of the system. These may appear:
• • at a number of levels and for the mix of participating agencies, and
  • as part of a sector initiative. This emphasises the importance of alignment with sector goals and strategy, both national and regional.
• Benefits for the service consumers. These are predominantly but not always members of the public (be they individuals or businesses either individually or as a professional, business or community group, or other agencies or sectors).

Size, Complexity, and Context

Introduction

Every business case should make clear the size and complexity of the specific proposal, and explain the context in which the proposal is being made.

Size and Complexity

The size and complexity of the proposal will have a significant impact on the level of Risk attaching to the project.

The size and complexity of the proposal will also determine the amount of detail required for the Business Case.

Context

Context is a key factor that determines the approach to developing the business case. Context records the environment or situation in which the proposal operates. Context is not equated to Risk, although Risk is influenced by Context.

Risk

The recognition and mitigation of a Risk is heavily dependent on the context in which the particular Risk sits. The more major the Risk, measured in terms of probability of occurrence and consequence if the Risk eventuates, the more important it is to manage (mitigate) that Risk.

Depth of background information needed

The size, complexity and context of a business case determines the extent of detail and depth of the background information needed to support the business case as a basis for:

• project evaluation - formally carried out by the responsible agency management, allowing for proposal:
• • review
  • assessment, and
  • approval (or otherwise).
• doing the work
• observing progress - the Independent Quality Assurance function of project work.

Uncertainties in a Business Case

Uncertainty inherent

A business case contains inherent uncertainties. This is most evident in the areas of costs, benefits, and timing. Uncertainties exist irrespective of the funding basis for the project although the method of funding can contribute to them or mitigate them, for example cross- or multi-agency funding.

Uncertainties may impact:

• an agency’s clients
• an agency’s business
• other involved or related agencies’ business
• government as a whole.

Uncertainty is acknowledged in Risk assessments.

Record known uncertainties

To be an effective tool for decision support/making, the business case must record known uncertainties. It should provide:

• an indication of the scope that each uncertainty covers, e.g. by documenting the ‘spread of probability’ or the ‘degree of sensitivity’ that each item carries
• a range of possible mitigation options.

Simulation to show range of variability

The ranges of variability associated with financial information, for example cost, can be summarised and presented by the use of a simulation, e.g. Monte Carlo, which shows a range of values for each item.

Simulations can be applied to:

• benefits
• costs (material, labour, consultancy)
• time constraints (for any single key task or the project as a whole).

A simulation will show a range of possible results rather than showing a single value for any line item in the business case. This would at least extend from a 'credible worst case’ through a ‘most likely case’ to a ‘credible best case’, and include an indication of the relative probability for each of these cases.

See Chapter 5, Section 5.9, Funding, for further information about the Monte Carlo method.

See also http://www.riskglossary.com/articles/monte_carlo_method.htm.

Dangers of relying on simulation

There are two dangers inherent in relying on the outcome of a simulation:

• they do not address ‘people’ and ‘cultural’ issues, and
• if a cost variable (for example) is omitted entirely, a false positive confidence is generated in the absence of the missing information.

Section 2.2 - Extracts from Supporting Documents

Introduction

The topics in this section include extracts from specific items of interest that may be used to inform the preparation and presentation of an e‑government business case.

A Major IT Project

What is ‘in’ and what is ‘out’

When the proposal is considered to be “a major IT project”, additional checks and balances are required. Cabinet Office Circular CO (01) 4 sets out the relevant requirements.

Note: An expansion of how the following is approached by Central Agencies is contained in the publication Guidelines for Managing and Monitoring Major IT Projects, see http://www.ssc.govt.nz/ITguidelines.

Cabinet Office Circular (01) 4

The following is an extract from Cabinet Office Circular CO (01) 4, 10 April 2001 Monitoring Regime for Major Information Technology (IT) Projects:

"A major IT project is a new initiative, an ongoing development or acquisition project, an operational system, or other type of IT project (including studies against existing contracts) that meets any one or more of the following criteria:

• The project is not an existing operational system and its projected total life cycle costs are $15 million or more (GST inclusive). Cost included all equipment, software, contractor services, supplies, staff compensation and related staff costs, and inter/intra agency payments; or
• The project includes a projected IT capital investment totalling $7 million or more (GST inclusive) in any one year; or
• Failure to deliver the project in line with the projected functionality requirements, cost, and timelines, would expose the department to significant risk of impaired operational capability, or expose the Government to significant fiscal or ownership risk; or
• The project will impact significantly on more than one department or agency; or
• The responsible Minister has requested that the project be monitored."

The Role of the Central Agencies

Central Agencies

The Central Agencies are:

• Treasury
• State Services Commission
• Department of the Prime Minister and Cabinet.

Central Agencies have a variety of roles to perform, as set out in this section.

Readers are encouraged to make contact with their liaison points in these agencies to confirm the level of involvement required.

Concerns of Central Agencies

Agencies may have other general or specific requirements for reporting to their own Minister(s). They may also have obligations under various Acts or Regulations. As a general guide, Central Agencies are concerned with:

• ensuring that there is a fit between a proposed major IT initiative and the overall Government and departmental strategic directions and that Ministers can have confidence in the proposed investment
• project alignment with the e-government strategy
• the application of the monitoring role, to be met either by the direct involvement of the Central Agency or the appointment of Independent Quality Assurance (IQA) providers
• project context, including for example:
• • feasibility
  • funding
  • approval
  • governance
• project planning, including the provision of check points (or off-ramps) at key times in the project
• intended project management processes, for example:
• • Management of Risks and Issues
  • Privacy
  • Consultation.

Accountabilities of Agencies

Introduction

This topic gives a general indication of the accountabilities of the following agencies:

• Chief Executive of the responsible agency
• State Services Commission
• Treasury
• Department of the Prime Minister and Cabinet
• Office of the Controller and Auditor-General

Chief Executive of responsible agency

The Chief Executive of the responsible agency is accountable for:

• ensuring the business case is sound and the agency’s risk management, project management and monitoring structures follow best practice
• delivery of the project and associated benefits, as outlined in the business case, and
• ensuring processes are put in place to manage off-track projects, if this becomes necessary
• managing relationships with Chief Executives of other agencies.

State Services Commission

The State Services Commission acts on behalf of the Minister of State Services and is primarily concerned with ensuring that:

• a major IT project fits within the Government's direction and policy
• agencies have the capacity and capability to effectively manage and deliver the project on time and within budget, and
• ministerial confidence in the outcome is maintained.

Treasury

The Treasury has a direct interest in the investment to be made in a major IT project both in terms of the technology solution and all other associated project costs. It is concerned to ensure that:

• the overall interests of the Government in terms of fiscal accountability and responsibility are being met, and
• the anticipated benefits of major IT initiatives are realised.

Department of the Prime Minister and Cabinet

The Department of the Prime Minister and Cabinet has less of a day-to-day role in major IT projects. It is nevertheless concerned with ensuring that the interests of the Prime Minister and Cabinet are met.

The Cabinet Office Manual incorporates guidance for Ministers in respect of IT projects. From time to time, the Cabinet Office issues circulars containing directives of the Cabinet to departments.

Reference: http://www.dpmc.govt.nz/cabinet/manual/

Office of the Controller and Auditor-General

The Office of the Controller and Auditor-General, while not a Central Agency, has an interest in ensuring good practice is shared and adopted across the sector. It has published reports in relation to the management of IT projects in the public sector and on coordination and collaboration between agencies.

Reference: http://www.oag.govt.nz/2000/it-oversight/it-oversight.htm; http://www.oag.govt.nz/2003/key-success-factors/key-success.htm

Financial Delegations

Cabinet Office Circular (99) 7

Financial delegations for government agencies are documented in Cabinet Office Circular CO (99) 7.

Reference: http://www.dpmc.govt.nz/cabinet/circulars/co99/7.html

Delegations

In brief, the financial delegation limit for the purchase or development of departmental fixed assets and to operating leases for the use of fixed assets, if the assets are to be leased for more than a year, are as follows:

• Departmental Chief Executives: $7 million
• Responsible Ministers: $15 million

All proposed expenses or financial commitment that exceed a financial delegation limit require specific Ministerial or Cabinet authorisation.

Any subsequent variations to expenses or financial commitments also need specific authorisation, except variations for the purchase, development or lease of fixed assets that, in aggregate, do not exceed 10% of the value of the initial authorisation (and are within a certain dollar limit).

No financial commitments or expenses are to be incurred, project commenced or order placed unless delegated financial authority exists or has been specifically authorised by the Responsible Minister or Cabinet.

Capital projects must be supported by a business case and the agency’s strategic business plan.

[ Previous | Next ]