Chapter 5 - Supporting Schedules for Recommended Option

Introduction

The Supporting Schedules provide more detail of the reasoning related to various aspects of the Recommended Option, and where required, of other viable options to illustrate the basis for preferring the Recommended Option. It is the most voluminous section of the business case. This chapter outlines possible schedules that may be attached to business cases, depending on need.

Purpose of supporting schedules

The supporting schedules should give information sufficient that the audience of the business case may make informed decisions on the proposal, the risks, and the benefits. The analysis will be repeated for each option presented, albeit in varying levels of detail.

Gap analysis

It is appropriate for agencies to undertake a gap analysis to highlight what has been covered and to identify what needs further attention, for example:

• standards (be they SIGS, e-GIF, sector specific, general interoperability, Evidence of Identity and Authentication), or
• legislation (e.g. Public Records Act, covering archiving).

Reference: ISO 9001 2000 Gap Analysis Tool. See http://www.praxiom.com/iso-gap.htm

Section 5.1 – Implementation Issues

Introduction

The schedule of Implementation Issues provides a clear analysis of the consequential effects and change management issues for each option. The schedule shows how the option will impact on the agency’s current structure and operations, as well as impacts on other agencies and stakeholders. A Change Management Strategy may be required to address these issues.

What to include

The analysis should consider related ‘knock on effects’ within the agency, as well as effects on other involved state agencies and stakeholders, if appropriate. This analysis should:

• provide detail if the proposal involves the agency diversifying into new lines of business, or where there is a link between the proposed new business and current core business of the agency
• summarise how the tangible benefits of the proposal outweigh the costs and risks of diversification
• acknowledge the effects on the agency’s other significant systems (particularly if new technologies are to be introduced). This may take the form of an architectural assessment
• look wider than the specific proposal alone but should include appropriate reference to and assessment of the collective interest of the Crown
• identify and describe the likely impacts on key stakeholders.

Cover all options

Provide comment on the consequential effects of the proposal, covering:

• all the options proposed, and
• all consequential effects, ranging from in-house effects (on the lead agency) to wider all-of-government effects.

Note: This work could be combined with the section on Consultation (Section 5.10), the undertaking of which will clearly have an impact on the development of respective business cases.

Identify Effects

The proposal should identify the effects of undertaking the proposal on:

• existing agency processes
• clients, and
• staff.

Change Management Strategy

Change Management Strategy

The business case should describe the project or programme's links to the greater business, how change management will be resourced and managed, and provide an outline of the project or programme's major change management activities.

A Change Management Strategy should be developed to address these issues, and will need to cover:

• managing the process of change management
• creating the impetus for change
• supporting the organisation before, during and after the change.

Elements of a Change Management Strategy

A change management strategy requires a charter for the change team and a high level plan which sets out the time line and relationship to the project which is the subject of the Business Case.

A communications plan will address stakeholder interests, including the impact of the change on stakeholder cohorts.

Consideration needs to be given to who will manage change, and the role of the change manager in the project. The benefits of having an externally-sourced change manager should not be ignored.

Getting sponsor buy-in is critical, especially when the change affects the culture of the organisation.

The project budget must include provision for change management.

References

Successful IT: Modernising Government in Action; UK Cabinet Office Central IT Unit (CITU) 2000 – “Business cases must reflect all of the business change to be delivered” - http://www.e-envoy.gov.uk/reports-itprojects/$file/successful_it.pdf

Section 5.2 - Costs, Benefits, and Proposed Timeframes

Introduction

This section gives background information on costs, benefits, and timeframes outlining methodologies available to address them.

Further details can be found in sections 5.3 and 5.4 of this chapter.

Where to find guidance

Dealing with cost, benefits, and timeframes is complex. The following table explains where to find guidance on establishing credible information to support the business case assertions.

See this section 5.2 for guidance on:

• Background information
• Determining costs
• Determining benefits
• Benefit valuation methodology
• Cross agency benefits
• Range of project costs, benefits and timescales
• Benefit evaluation
• Range of project costs, benefits and timescales
• Benefit evaluation

See section 5.3 for guidance on:

• Cross agency benefits

See section 5.4 for guidance on:

• Range of project costs, benefits and timescales
• Benefit evaluation

Background Information

Importance of cost, benefits and timeframes

Any business case must have a section that sets out:

• what the proposal will cost
• what is expected in return, and
• how long the project will take.

While this section of the business case will be one of the hardest to prepare, it is the most important, as these three items are a major influence on the judgement made.

Information you must cover

You must clearly identify and demonstrate, to an appropriate level, the detailed information required to support the business case. For readability, it is likely that the information would be summarised in the body of the proposal. Sufficient detail to support the summary should be contained in appropriate appendices to the business case.

The following major concepts must be covered:

• The life of the investment
• The economic costs and benefits
• Cash flows
• Return to the Crown
• Implementation timeframe
• Any legal contractual relations.

Further details are given below.

Life of the investment

The nature and expected life of the investment should be covered. This includes the likely demand over the life of the asset. Note that the term ‘asset’ may mean the whole developed system.

The definition of ‘life’ needs to be adequately explained (i.e. technical, legal, economic etc.), as should the reasoning behind the particular selection made. Based on this definition, you should address:

• ‘business as usual’ support
• ownership, and
• cost of operation, e.g. who holds the depreciation funding etc.

Economic costs and benefits

Any rigorous analysis of the economic costs and benefits must include comment on social costs and benefits. The analysis must clearly outline the assumptions underlying all cost and benefit projections. For each option, the detail required should cover the following:

• the relevant tangible and non-tangible benefits and costs; the discount rate used and its derivation. Where productivity benefits are the essence of the proposal, this still requires analysis to demonstrate how the productivity change is:
• • quantified (in terms of actual financial improvement), and
  • to be realised (achieved)
• sensitivity analyses and relevant un-quantified risks associated with the proposal
• the basis for calculation including where possible, and/or appropriate, independent assessments of those calculations.

Cash flows

Include:

• the financial cash flows attributable to the project, and
• the financing options considered (e.g. sale of assets, cash accumulated from non-cash expenses).

This analysis should clearly outline the assumptions underlying all financial projections.

Return to the Crown

Include an assessment showing the Return to the Crown in terms of the net tangible benefits from reduced output prices, increased charge receipts or capital withdrawals.

Implementation timeframe

Include details of the timetable for implementing the proposal including:

• the post implementation review, and
• the ongoing operational, reporting and monitoring systems that will be established.

Effort needs to be applied to consider the future operational aspects of the development.

For details on the use of GANTT Charts see section 5.4.

Contractual relations

If legal contractual relations are envisaged, ensure these have been properly assessed and recorded. An example would be the choice of using Memoranda of Understanding or other formal legal agreements.

This can cover a variety of different legal risks, for example:

• liability
• service failure
• delivery, and
• audit/review.

Determining Costs

Introduction

Costs should be identified for all relevant aspects of the proposal. The analysis of costs should cover:

• Direct costs of the project.
• Any indirect costs incurred by the department itself, other departments and agencies of the Crown in adjusting their business operations, or the general public, including social costs.
• The basis for calculation, including any independent assessments of calculations.

The Treasury has developed a Cost Benefit Analysis Primer, which provides simple, accessible and practical assistance across a range of aspects of cost determination.

References:

http://www.treasury.govt.nz/costbenefitanalysis/

Accounting principles

All public sector entities are required to follow generally accepted accounting practice (GAAP). Binding advice is in Financial Reporting Standards such as FRS-3: Accounting for Property, Plant and Equipment. Binding advice on the interpretation of GAAP for the Crown and departments is provided in Treasury Instructions, which are published on Treasury's web site.

References:

http://www.treasury.govt.nz/instructions/

Technology costs

Technology developments typically comprise a mix of:

• Hardware acquisition.
• Software development or acquisition.
• Data conversion or capture.

There are separate costs for each of these items and each must be considered separately. An important issue is whether specific cost elements can be capitalised as an asset or must be accounted for as an operating cost that is expensed in the period in which the costs are incurred. This is important because the Government often sets separate limits for its expenditure on new capital items and operating costs.

Project costs

The project costs identified should cover:

• Direct costs for the personnel engaged on the project.
• Internal costs (such as for temporary assistance to provide support for permanent staff assigned to the project).
• Contingency, especially for cost categories which have a tendency to be underestimated such as:
• • User acceptance testing.
  • Equipment configurations.
  • Data migration.
  • Changed requirements for software development or package modifications.
  • Training, temporary staff to cover for people assigned to the project.
  • Documentation.

Indirect costs

The analysis should ensure that it covers all indirect costs that are relevant and material to the proposal, including monetary and non-monetary costs. It should also cover indirect costs that are incurred by:

• the agency undertaking the activity, e.g. changes in accommodation requirements or organisational restructuring
• other agencies that will be affected by the activity and its outcome, e.g. any requirement to adjust systems in order to interoperate or integrate activities
• users or other stakeholders, e.g. to meet new compliance requirements, charges, systems requirements, training.

Ongoing operating costs

Ongoing operating costs need to be identified:

• Decisions about sizing of the equipment that can only be taken after prototype or proof of concept phases have been completed.
• Budget process for:
• • Upgrades to equipment.
  • Software licenses.
• On-going maintenance costs for both hardware and software.

Assumptions

Outline of assumptions underlying all the cost projections.

Determining Benefits

Introduction

Benefit establishment can be at once the easiest and hardest task of the business case development. The ‘easy’ parts tend to be when the benefits are those that can be quickly and accurately quantified and are measurable in dollar terms. They tend towards certainty in amount, time and the sector (audience) that will receive/recognise them.

No special comment or guidance is provided in this document on establishing easily quantifiable benefits. General information is contained within the Treasury Publications and at the Project Management Institute.

References:

• http://www.treasury.govt.nz/publications/
• http://www.pmi.org.nz/

Benefit management plan

The biggest aid to applying the model of determined benefits is the correct establishment of the benefits in the original proposal. “Establishing” covers the identification of all benefits, tangible and intangible.

It is essential to have a plan that clearly shows how the various parties to the proposal will apply the results of the subsequent evaluation review(s). This may be titled a ‘benefit management plan’ and it would operate:

• over the life of the project, and
• subsequent to project closure.

Additional reading

The following additional reading may be useful:

• http://www.ssc.govt.nz/managing-for-outcomes, leads to a range of resources to help identify benefits and relate them to outcomes.

Example questions

In determining benefits for later evaluation, the following example questions may form a useful start point.

• What is the nature of the activity? Is it about providing information, or does it involve a transaction?
• To whom is the service to be delivered? Examples are:
• • another government agency
  • an intermediary, e.g. non-government organisation or commercial provider
  • an individual person – on their own behalf or on behalf of another (a proxy or agent),
  • business
  • another government.
• Is the intended result of the project/programme properly documented, and has appropriate training documentation been prepared/trialled/delivered/ applied?
• Is the service/system to be operated to pre-defined planned levels? If so, are their agreed performance standards.

Reference: http://www.goal-setting-guide.com/smart-goals.html

Note: It may be worth assessing other service performance criteria such as Quality, Quantity, Time, Cost, and Location.

Benefit Valuation Methodology

Cross-agency or non-financial benefits

The challenges appear when considering such factors as the recognition of cross-agency or non-financial benefits. There are many methods of assigning quantifiable values to such benefits.

The Value Measurement Methodology (VMM) provides an ability to include and assess a wide range of non-tangible benefits and it is this method that is recommended for use.

Recommended reading

Recommended reading includes:

• USA - Office of Management and Budget (OMB) – The Value Measurement Methodology (VMM), as developed by Booz Allen Hamilton, see http://www.whitehouse.gov/omb/
• UK – Office of Government Commerce – The Green Book (Appraisal and Evaluation in Central Government), see http://www.ogc.gov.uk/, and http://www.ogc.gov.uk/sdtoolkit/reference/ogc_library/related/geenbool03_pres.pdf
• Australian Federal Government – Australian Government Information Management Office (AGIMO) – The Demand and Value Assessment Methodology (May 2004), see http://www.agimo.gov.au/, and http://www.agimo.gov.au/government/damvam

Valuing Benefits - Value Measurement Methodology (VMM)

VMM

Booz Allen Hamilton, on contract to the USA Federal Government, developed a Value Measurement Methodology (VMM) in May 2003.

Reference: http://www.estrategy.gov/documents/measuring_finalreport.pdf;

“Building a Methodology for Measuring the Value of e-Services” Booz Allen Hamilton, USA Social Security Administration 2002.

VMM document page references that follow are from the above source.

Undertake VMM at appropriate level

The Value Measurement Methodology should be applied at a level that is appropriate to the project being proposed. It provides:

• a comprehensive structure;
• a series of estimation techniques to quantify all aspects of the project into common terms, and
• an integration methodology to allow these to be turned into a decision.

Six essential factors

VMM can provide a comparative ranking of options. It uses six Essential Factors, namely:

1. Direct Client Value
2. Social Value
3. Financial Value
4. Government Operational/Foundational Value
5. Strategic/Political Value
6. Risk.

An explanation of each is given below.

Direct Client Value

Direct Client Value is an assessment of end-user benefits arising from the proposal. The VMM approach requires this assessment be undertaken from the perspective of all of the intended user groups. For this purpose, Direct Client Value covers:

• Government to Client/Citizen (User Community)
• Government to Government (Inter~ or Intra~), and
• Government to Business.

Social Value

Social Value measures 'the benefit realised by individuals and organisations that are neither direct users of the service nor providers of the service'. Key aspects in determining social value can be considered as:

• improved trust in government, for example:
• • increased participation in the political process
  • enhanced transparency of government processes
  • greater government accountability.
• better services, for example:
• • access to services outside of traditional business hours
  • usage of the electronic delivery channels outside of traditional business hours
  • lowered cost of doing business for private sector.

Reference: VMM document, p.14.

Financial Value

Financial Value or “government financial value”, comprises the key aspects that determine value in accounting terms, for example:

• cost per step:
• • central implementation costs
  • agency implementation costs
  • central operating costs, and
  • agency operating costs
• lower cost of materials:
• • infrastructure items
  • development costs
  • staff salaries
  • hosting
• reduced workloads:
• • across government
  • technical
  • support/communications/operations/data
• shared infrastructure, at agency and across government levels
• duplication of costs avoided across government e.g.:
• • maintenance
  • operating
  • capital investment.

Reference: VMM document , p.15.

Government Operational/Foundational Value

Government Operational/Foundational Value is an assessment of “the order of magnitude improvement that may be achieved in both current services (operational) and in preparation for future demand (foundational)” The key aspects are considered to be that:

• data accuracy is enhanced, is cleaner (less error prone), and entry is timely
• the process:
• • is streamlined
  • uses on-time processing
  • has availability, redundancy, system reliability, and flexibility.

Reference: VMM document, p.16.

Strategic/Political Value

Strategic/Political Value is an assessment that:

• looks beyond the initiative itself, and
• gauges the ability of the proposal to move the agency (and government as a whole) towards achieving the agency/government mission.

Such an assessment presupposes the agency has a strategic and performance plan linked to government goals and priorities in a manner that avoids platitudes. The assessment should be:

• User - (rather than bureaucracy) centred
• result - (not process) oriented, and
• promoting of market-based innovation and competition.

Reference: VMM document, p.17.

Risk

Risk (in the context of VMM) is an assessment of the potential causes of project/proposal failure. Risk is assessed at proposal definition including allowance for appropriate mitigation factors.

Later, the traditional assessment of potential risk (probability * impact for items such as Project, Organisational and Technical Risks) should demonstrate the agency level of risk tolerance.

Reference: VMM document, p.18.

VMM in a New Zealand government context

Introduction

The general arrangement of the VMM matrix has the capacity to become a comprehensive listing appropriate for supporting a business case.

Example adapted for New Zealand

The following table is an example of how the VMM matrix could be used in a New Zealand government context. While the broad format (both horizontally and vertically) remains the same as the original, the categories have been amended to:

• include the appropriate essential factors, and
• allow the inclusion of the aspects of projects most prone to be overlooked.

Note: the content of the matrix is a series of ‘typical entries’ that should be appraised and their inclusion specifically reassessed for each project.

Reference: VMM document, p.19-21.

Table

The following table gives an assessment matrix showing factors against relationships/objectives.

Essential factors:	Government to community(G2C)	Government to government(G2G)	Government to business(G2B)	Internal efficiency and effectiveness
Direct client value:(realised by users)	Value of time saved	Government user savings	Customer time saved Lower regulatory costs	Value of time saved Reduced complaints
	Common facets: Take up rates Contingent valuation Customer satisfaction Queuing Effects
Social value:(non-market – indirect value)	improved trust in government better service (e.g. outside working hours)	improved information sharing	better processes lower costs able to operate outside working hours	enhanced transparency better accountability
Financial value:(fiscal impact – as shown in Votes and budgets)	cost per step lower cost of materials	reduced workloads shared infrastructure	reduced facility costs	duplication costs (maintenance, operations, capital) avoided
Foundation value:(System benefits now and in future from quantum leap in performance and as platform)	data accuracy enhanced data cleaner (unduplicated) data entry timely	process streamlined on-time processing	availability redundancy	system reliability flexibility
Strategic/political value(Movement of whole of government toward aims)	community awareness publicity	fulfils legislative requirements	partnership prospects heightened	achievement of government goals
Risk(potential direct causes of failure)	success ratio (probability)	key project risks (cancellation, scope creep, schedule failure, program management, political failure, legal)	key organisational risks (process / operational alignment, utilisation / demand, impact on other channels)	key technical risks (feasibility, obsolescence, vendor, architectural dependencies, integration complexity, security)

Example of VMM Applied

Interpret appropriately

The structure and content of the above table can be expanded and appropriately interpreted to cope with the issues particular to the individual proposal - complex or simple.

The agency must address the serious questions behind the proposal, for example: How do the costs/benefits fall on users/citizens?

Example

The following table demonstrates the final results of such an evaluation used to support option two in a four-option business case.

The comparative basis applied was that:

• Positive values = more value than base case
• Null value = similar value as base case
• Negative values = less value than base case

	OPTION
Summary of VMM Factor	One	Two	Three	Four
Direct Client Value: G2C and/or G2B	4	5	4	1
Direct Client Value: G2G	-4	0	-6	1
Direct Client Value: Internal Efficiencies	8	8	4	1
Direct Client Value: Total	8	13	2	3
Social Value:	4	5	3	1
Foundation Value:	14	16	7	5
Strategic/Political Value:	14	17	13	7
Financial Value:	0	8	-2	1

Weighting Issues for VMM

Relative weightings

How the ‘six essential factor’ categories of the VMM are aggregated involves assigning relative priorities, or weightings, to each of the factors. If the factors are merely added, i.e. each factor is given the same weight, this is equivalent to an equal weighting schema.

A single option may be a clear winner

When the weighting is complete and the results summarised, sometimes a single option (of the three, at least, that are presented in the proposal) will be the clear winner in every category. Depending on how significant is the degree of separation of the leading option from the offered alternatives, it may be inferred that it would take a massively disproportionate weight to be assigned to one or more of the factors to change the result. A sizeable additional weight would be necessary to gain a change in the recommended option. Such a heavy weight change would be improbable. In such a case, further close consideration would only be required for those individual factors in which the particular option did not dominate.

Establish relative weightings

A single option may not be a clear winner in every category. Normally, it will only be possible to establish relative factor weightings. One straightforward option is to talk with stakeholders about the priorities to identify those factors they consider have a high prominence. It is usually sufficient that this be done at a level of generality using generic concepts like ‘priority’ rather than by determining a set of numerical values.

Section 5.3 - Cross-Agency Benefits

Introduction

This section gives details of some approaches to assessing and weighting factors when dealing with a proposal that provides benefits across agencies. Agencies need to decide whether these approaches would be useful for their particular proposal.

Cross-Agency Benefits - General Comments

Two basic scenarios

There is no simple way to establish and then evaluate the benefits associated with an e-government project when they may appear in multiple agencies. There are two basic scenarios:

• a limited cross-agency affect, or
• a significant number of agencies affected by the proposal

Limited cross-agency

For a limited cross-agency affect, the recommended method is to:

• identify the agencies involved and ask them to assess both the costs and benefits as they see them. Incorporate this into the business case, and
• perform a ‘standard’ consolidation to achieve whole-of-programme information.

Significant number of agencies

When a significant number of agencies are affected by the proposal there are three basic stages in the process to extrapolate costs, benefits, and timeframes. These are:

• weighting relative importance
• establishing the range of cost/benefits, and
• achieving total cross-agency cost/benefits.

Details are given in the topics that follow.

Weighting Relative Importance

Tasks

The tasks below outline a suggested approach to weighting relative importance when a significant number of agencies are affected by the proposal.

In the context of this proposal …

Task 1

Identify the agencies involved or obtain a list of all government agencies. Include Local Government organisations as appropriate.

Reference: http://www.ssc.govt.nz/state-sector-organisations

Task 2

Establish a relative size for each agency identified. The grouping could be in the following five general categories:

Very Large – Large – Medium – Small – Very Small

Sizing should be based on the impact on the individual agency of the task to be performed. The sizing criteria will depend on the tasks required and their effect on the individual agencies (no ranking of importance is implied). Estimations are acceptable. Suggestions for a basis for assigning ‘size’ include:

• number of staff, in total, or that may be affected by the change
• number of physical locations, in total, or that may be affected by the change
• size of Vote, in total or that may be affected by the change
• number of ‘e’ or manual systems or services currently offered or planned to be offered
• the existence (or otherwise) of related systems to be affected

Task 3

Weight the criteria for relative importance of the agency to the proposal.

Result

Applying a ranking process should produce a table listing the number of agencies in each size grouping affected by the proposal. It may also be relevant to consider ordering the table by agency type in order to identify any commonalities that might affect consideration of the proposal,

e.g.

• Public Service departments
• local authorities
• district health boards.

Establishing Range

Establish representative range

In consultation with at least one agency from each size group, establish a representative range of cost and benefit values i.e. numbers that indicate Highest – Most Likely – Least cost/benefit.

Obtaining a range of values is important. This information will be used later for simulation and sensitivity analysis. If confidence in these values is limited, interview additional agencies from the size grouping to increase the sample size and therefore confidence.

Extrapolate to achieve range

Extrapolate the interviewed agency’s (or agencies’) range of values (costs/benefits) across the number of all participating agencies (taking account of the weighting) to achieve ranges of amounts totalling the cumulative effect on ‘all’ agencies.

The result table may look like this:

Agency size	Number of agencies in group	Range of costs - $High – Most Likely - Least	Range of benefits - $High – Most Likely - Least
Very Large	3	$x - $y - $z	$x - $y - $z
Large	6	$x - $y - $z	$x - $y - $z
Medium	14	$x - $y - $z	$x - $y - $z
Small	16	$x - $y - $z	$x - $y - $z
Very Small	8	$x - $y - $z	$x - $y - $z

Achieving total cost/benefits

The resulting values can them be further extrapolated. To achieve a total cost/benefit of the proposal, multiply by:

• the number of affected agencies in the group (for each range), and
• a weighting factor, to allow for the significance of the proposal compared to the size of agency.

For the above example, the extrapolation would be as follows:

TOTAL

47

$sum(x) - $sum(y) - $sum(z)

$sum(x) - $sum(y) - $sum(z)

The simulation and sensitivity analysis is applied to this information.

Section 5.4 - Range of Costs, Benefits, Timeframes

Establishing value

This document does not demonstrate how to quantify financial costs or benefits for a business case. It is expected that a spreadsheet system or something similar will be used.

Reference: For detailed discussion on various methods of establishing value, see http://www.treasury.govt.nz/costbenefitanalysis/default.asp

Show range, not single value

Presenting a single value for each benefit, cost and time is inappropriate as a basis for a business case decision. This is because the impact from a single variation to any number in the process has not been considered in relationship to other numbers established for the process. It is more appropriate to identify and present a range of possible/probable dollar numbers (or date values) against which degrees of confidence can be recorded.

Valuing public services

The assignment of ‘Value’ is not related to the special nature and complexity of IT proposals. It is a reflection of the complex nature of valuing public services as are delivered by e-government. There are several aspects, specifically IT related, that can be assisted by a particular approach such as the VMM. It helps to provide:

• a comprehensive framework, to ensure that all aspects of the issues are covered, and
• an agreed estimation/valuation process, including respective weights, to approach and measure the areas in which the proposal will have an effect.

The assessment of benefit from a specific e-government proposal is just another type of public sector cost/benefit analysis. Its high-level structure is similar to generic examples elsewhere. The devil is clearly in the detail of the valuation. This needs to be carefully thought out and reflect the issues involved in the particular proposal.

Simulation and Sensitivity Analysis

Introduction

When you have obtained a range of values for the costs and benefits, undertake a simulation and sensitivity analysis on the data.

Example

The example below looks at costs only (ranges and sensitivities). It could equally be applied to benefits or timeframe calculations. It is based on an Excel spreadsheet approach using the @Risk add-in software – other options to achieve a similar analysis are equally valid.

The example is simplistic. It is highly recommended that those wishing to apply this software undertake training and develop test spreadsheets to confirm principles before undertaking a full scale analysis.

Reference: http://www.palisade.com.au/

Procedure

Follow these steps to carry out a simulation and sensitivity analysis.

Note: This is not a fully worked sample – readers will still need good familiarity with both Excel and @Risk to apply the process.

Step 1

Identify and list all costs (and benefits and timeframes) associated with the proposal. For each line item, capture the Lowest, Most Likely, Highest value and the probability for each value.

The probability may be the same or may vary for each line item.

Examples are:

• a simple maximum and minimum
• a uniform probability
• a triangular 3-point distribution, or
• be based on more complex calculations.

Note: The @Risk software package includes some 37 options to analyse probability – ranging from the esoteric (Pearson Type VI) to the routine (Normal) distributions.

Step 2

Enter the appropriate @Risk function based on the decision made above.

Step 3

• Summarise the cost (benefit, time) with usual appropriate Excel Sum() functions.
• Add an @Risk Output function to nominate the final value that is required for the calculation

Step 4

Use the @Risk control panel to set the sampling type (Monte Carlo) and the number of iterations that are to be performed.

See: Section 5.5, Funding, for details of the Monte Carlo Method.

Step 5

Run the analysis.

Step 6

• Review the results, both cost distributions and sensitivity report, and
• Understand what is being reported.

Step 7

Include graphs and comments as appropriate in the business case to support the information being provided from @Risk, as it relates to the proposal.

Results

The following two charts show the results of the above process for a test project.

What the charts tell you

The above charts tell you:

• the range or distribution of possible costs with probability markers at 5% and 95% confidence levels, i.e. you are:
• • 95% sure it will cost more than $861,900, and
  • 95% sure the cost will be less than $960,800, and
  • sure the mean (expected) cost of the project is $913,202.
• the sensitivities for this project showing the things most likely (if they have a problem) to cause delays to the project. For example, the ripple effect of problems with the recruitment of the project manager has a 40.8% probability of being a delaying factor.

Timeframe - GANTT Charts

Introduction

The business case should include a GANTT chart as a high level representation of the planning and coordination tasks that are associated with each option.

GANTT charts:
developed in 1917 as a production tool by Henry L. Gantt, an American engineer and social scientist.

The presentation may be:

• a summary of a complex chart, perhaps developed in Excel or Project and rolled-up, or
• from a more simplistic Draw application.

What is required

A GANTT charts shows:

• the order of events
• the approximate times required, and
• the relationships between them.

Whatever tool is used, sufficient information should be shown to leave the readers with a clear understanding of:

• the relationships, in particular, dependencies, between key events in the proposal, and
• the key milestones and decision points that are involved.

Chart contents

At the high level and whatever format is chosen, the chart should either show, or have as ancillary text, information on:

• milestones (hand-off points)
• resources required for the task
• deliverables.

Example chart

Download the pdf, for an indicative sample (page 73), taken from a January 2004 Business Case for the then next stage of the development of an All-of-government Online Authentication proposal. The example demonstrates a ‘rolled up’ chart indicating there are levels of detail for these base tasks.

Dates

Note: The @Risk function can be applied to dates where there are possible variations to start and end dates due to dependencies.

These can then be analysed to:

• achieve confidence in predicted end dates, and
• identify the sensitivities around specific tasks.

Benefit Realisation

Identify benefits

Benefits realisation requires identification of what the benefits are and how they will be achieved, as well as how they contribute to the strategic goals of the organisation and to government outcomes. In the case of an e-government activity, the benefits could rest with the agency undertaking the project, the users of the service involved, or other agencies. The proposal must provide clear identification of resulting benefits, covering:

• where and how they arise, and
• how they will be recognised.

The proposal should provide information at:

• the evaluation level, i.e. a summary and comparisons between options
• the financial level, i.e. the costs vs. benefits numbers game, and
• any other ‘soft’ or non-quantifiable benefits.

What to consider and document

The following should be considered and documented:

• The agencies and users involved: those participating in the development and/or operation of the proposed system and those agencies affected during its operation, even though they may not form a part in that operation. This includes agencies in the public sector, for both individual agencies and cross-agency effects, private sector, and the general public.
• The period: over which the benefits are to appear.
• The location: of those benefits, if this is relevant to the proposal.
• The measurements metrics: as are to be applied in assessing the achievement of the stated benefits, e.g.
• • financial
  • social
  • political (for both outcomes and outputs), and
  • other, which should be specified.

Three levels of evaluation

Evaluation of the proposed benefits should be undertaken at three levels:

• the project
• the programme in which the project fits, and
• the strategy of the agency, the e-government strategy, and government outcomes.

Assessment at a project level

The proposal should identify the process by which goal achievement will be assessed. This is to be undertaken when the project is complete. To aid in ongoing go/no go decisions, an assessment process during the project could also be considered, dependent on project specific factors, e.g.:

• project length of time
• complexity,
• off-ramp timing (see ‘Early exit strategy’ section 5.11).

Evaluators

To undertake the evaluation, it is recommended that a mix of in-house and external evaluators be identified and engaged. The cost of this evaluation process is a cost to be identified in the proposal, in a section titled ‘Post-Implementation Review (PIR)’.

Reference: http://www.epmbook.com/pir.htm

Note: It may be appropriate to recognise at the proposal stage, that the timeframe for the achievement of some benefits may defeat such analysis.

Scale of project evaluation

The actual mix, time scale, and breadth of the evaluation process will depend on the scale of the project. A sensible approach should be applied to how much time and funds are spent on the benefits evaluation programme. In planning for, and then performing the PIR, the following criteria are considered essential:

• Benefits to be appraised should be considered based on a weighting of the relative importance of the specific benefit. Not all benefits are equal.
• The evaluation system proposed in the business case, either during development or when the project is complete, should be undertaken using a ‘no fault’ approach. In assessing benefits, inevitably there will be the view that things could have been done better. Such results should be accepted, and actively sought. This encourages the identification of things that:
• • are ‘not the optimal approach’, or just wrong, and
  • now have the chance of being done better ‘next time'.

Assessment at programme or strategy levels

Benefits realisation is more than evaluation of how well the project delivered the expected benefits, it is also about realising benefits across a programme or in achievement of broader goals through a portfolio of investments.

The Business Case should identify how the benefits will contribute to business goals and how success will be evaluated.

Section 5.5 - Funding

Single value

When a range of values for the business case has been achieved, there is still a need for a single value/date for Vote allocation or Treasury agreement purposes. On the question of choice of vehicle to provide funding and the timing for the funding, this section provides references to Treasury resources.

Single Value for Funding

Example

Establishing a single value (necessary for a funding proposal) is addressed as shown in the following project cost example, assuming the proposal has been approved to proceed. Funding is:

• released immediately (consistent with the draw down requirements) to the 15th percentile
• appropriated to the 50th percentile (the expected [most probable] cost), recorded in the accounts to this amount, and made available on Joint Ministers approval
• made available to the 85th percentile on Cabinet approval.

Outcome example

Download the pdf to see an example (page 77) illustrating the outcome of this approach.

The Monte Carlo Simulation Method

Introduction

The extent of the range of costs/times for the proposal is established by using simulations, e.g. Monte Carlo style. The Monte Carlo method is one of a variety of ways of achieving this information and the choice of method should depend on the project requirements.

What is the Monte Carlo method?

The method is outlined in the following extract from: http://www.riskglossary.com/link/monte_carlo_method.htm

“The Monte Carlo method, as it is understood today, encompasses any technique of statistical sampling employed to approximate solutions to quantitative problems … (which) transformed statistical sampling from a mathematical curiosity to a formal methodology applicable to a wide variety of problems. It was (Nicholas) Metropolis who named the new methodology after the casinos of Monte Carlo.”

Approximate solutions

Approximate solutions, (i.e. amounts or times, e.g. worst case, most likely case, best case) are recorded for individual line items in the cost (benefit, time) calculations, together with probabilities for each solution. Analysis software is used to establish:

• the boundaries for the curve, as demonstrated in the diagram in the previous topic, Single Value for Funding, and
• the confidence that can be placed on any point on the curve.

Software to use

Depending on the scale of the proposal, there is a requirement to at least model the proposal, providing confidence in, and a sensitivity analysis of, costs, benefits, and the timescale.

You should use @Risk software, or something similar, for the above purpose. @Risk is an Add-in that runs with Microsoft Excel or Project.

Where to find software:

• The @Risk software is an Excel add-in, developed by Palisade (see http://www.palisade.com.au/) and provided/supported in New Zealand by Hoare Research Software Ltd (see http://www.hrs.co.nz/).
• Another software product is Crystal Ball as provided by Decisioneering Inc (see http://www.decisioneering.com/crystal_ball/). This is provided / supported in New Zealand by Hearne Scientific Software (see http://www.hearne.co.nz/).

Supporting publications

There are other useful Treasury publications to assist in developing the cost schedule for the proposal, in particular the ‘Cost Benefit Analysis Primer’.

References:

• http://www.treasury.govt.nz/costbenefitanalysis/
• http://www.treasury.govt.nz/publications

Areas to include

Particular consideration should be given to at least the following areas of expenditure. Ensure they are present and that the rationale supporting particular decisions about the treatment of each line item is recorded.

• Capital: Distinguishing one-off (set up/construction) and ongoing operation funds including for example future refreshes and upgrades.
• Financial Costs: Cost of capital, GST, Depreciation.
• Calculations: Net Present Value (NPV) calculation. See also Discounted Cash Flow (DCF), justifying both the percentage used and the period over which the calculation is being made.
• Distinguish development (lead) agency, operational agency and other (implementing/adopting) agency costs.
• Other essential related costs, e.g. Disaster Recovery and Business Continuity plans and systems, including proper plans for really trialling such plans.

Contingency

A major potential problem arising from placing reliance on simulations is that the analysis, including the sensitivity analysis, is undertaken only on those items included in the cost (or benefit) list. The simulation cannot make allowance for items omitted entirely, i.e. forgotten and not present in the analysis at all.

For this reason, even though the analysis will show a range of numbers, there needs to be a “contingency” line to provide cover against those things that may have been missed. In this case, the contingency is not for variation in the cost of a line item, but as a hedge for a cost line or time being omitted entirely from the analysis.

Timing and Choice of Funding Vehicles

Introduction

Careful consideration needs to be given to timing and choice of funding vehicles. In large part these will be subject to existing rules and guidelines.

Treasury publications and Cabinet Circulars

Agencies should review and take note of appropriate Treasury publications and Cabinet Circulars which provide advice on a number of topics such as:

• The budget process:
• • how to get involved
  • what to do, and
  • by when, a general timeframe guide. This includes what is needed for the bi-lateral process, and how to deal with Multi-Year requests for Appropriation.
• The process for ‘Out of budget cycle’ bids for funds. How to get involved, what to do and by when - a general timeframe guide.
• Funding alternatives, e.g.:
• • Central (Vote:)
  • from Baseline
  • by the use of depreciation funds
  • third party (user pays), or
  • partnership with private business

References:

• http://www.treasury.govt.nz/instructions/
• http://www.treasury.govt.nz/budgets/process/
• http://www.treasury.govt.nz/publicsector/charges/
• http://www.dpmc.govt.nz/cabinet/manual/
• http://www.dpmc.govt.nz/cabinet/circulars/index.html

Section 5.6 - Issues, Risks and Available Mitigations

Introduction

This section gives general information about dealing with Issues, Risks and Mitigations. It also provides examples of approaches you could consider using.

Definitions

It is essential to distinguish Issues from Risks.

An Issue is an event that has happened, with (perhaps) uncertainty as to impact. An assessment of the result is made and presented.

A Risk is an event, uncertain as to time and/or impact. An assessment of these two factors is made and presented.

Reference: Standards New Zealand – see http://www.standards.co.nz/

Display relative importance

The text (and possibly a visual representation of the items), should be sufficient to briefly and accurately describe the key Risks/Issues and display them in a way that demonstrates their relative importance.

Risk Management is a complex business. Agencies may wish to consider using a Risk professional to undertake or assist with the identification, assessment, and quantification process.

To assist decision-making

A clear understanding of the challenges and opportunities associated with the recommended option will assist informed decision-making. Materiality is fundamental to this approach. A risk-sensitivity analysis may be appropriate to support the process.

Resources

Available resources

Resources for understanding issues and risks are listed below.

• Standards e.g. AS/NZS 4360:2004 (Australian/New Zealand Standard available from Standards New Zealand). http://www.standards.co.nz/default.htm
  Note: There may be a charge.
• Government Communications Security Bureau (GCSB) http://www.gcsb.govt.nz/
• NZ Security of Information Technology Publications http://www.gcsb.govt.nz/publications/nzsit/index.html
• Security in the Government Sector (SIGS) http://www.security.govt.nz/
• National Institute of Standards and Technology (NIST) http://csrc.nist.gov/publications/nistpubs/ search for 800-18

Other types of risk

There are many other types of risks that need consideration including, for example, political risk.

Issues

Recording issues

The Proposal should record significant Issues identifying:

• what (has happened)
• how (events leading up to)
• who (did it, reported it, is affected)
• why (any indications of cause)
• when (timing)
• ‘so what’ (effect on the task) and
• what can be done now to manage the impact of the Issue.

Risk Analysis and Reporting

Introduction

The stakeholders need to understand the recognition given to Risks as well as the mitigation action(s) planned to deal with them. This topic outlines what must be covered, and recommends a process to follow.

Identification and reporting

Risk identification, assessment, analysis and reporting should be at a high level, providing identification of the most important and most probable Risks. It should record ‘what is to be done about this’ to a level that is appropriate to the project. You should:

• identify and record significant Risks as well as possible Mitigations
• assign values (probability and impact) leading to an overall Risk rating
• report the result in the business case.

Significant Risks

Ensure you have identified and quantified all significant Risks, e.g.

• regulatory
• legislative
• implementation
• funding commitment
• contracting
• organisational or sector capability (to develop a new system while continuing existing operations)
• maintaining collective interest and participation (collaboration and interoperability)
• assumption accuracy and completeness
• partial completion
• proposal flexibility
• risks to other agencies

Unquantifiable Risks

Acknowledge any unquantifiable Risks in the business case.

Realistic mitigations

Ensure that mitigations are realistic, e.g.

• management process
• appropriate delivery and initiative checkpoints are identified
• backup/fall back planning
• how change will be effected and maintained
• have barriers to change been identified and managed?

Tasks

To identify and report on Risks and Issues, carry out these tasks.

1. Identify potential Risks and actual Issues, both internal and external to the agency. A Risk Workshop can be a useful tool to achieve this.
2. Record characteristics for all facets of the proposal, particularly addressing those associated with:

• the proposal design
• implementation, and
• undertaking an ex-post review.

3. Construct a risk/issue management and risk mitigation strategy, at a level appropriate to the specific proposal, addressing:

• the process to be applied to identify, analyse and respond to Risks related to the proposal, and
• the project management framework and monitoring mechanisms.

Note: Preparing a risk sensitivity analysis may assist this process.

Ongoing operation plans

Based on the completion of the above tasks, the business case will acknowledge the need to prepare ongoing plans for the management of the day-to-day operation of the systems resulting from the proposal. These plans for future operations will include consideration of, for example:· future system refreshes and upgrades· management and related communications risks.

Risk Levels and Risk Categories

Introduction

This topic provides an example of the values that could be used to determine risks.

Risk levels

The tables below outline the components of risk levels.

Likelihood

Guidelines for assessing risk likelihood are as follows:

1. Rare – less that 10% probability of happening
2. Unlikely – more than 10%, but less than 30% probability
3. Moderate – more than 30%, but less than 60% probability
4. Likely – more than 60% but less than 90% probability
5. Almost certain – more than 90% probability

Probability (Likelihood)	Range
Rare	1
Unlikely	2
Possible	3
Likely	4
Almost Certain	5

Impact

Each issue or risk is assessed on the impact or consequence it could have on the activity. The impact is assessed using two quantifiable criteria: schedule (time) and financial (cost), and one non-quantifiable criterion: quality. The ‘quality’ criterion is intended to cover all non quantifiable impacts including reputation, goodwill, confidence and capability to meet objectives.

There are five ratings under each of these criteria: Catastrophic, Major, Moderate, Minor and Insignificant.

Note: If an impact can realistically be assessed under multiple criteria, then choose the highest rating out of all categories.

Impact (Consequence)	Range
Insignificant	1
Minor	2
Moderate	4
Major	7
Catastrophic	10

Risk categories

Risk categories cover levels, types, and options. Examples of each are given below.

Location

Risks can be found within the:

• Policy
• Programme
• Project

Types

Examples of Risk types are:

• Policy
• Legal
• Legislative Compliance, including Public Records Act
• Political
• Strategy
• Approvals and funding (include specific as may be related to possible multi-year appropriation or source of funds, e.g. third party, fee etc)
• Technology
• Security Related (including system compromise, breakdown, lack of ability to change, technology redundancy, vendor/technology tie-in)
• Privacy
• Offshore
• Accuracy of assumptions
• Reputation
• Scope
• Project Management
• Human Resources
• Contracting and vendor non-performance
• Project Completion
• Budget
• Change Management
• User Uptake and demand
• Implementation and operational
• Risks to other agencies
• Other (External - Economic, Environment)
• Other (Internal)

Options

The business case should employ minimum text necessary to describe the key Risks/Issues and to note the proposed action for the major impact items such as:

• manage (mitigate)
• transfer (insure), or
• accept (‘be aware of and do it anyway’).

Presenting composite Risk value

For each Risk/Issue, the rationale behind the choice of level and category value should be explained in a separate schedule or appendix.

Risks/Issues should also be considered in terms of time, cost, and benefits impact when establishing the composite Risk value. The trigger events that imply why and when the named Risk may occur should be identified, as should interdependencies between Risks/Issues within the project, including consideration of any external influences.

The result should be summarised in tabular form.

Risk Response Type

The responses to the risks identified can include:

• Avoid the risk (not proceeding with the activity that gives rise to the risk)
• Reduce the likelihood of the risk event occurring (develop new controls)
• Reduce consequences of risk (introduce contingency plans)
• Sharing or transferring risk (contracts, insurance)
• Retain the risk (manage residual or secondary risks)
• Ignore the risk

Regular re-evaluation of Risks

The governance arrangements for the implementation of the proposal should establish a rolling-review regime requiring the Risks and Mitigations to be re-evaluated at regular intervals (say six-monthly, depending on the business case context). This review would reassess the identified Risks and their mitigations for potential changes as well as looking for ‘new’ Risks/Issues.

Overall Risk/Issue Classification and Presentation

Introduction

The following Risk matrix helps to display the key risks. The matrix is followed by a schedule, providing more detail such as:

• Risk Reference number
• Name of Risk
• Impact
• Probability
• Mitigation.

The matrix and list should reflect the Project Risk Management Register.

Producing a matrix

To produce a matrix such as the one illustrated on page 89 of the pdf:

1. Calculate the resulting Risk value (impact*probability) in a table.

2. Sort the table by value of result.

3. Enter the Risk Reference number in the appropriate cell of the matrix.

While it is recommended that the matrix display the top 10 risks, this must be viewed on a case-by-case basis. Any risk that results in value greater or equal to the Red or Yellow quadrant must be shown in the list and the diagram.

Risk Table:

Reference number	Name of Risk	Impact	Probability	Mitigation Counter measures
1	Technology does not work	Catastrophic	Unlikely	Research
2	Supplier defaults	Major	Rare	Source alternative suppliers
3	Etc	Etc	Etc	Etc
4	Etc	Etc	Etc	Etc

The following indicates the requirement to take action, based on the analysis:

Very High

Urgent action is required / is underway – mitigation strategy is documented and plans prepared, delivered to and approved by Senior Management. Action plans are being applied.

High Risk

Action likely to be required – mitigation strategy is documented and plans prepared, delivered to Senior Management, awaiting approval for action.

Moderate Risk

Possibility of action being required – mitigation strategy is documented and first stage plans prepared, delivered to Senior Management for consideration.

Low Risk

No immediate action required – mitigation strategy is prepared, Senior Management advised, close watching brief maintained.

Resources

• Guidelines for Managing and Monitoring IT Projects http://www.ssc.govt.nz/Itguidelines, Risk Management Strategy section
• Australian New Zealand Risk Management Standard AS/NZS 4360:2004
• Australian New Zealand Risk Management Guidelines, Companion to AS/NZS 4360:2004
• Project and Programme Risk Management, R Max Wideman, Editor [this is one of the Risk Management texts recommended by PMI].

Section 5.7 - Privacy

When privacy must be considered

Privacy must be considered when e-government systems involve the gathering, storage, manipulation or transmission of user information.

Note: A Preliminary Privacy Impact Assessment may have been prepared prior to this business case, providing information on what will be needed should the proposal go ahead.

PIA tool

The business case must assess privacy issues where they arise, and record the extent to which they need to be acknowledged and/or addressed. The tool for this process is the Privacy Impact Assessment (PIA) Handbook. The size and complexity of the PIA will depend on what is proposed.

Copies of the PIA Handbook are available from the Office of the Privacy Commissioner. To request a copy:

• enquiries@privacy.org.nz, or
• the website http://www.privacy.org.nz/

A PIA approach

Properly applied, the PIA acts an ‘early warning system’ that formal management is required. Early use of the PIA Process is likely to help avoid later problems. A recommended approach would be as follows:

Step 1

Prepare an (internally written) initial PIA that:

• describes the reason for, and nature of, the proposed system
• describes at a high level, the intended information flows and requirements of the options currently being discussed with agencies and members of the public
• reviews the actual and potential impact on privacy, and legal implications of the proposal
• does not make formal recommendations but rather defines the concerns raised by each option presented.

Step 2

Define how an ongoing PIA process will be incorporated into the proposal.

Step 3

Develop processes appropriate to manage any privacy issues that may arise from the implementation of the proposal.

Note: Activity in this area should involve discussions with the Office of the Privacy Commissioner.

Addressing privacy in the business case

The business case should:

• include the preparation of a full formal PIA as a defined task
• indicate if the preparation of a PIA will be considered at various stages throughout the project, rather than a one-off task or report
• note that the PIA is to be prepared by a suitably qualified independent person or agency, and
• record the need to decide, very early in the process, if the PIA is to be published.

Reference: http://www.dpmc.govt.nz/cabinet/manual/index.html. See Chapter 11 of the Cabinet Office Manual for the procedures associated with obtaining approval to publish.

Section 5.8 - Legal Implications

Introduction

The business case should summarise and comment on:

• the effect of the proposal on any relevant legislation, regulation or Bills before the house, and
• the effect on the proposal of any relevant legislation, regulation or Bills before the house.

Cabinet Office Circular for guidance

A Cabinet Office Circular provides guidance on the way legal advice should be treated in departmental documents and Cabinet papers. Guidance is given on how to address disclosure protection, i.e. to protect advice subject to legal privilege from inadvertent disclosure.

Reference: CO (05) 5 dated 15 April 2005.

Range of legal risks

The business case should explore a wide range of relevant legal risks. Examples are:

• direct and indirect liability
• service failure implications
• repudiation
• delivery
• audit and review, and
• other types of legal risk that can arise from non-legislative causes, e.g. case law, judicial review.

Key questions

The following key questions are significant:

• Is the proposal robust from a legal perspective?
• Can the proposal comply with all of the relevant legislation/codes?
• Does the proposal require empowering legislation/regulation?
• Are there any international/jurisdictional implications arising from the business case?

Formal legal review

A full formal legal review of the proposal may either be required or be recommended as part of the project.

Example: Anything other than strict adherence to best practice design principles (e.g. the maintenance of uniform audit trails), will potentially undermine the legal robustness of the proposed system.

Acts that may affect the proposal

The necessity for legal work to be undertaken should form part of the business case. Consideration should be given to a wide range of Acts that may have an effect on the proposal. Examples are:

• Privacy Act 1993
• Human Rights Act 1993
• Public Records Act 2005
• Fair Trading Act 1986
• Consumer Guarantees Act 1993
• Electronic Transactions Act 2002
• New Zealand Bill of Rights Act 1990.

In addition, the implications of Codes of Conduct (e.g. for relevant industry/profession or Public Service) and evidence standards (e.g. for audit or research) may need be considered.

Basis of legal review

Depending on what is being proposed, the following outlines broad areas that should form the basis of the review:

Governance

The requirement for any legislation to establish accountability arrangements.

Administration

Legislation formalising specific aspects of the operation of the proposal, e.g. the relevant provisions in the Crimes Act 1961.

Miscellaneous

Other legislation related to the proposal addressing implementation matters, e.g. legislation operated by various agencies that may possibly have conflicting values in an all-of-government environment.

Note: It may be appropriate to provide a timetable showing how any action arising from the above may influence the development. This is a highly specialised area; appropriate advice should be sought from suitably qualified professionals.

Section 5.9 - Governance

Introduction

Governance, as addressed by the business case, should comment on both the project development process and outline options for the ongoing operation of the completed system, with an indication of how those options are to be addressed.

A clear and operable governance structure is fundamental to the achievement of a satisfactory project result, particularly in a multi-agency environment.

Document governance arrangements

The governance arrangements to be applied in undertaking the proposal should be documented, at least at the high level. Having reviewed the constraints the existing internal governance systems may impose, the business case should clearly identify:

• the lines of authority, up to the project sponsor and champion, and
• the escalation process (plus comment about ‘who’, ‘how’ and ‘timing’) for reporting, decision-making, and resolving issues.

What Level of Governance is Needed?

What to document

Information appropriate to the level of governance needed should be prepared and documented. Care must be taken not to go beyond what is needed for a business case, providing reference only to ‘standardised management processes’, unless there are unusual circumstances surrounding this project. The question of where ‘accountability’ vs. ‘advisory role’ starts and ends may be a question that will be answered in this area.

Project internal management

The following sets out some areas of internal project management that should be the subject of comment.

Steering committees/advisory boards

Covering:

• establishment
• composition and documentation of roles and responsibilities (e.g. for project cost/benefit tracking, scope change approval process)
• setting regular reporting requirements (frequency, scope, audience).

Governance boards, in both the development and operational phase

Of particular importance when there is a multi-agency impact from the project, and is achieved by the active involvement of the lead agency Chief Executive and/or Senior Management Team.

The relationships with external agencies

Examples are:

• Central Agencies
• ICT Monitoring agency
• Independent Quality Assurance (IQA) provider
• the PIA agency (including the relationship with the Office of the Privacy Commissioner), and
• other regulatory or environmental assessments, depending on the system/processes being developed e.g. Occupational Safety and Health assessors.

Level of management

In preparing governance information, knowledge of the most senior level of management involved is essential. This should be one of the following:

• Cabinet, for example, via:
• • the Minister (also consider the case of Joint Ministerial responsibility), or
  • the Lead Agency/Project (Advisory) Board/Chief Executive through the development agency’s line management.
• Agency Management Structure, for example, via:
• • the development Agency Management Board (if this exists) or
  • the Lead Agency/Project (Advisory) Board/Chief Executive through the development agency’s line management

A Possible Project Governance Model

Diagram

A possible project governance model may be represented as follows:

Additional reference

Additional reference material is available to provide context and assistance in developing “… an approach to deciding how to govern shared activities …” There are significant challenges in this area, and good documentation of the proposed solution is essential. Documentation should also be provided for future operational aspects including management of the new system.

Some additional material on governance is available on the SSC website, while the OAG report on Governance and Oversight of Large Information Technology Projects also provides some useful insights.

References:

• http://www.e.govt.nz/governance-funding/index.asp
• http://www.e.govt.nz/docs/gov-shared-200406/index.html
• http://www.oag.govt.nz/2000/it-oversight.htm

Section 5.10 - Consultation

Introduction

E-government systems by their very nature affect a wide range of groups of people, be they public users, other agencies, business users, or special interest groups. In developing such systems, it is appropriate to discuss proceedings and developments with these groups, or selected representatives of the groups.

Consultation where appropriate

No business case works in isolation. There are always other agencies that should be consulted during the preparation of a business case. In the case of the private sector agencies or the public, consultation may not be appropriate, depending on what it is proposed in the business case.

Specific requirements are laid down in the Cabinet Manual, with a step-by-step guide in Chapter 11.11 on the process for outside consultation.

Reference: http://www.dpmc.govt.nz/cabinet/guide/11.html

Definition

Consultation is that which occurs during the development of the concept or an idea. It is not that which occurs after the idea/concept/system is developed and just before the move to development/production is started.

The former is real discussion as the idea develops. The latter is informing groups of something that is already decided.

Three Basic Groups

Introduction

There are three basic groups for which consultation should be considered:

• the general participative agencies
• the agencies with generic control or oversight
• private sector agencies or groups.

Generic participative

The generic participative agencies are those influenced by the business case proposal. These are the agencies that rely on the data or actions or agencies upon whose data your agency relies. Examples may include Statistics New Zealand, IRD.

Other agencies with a specific interest in that agency/sector will need to be involved, for example Ministry of Health, Ministry of Justice.

Agencies with generic control or oversight

Agencies that have generic control or oversight roles may not be essential participants, but individual consideration to their early inclusion in discussion is recommended. They include:

• Central agencies - Treasury, Department of the Prime Minster and Cabinet, State Services Commission.
• Review agencies - Office of the Controller and Auditor-General, Office of the Privacy Commissioner, Office of the Ombudsman, Human Rights Commission.
• Specialist agencies - GCSB, Te Puni Kōkiri, PIA, Women’s Affairs

Private sector agencies and non-government organisations

Private sector bodies or groups covers the other influence or lobby groups that may have a significant input into the development of the proposal or in its application. They include:

• Private sector groups, e.g. banking, legal, accountants, Citizens Advice Bureaux, other professional special interest groups (Computer Society, ISACA), other ‘not for profit’ groups.
• Community groups, general or specialist, e.g. Māori, Internet
• General consultation groups, e.g. the ordinary process of public consultation.

Readers are also referred to the Office for the Community and Voluntary Sector for additional information, reference as below:

Reference: http://www.goodpracticeparticipate.govt.nz/

Other consultation work

The business case should also recognise what, if any, other consultation work has been done or still needs to be done, including the timing of such action. Agencies are advised to keep careful track of:

• who was consulted, both the agency and the person, and
• when they were consulted, and
• the outcome of that work.

This information will be of use in the completion of various associated forms should the proposal go to Cabinet for approval, e.g., the CAB 100 form.

Reference: http://www.dpmc.govt.nz/cabinet/forms/index.html

Groups in different categories

Don’t forget that groups can reflect different kinds of categories, such as:

• system users, e.g.
• • the public
  • specific interest groups such as Internet Society, Māori interest groups
  • users on behalf or others, i.e. intermediaries such as accountants, lawyers, Citizen Advice Bureau.
• system operators, e.g. other government agencies, business, other governments.
• system observers, e.g. Privacy Commissioner, Ombudsman, Auditor-General.

Consultation with the public

Special consideration should be given to any proposal that envisages consultation with the public. Readers are referred to the particular requirements of the Cabinet Office Manual, Step by Step Guide for the process to be followed in this case.

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

Documenting Consultation

Introduction

Consultation should be documented at a high level appropriate for the purposes of presenting a business case, rather than for actually applying the business proposal. The latter would not occur until the project is approved and active. When approved, the proposed consultation schedule would be expanded to be a working document.

Suggested procedure

Follow these steps to document consultation for each of the groups identified in the proposal.

Step 1

Identify the group constituent members, and if possible, the key figures, including the recognised spokesperson.

Step 2

Prepare a schedule indicating what discussion should be held with each group and when.

Step 3

Prepare forms that indicate how questions and consultation will be requested and in what form the responses are to be received.

Step 4

Prepare the documentation that will show who was consulted with, when, and the outcome of the consultation.

Section 5.11 - Associated Strategies

Introduction

In preparing the business case, it is appropriate to have available a number of associated supporting strategies.

Suggested associated strategies

Which strategies are needed depends on the particular business case. The following are suggested for consideration:

• Communications - at both the Ministerial and agency level. This may be in the form of advice to the respective groups only or it may include options and choices for a public consultation strategy.
• An early exit, or off-ramp, strategy.

Communications Checklist

Introduction

All agencies will already have a formal approach to communications as part of their standard operating routine. This document does not attempt to replace that approach. However, a few thoughts are offered as a partial checklist for consideration in building the business case, and at a summary level only.

Detailed plans will need to be prepared upon approval of the proposal. These should be prepared in consultation with the agency Relationship Management Team, by whatever name they operate.

Checklist

The checklist below gives suggested high level approach to communications, as should be reflected in the business case.

1. Briefly summarise the overall approach to communications relating to the business case.
2. Identify the strategic intent and objectives of the communication aspect of the proposal.
3. Identify the audience and stakeholders at the following levels:
4. • key and peripheral stakeholders
   • opinion-makers
   • interested parties.
5. Identify the communications environment in which the project will operate, addressing at least the:
6. • public sector
   • private sector, and
   • any specific technological aspects.
7. Identify the key messages that need to be handled.
8. Identify the method(s) by which communications are to be handled, including internal protocols to be adhered to, i.e. the key contacts within the agency who can speak on behalf of the project.
   This would also include reference to the procedures for handling media queries, posting key documents on the agency’s website.
9. Provide a communications calendar of significant events.
10. Identify programme/project risks and issues as they relate to a communications environment. Identify ways in which the communications programme will be measured and evaluated, i.e.:
11. • Were all the actions undertaken?
    • What effect did they have on the target audience(s)?
12. Address the key groups:
13. • how they will be asked to participate, if appropriate, and
    • how they will be affected by the proposal.
14. Provide, or allow for the preparation of, a Frequently Asked Questions (FAQ) document, including responses to the questions. It may be appropriate to provide contact reference points, e.g. a generic email address, for the public or vendors. Early Exit Strategy

Chunking of significant projects

These guidelines, and the document 'Managing and Monitoring of Major IT Projects', state the need to chunk significant projects. Chunking provides interim deliverables and allows for an early exit strategy should an unsolvable problem arise.

Reference: http://www.ssc.govt.nz/ITguidelines

Benefits of part implementation

Inclusion of a ‘pathway’ or ‘off-ramp’ diagram can indicate how benefits can be obtained even if the programme does not go to full implementation. A decision tree diagram or possibly a more visual representation could be used to demonstrate when a chance to adopt an exit-strategy option is available.

Reference: http://www.mindtools.com/dectree.html

Example

The following example is provided only to demonstrate an alternative method to display choices. The associated business case should include text for each identified off-ramp, discussing available opportunities to curtail the whole or part of the project while retaining some benefit at the time of closure.

[ Previous | Next ]