Guide to Developing IT Strategies in Supreme Audit Institutions

INTOSAI EDP

INTOSAI EDP Publications

Guide to Developing IT Strategies in Supreme Audit Institutions

Issued by
EDP Audit Committee
International Organisation of
Supreme Audit Institutions

October 1995

Contents

Chapter 1	Why have an IT strategy
Chapter 2	Aims of the Guide
Chapter 3	The stages in developing an IT strategy
Chapter 4	Plan IT strategy development
Chapter 5	Develop the business model
Chapter 6	Identify business systems
Chapter 7	Rank systems and identify benefits
Chapter 8	Review current technology and data and resource availability
Chapter 9	Draw up systems development plan
Chapter 10	Draw up business impacts
Chapter 11	Draw up implementation and training plan
Chapter 12	Planning post implementation activity - monitoring, maintenance and enhancement
Chapter 13	Strategy for migration - advice for SAIs implementing major systems or strategy changes
Chapter 14	Advice for small audit institutions - getting started
Chapter 15	Tips for Success
Chapter 16	Key terms

Chapter 1 - Why have an IT strategy ?

1.1	The business of an audit institution does not only comprise the provision of audit services. Other fundamental issues are the development of policy, the management of audit, and the management of staff, other resources, and support activities.
1.2	To manage these activities successfully, we must be able to make full use of the available information by organising it into "information systems". These systems may be manual, technology assisted such as a card index system, computerised, or a combination of all three.
1.3	Because information is such a vital resource, it requires planning to ensure that it is best applied to meet business aims and objectives. It must therefore be the concern of top management.
1.4	Planning for information systems is concerned with: understanding the aims and objectives of the business establishing the information requirements outlining the systems needed to provide the information determining the role of information technology in supporting the information systems agreeing policy, priorities and development and implementation plans managing, reviewing and evolving the strategy, and planning to manage potential impacts such as the effect on culture and organisation
1.5	An information technology strategy brings this information together into a plan to make the most appropriate use of both information and technology available in an organisation. The degree of sophistication will vary tremendously according to the size of the organisation and the resources available.
1.6	All organisations, of whatever size, should have an IT strategy. The cost of IT is significant and it is very easy to spend large sums of money without realising the full potential benefits. An IT strategy ensures that, when necessary, data can be integrated between users and systems, standards are adopted which allow future upgrade, and the full effect on the business overall is considered. All these factors mean that a high level business approach is needed.

Benefits of an IT strategy

1.7

The main benefits of an IT strategy flow from the statement of direction from top management and their commitment to the development of the role of IT in the organisation. The use of IT within an audit office enables data to be integrated with other data to add value; for example, an analysis of the skills needed for different types of audit work and a match against the skills of staff in the office, shared, through networking.

1.8

An IT strategy also ensures that resources are committed in line with business objectives, rather than on pure technical considerations, and makes the best use of resources in developing business systems

Warning!

1.9

Investment in computerisation must be worthwhile in itself. For example, very small audit institutions are unlikely to benefit significantly from data integration or a work and skills match because this information will already be known to those concerned and there is therefore no added value. For such an institution the use of standard word processing and spreadsheet facilities may be the only IT necessary, and "added value" might be provided through the use of manual or card index systems. But this does not negate undertaking an IT strategy review. A major benefit of a strategy review is developing the business model and understanding the business so that objectives may be achieved more efficiently and effectively.

Chapter 2 - Aims of the Guide

Who the guide is aimed at

2.1	This guide is aimed at senior management concerned with directing the development, monitoring and review of an IT strategy. This could be the Chairperson of an IT Steering Committee, or senior members of the audit institutions who need to understand the principles and stages involved in developing and implementing an IT strategy.
2.2	The focus of this guide is on broad principles rather than detail and is an attempt to define `best practice’. It draws on the experience of Supreme Audit Institutions in developing and implementing their IT strategies. The principles involved apply to audit institutions whatever their size and IT sophistication, although the degree of sophistication and the amount of work involved will vary and audit institutions will need to adapt the methods to suit their own situation, which may be far less sophisticated than that set out here. The important point is to retain a systematic approach to developing the strategy.
2.3	The guide should also help staff involved in developing and implementing an IT strategy to understand their role, the importance of planning for information systems and how they support business activity.
2.4	The logical and systematic approach advocated in the guide is the main feature of an IT strategy. But very small audit institutions with very limited resources might have very different objectives, timescales and problems in mind. Each chapter contains suggestions for small bodies where appropriate. Chapter 14 suggests a more streamlined and target approach to developing an IT strategy in such bodies.
2.5	A logical and systematic approach should also be adopted where migration from existing computer systems, as a margin change in IT strategy is expected. Chapter 13 contains further advice for SAIs considering migrating existing systems and focuses on the specific issues involved.

Chapter 3 - The Stages in Developing an IT strategy

3.1

The main stages in developing an IT strategy are set out below. The remainder of this guide deals with each in more detail.

Plan IT Strategy development (Chapter 4)

preparatory work, timescales, the project charter, methodology, steering committee, Project Team, support requirements, success factors;

Develop the business model (Chapter 5)

identify business remit and objectives; identify main business functions;

Identify business systems (Chapter 6)

identify business systems and those which are candidate computer systems; grouping candidate systems;

Rank value of systems and identify tangible and intangible benefits (Chapter 7)

estimate relative value of each candidate system and rank accordingly; assess value of tangible benefits; list intangible benefits;

Review current systems and data availability (Chapter 8)

consider data available in existing system and the ease of obtaining new data needed ; consider availability of resources - cash, people, skills;

Draw up systems development plan (Chapter 9)

consider costs, resources, timescales, priorities and dependencies;

Draw up business impacts (Chapter 10)

consider the effect that implementation of the proposed systems will have on the organisation and culture of the business and what changes may be needed;

Draw up implementation and training plan (Chapter 11)

consider transition stages, data validation and testing, and training programmes needed;

Post implementation - monitoring, maintenance and enhancement (Chapter 12)

consider longer term needs for systems enhancements and how the IT strategy may evolve; prepare resourcing plan.

Chapter 4 - Plan IT strategy development

4.1 The purpose of this preliminary work is to deliver agreed overall objectives, timescales, the project charter, methodology and the composition and role of the Steering Committee and the Project Team. Planning the strategy involves organisational issues, devising terms of reference, selection of a methodology and devising a timetable. These issues, and the relationship between them, are summarised at figure 1.

4.2 As with audit work, good planning is essential for cost effective and timely delivery. Changes, whether made to the strategy plan, or during the subsequent stages, are more expensive to accommodate the later they occur. It is therefore important to have formal review and "sign off" stages agreed as part of the plan. This ensures that all involved, including the Senior Management sponsor, are happy with the outcome so far and future plans before the next stage of the work proceeds.

4.3 These arrangements will not eliminate changes in requirements from occurring. Changes will always arise as the work proceeds. But formal review and sign off arrangements help focus on the added value of changes before final decisions are taken, and enable the reason for change to be understood, costed and monitored.

Preparatory work

4.4 The first stage of the work is to identify the Senior Management sponsor of the project and ensure that he or she fully understands the overall objectives of developing an IT strategy to:

ensure an accurate understanding of the business, comprising audit and support functions, for examples staffing and training issues;

build a bridge between strategic business planning and IT systems development;

ensure that all IT development meets corporate objectives;

produce a meaningful short and long term system development plan;

provide a framework for data sharing and adding value through data integration.

Timescales

4.5 It is important to consider timescales at an early stage, although these may need to be refined subsequently. In particular, setting out where the office wishes to be by a specific date will determine the pace of development and implementation of the strategy and the resources needed. For a larger audit office, it is unlikely that the strategy will be complete in less than 4 months, and it could be considerably longer, although too long a timeframe can cause loss of momentum.

Project Charter

4.6 The purpose of the project charter is to provide all concerned with an outline of the project at an early stage:

objectives;

expected benefits, including deliverables;

Senior Management commitment, the degree of involvement and formal "sign off" arrangements.

Methodology

4.7 This booklet provides high level guidance for developing the strategy, but in addition a formal systems analysis and design methodology which specifies the documentation standards and deliverables at each stage of the work is essential for success. Such a methodology helps focus attention on stages of the work, documentation, key deliverables and "sign off". However, the choice of methodology, and the degree to which it is applied, will depend on the overall size of the audit office and scope of the project.

4.8 There are considerable benefits to be gained from adopting a formal top down methodology. The documentation created during the strategy is an invaluable reference source for understanding the business and the interaction between its constituent parts.

Steering Committee

4.9 The Steering Committee is responsible for managing the strategy and subsequent implementation. It must have full authority to take decisions and therefore must be at the highest level affected by the strategy review. The Committee for a top down strategy review of an audit office is therefore likely to involve at least one member of senior management.

4.10 The responsibilities of the Steering Committee are:

to provide active critical review and "sign off" at agreed points in the project;

to provide final resolution of difficult issues;

to provide the necessary resources for successful completion;

to communicate progress and the outcome of the work.

The IT Strategy Development Team

4.11 The Project Team for developing the IT strategy should comprise a team leader and managers who represent the different functional areas of the business. A proven approach is to involve key players from both the audit and administrative functions and to use outside consultants to provide expert advice and to facilitate discussion. This can help to generate some creative conflict within the team. Another benefit is achieving a good balance between what is considered essential and desirable and what might be achieved in practice.

The size of the Project Team and the mix of internal and external resources will depend on the size of the audit office and the skills available. But, whatever the size of office, the team must be large enough to ensure an understanding of all the functional areas of the office, but small enough to be manageable and to reach decisions quickly. 3-6 members with a mix of audit, administrative and IT skills is probably an optimum size.

4.13 The responsibilities of the Project Team are:

to produce the project plan;

to carry out the analysis work, and take day to day analysis decisions;

to report progress and difficulties to the Steering Committee, and to present results and seek sign off at agreed points in the project (in practice, this involves continuous open communications with the Steering Committee, with periodic progress meetings to ensure that all aspects of the work are reported, and formal review meetings at agreed points);

to develop the IT Strategy.

4.14 The Project Team will need support personnel and access to technical advice when necessary. The latter may be provided in-house if available, or from external consultants. Depending on the size of the project they will need access to a computerised project management tool. They will need to agree documentation standards and procedures before the work starts, and to consider the techniques they will use to gather the information required.

4.15 Both the Steering Committee and the Project Team may need some training, before the work starts, in the methodology and techniques to be used.

Deliverables

4.16 The main deliverables from this initial stage in developing an IT Strategy are:

identification, education and commitment of a senior management sponsor;

a timetable;

a project charter;

selection of a formal systems analysis and design methodology;

set up of the steering committee and the Project Team

Success factors

4.17 The main factors in delivering a successful IT strategy are:

Senior Management commitment and active involvement;

100% availability of the main members of the Project Team; they must not bedistracted by other work;

a Project Team with collective wide experience of both the audit and the support activities of the business;

clearly defined objectives;

a business review, not just a technical review;

appropriate training at all levels;

easy access to expert advice.

Chapter 5 - Develop the Business Model

Business remit and objectives

5.1 The outcome of a successful IT strategy will be implementing systems that make business objectives achievable more efficiently, effectively and economically. The first step in developing the IT strategy is therefore to establish the remit of the office and identify the key business objectives. These may flow from the Corporate Plan. For an audit office these could, for example, be related to efficiency, quality and timeliness of audit work, increasing audit outputs, reducing inputs, and the quality and efficiency of administrative support services. An example of cascading objectives (which is neither complete nor a specific list) is at Figure 2.

5.2 This phase can often be the most difficult, because it involves a significant policy contribution from Senior Management in determining the future direction of the office. If these issues have not been recently addressed, considerable thought will be necessary. But the process can be effective in identifying the possibilities for change at a very early stage, and obtaining high level commitment to them.

Identify main business functions

5.3 Each business objective is supported by a number of business functions, and these need to be decomposed to a level sufficient for all involved to gain a full understanding of the entire business. An example of a decomposed business function is at Figure 3.

Tools and techniques

5.4 For this phase of the work (and the identification of business systems phase, which follows) the Project Team will need to gather information from a wide range of staff.

5.5 Information gathering is likely to involve both interviews (2 or 3 participants) and brain-storming sessions (5 to 20 participants). Interviews are useful where there is a focused objective. Brainstorming helps focus on an accumulation of ideas to resolve a given problem.

5.6 Interviews and brain-storming sessions must be documented, ideally by a member of the Project Team not directly participating in the discussion. The information gathered must be represented to those who originally provided it. This process, known as "review walk through" ensures that the Project Team fully understand both the business functions and relationships between them, and have grasped all the issued involved.

5.7 The formal methodology adopted (paragraph 4.7) should specify the standards to be adopted in formal documentation. For a large audit office, a computerised tool could be used to record the data collected. This helps ensure that the analysis work is structured covering the whole of the business. Such a tool also ensures consistency of documentation and data collection by different members of the Project Team.

5.8 "Review walk throughs" should be formal presentations of structured information to those who have provided information and higher levels of management, including senior management. The aim is to finalise understanding and agreement. Use of visual aids and formal presentation techniques are helpful in communicating understanding and advance circulation of material for review before the meeting is essential. Although the presentation should be formal, questions and disagreements ought to be taken as they arise and the discussion should be focused at isolating disagreement and taking corrective action. A member of the Project Team should act as session recorder. The meeting should be chaired by a neutral moderator, and not the Project Leader.

Deliverables

5.9 The main deliverables from this stage are:

identification of business objectives;

identification of main business functions, decomposed to present a full understanding of the business;

agreement by all involved, including senior management, to the decomposed business functions. Agreements must be reached before the next stage commences.

Chapter 6 - Identify Business Systems

Identify Candidate System

6.1 Once the business remit and objectives have been identified, the next step is to identify what IT is expected to contribute to the organisation, e.g. improvement in productivity, increased effectiveness, optimising the use of staff or opening up new areas of audit. The organisation needs to develop an IT vision to fit with its business remit, culture and future plans. The IT vision should be kept in mind while identifying the candidate systems (Chapter 6) and ranking them (Chapter 7) in terms of contributions to corporate objectives.

6.2 The next stage is to examine each one of the main business functions to focus on how they might be performed more efficiently, effectively and economically. Before computerisation is considered, the use of manual or technology assisted systems (such as a card index) should be reviewed. For a small audit institution, this can be very cost effective way of providing awareness and easy access to a wide variety of data. Computerisation should be considered only if manual systems do not provide the right level of efficiency, effectiveness and economy appropriate to the circumstances of the office.

6.3 For an audit office, functions that might benefit from organising into information systems include:

Financial audit support (e.g. planning, error evaluation, automated documentation)
Time recording

Performance audit support (e.g. planning, risk identifiers, automated documentation, generate and analyse response to questionnaires)

Strategic Planning

Database of accounts audited

Fees management

Database of reference material (manuals, previous reports, etc.)

Payroll

Job budgeting

General Ledger

Job scheduling

Accounts payable

People scheduling

Asset management

Personnel

Office automation

Recruitment

Desk top publishing

Training administration

6.4 A high level description of each system and the business functions it supports should be prepared setting out its objectives and brief specifications, together with the main users and interfaces to other systems.

6.5 At this stage it is necessary to consider, once again, whether computerisation is appropriate; the temptation to try and computerise everything must be avoided particularly if the data for input and potential output reports are non standard.

6.6 The need for, and the scale of, systems will depend of the size of the audit office. A large office might well need all the systems listed and more; a small office, with few existing systems might focus on computerising audit support tools, and computerising administrative systems might be unnecessary. Some administration functions, such as payroll and accounting, might more economically be handled on behalf of the audit office by another body who already have, or who are developing computerised systems.

6.7 In considering IT systems, it is important not to overlook the benefits of enabling office automation technology. This provides users with knowledge and experience of what IT can achieve and gives insight into how automation in other areas can add value. For an office with no existing IT, word processing and spreadsheets on personal computers might be a good introduction to computers.

Grouping Candidate Systems

6.8 Having identified candidate systems, it is helpful to think about them in groups:

those which provide administrative support to all areas of activity;

those which automate or support specific areas of activity.

6.9 For an audit office these could be characterised diagramatically as shown in figure 4. Benchmarking against other offices of similar size and functions is a useful way of ensuring the right focus on the potential grouping of systems.

6.10 Whatever systems are appropriate, it is necessary to determine a business value for each candidate system in order to assess priorities. This is discussed in the next chapter.

Deliverables

6.11 The deliverables from this stage are:

identification of candidate computer systems;

grouping of candidate computer systems.

Chapter 7 - Rank value of systems and identify benefits

Rank value of each system

7.1 This stage focuses on establishing priorities so that best value may be obtained if the budget for the IT strategy is limited. The aim is to establish a business value for each of the candidate systems identified. It is highly unlikely that a monetary value will be established at this stage, but it should be possible to consider how such a system will affect the efficiency of the audit business overall.

7.2 At this stage the high level description for each candidate system should be refined for wider circulation. At this point it is necessary to find a way of ranking systems according to their potential contribution to corporate objectives. Of course, this might be obvious for a small office with relatively few candidate systems. But for a larger office this may involve difficult matters of judgement. One possible technique is to circulate the high level specifications and undertake a "user survey". This can be done by sending a questionnaire to a wide range of individuals in the office who are asked to score each system from 1 to 10 on the basis of its contribution to achieving corporate objectives (and not their personal preference from their particular viewpoint in the Office).
Scores can be weighted for the importance of each factor. This approach is useful in both identifying a wide range of views, and in obtaining future commitment to potential computer systems. Whatever method of ranking systems is chosen, a score sheet should be drawn up to enable comparisons to be made. An example of a score sheet is at Figure 5.

7.3 A small audit office with no existing IT might wish to focus at this point on user awareness and education in considering ranking of systems. As already stated, implementation of word processing and spreadsheet packages "enable" other systems to follow.

Figure 5 : Ranking of strategic systems by their potential contribution to corporate objectives

Objectives

Systems (ranked by overall score)
Assurance on Accounting

Assurance on
VFM

Assurance on
Regularity

High Standards/ Minimum Cost

Best use of staff

Recruit / Maintain High Quality staff

Best use of Non-staff Resources

Maintain External Relations

Weighted Overall Score

Financial audit support

Performance audit support

Accounts audited database

Reference database

Job budgeting

Time Recording

Payroll

Personnel

Office automation

Identify tangible and intangible benefits

7.4 To establish the tangible and intangible benefits of each system, once again a user survey might be appropriate. Tangible benefits are those which can easily be quantified in cash or time saving terms; such as reduced staffing or delegation to more junior staff. Intangible benefits are secondary, and may not be quantifiable in cash or time terms; for example, improved quality of output or decision making.

7.5 Potential users could be asked to score potential benefits and again these scores can be weighted for the importance of each factor. Examples of score sheets are at Figure 6 and 7. It is important to avoid becoming too bogged down in a detailed mathematical exercise in this stage of strategy. The main point is to consider contribution to corporate objectives and potential benefits in a logical way, keeping the corporate overview in mind throughout.

7.6 For a small audit office with limited resources, adopting a phased approach to ranking systems and identifying benefits might be more appropriate. The aim should be to identify candidate systems at an early stage, establish their suitability for computerisation and undertake a detailed analysis of contribution to objectives and potential benefits of only those systems which are likely to be shortlisted for computerisation in the near future.

Deliverables

7.7 The main deliverable from this stage of the work is a list of candidate strategic systems ranked according to their contribution to corporate objectives and potential tangible and intangible benefits.

7.8 The next step is to consider how to tackle the technological and resourcing issues involved, so as to maximise the potential benefits of the new systems identified.

Figure 6 : Ranking of strategic systems by potential tangible benefit

Systems (ranked by overall score)
Descriptions

Staff reduction

Reduced Recruit-ment
Reallocation to other duties
Work done at lower levels

Better use of equipment

Better use of property

Better use of money

Total £ 000
p.a.

Financial audit support

Performance audit support

Accounts audited database

Reference database

Job budgeting

Time Recording

Payroll

Personnel

Office automation

TOTAL

Figure 7 : Ranking of strategic systems by potential intangible benefit

Potential Intangible Benefits

Systems (ranked by overall score)
Staff time saved

Improved Communication

Improved Quality of Output

Improved Quality of Service

Improved Quality of Information

Improved Quality of Decision Making

Improved Speed of Decision Making

Better Planning

Total Score

Financial audit support

Performance audit support

Accounts audited database

Reference database

Job budgeting

Time Recording

Payroll

Personnel

Office automation

E.g.: High = 5, Medium = 3, Low = 1

Chapter 8 - Review current technology and data and resource availability

Current systems

8.1 There are many issues to be decided in order to maximise the benefits of the strategy before an implementation plan can be drawn up. For example:

what is the status of and technology used in current systems ?

what data is available ?

what resources are available ?-cash -people -skills

This information will enable the Project Team to draw up the development plan.

8.2 This work should document current systems, both automated and manual, to establish their effectiveness (documentation, accuracy, maintainability and usability) and conversion effort involved (size, complexity, documentation quality and interfaces to other systems). Further information focusing on the specific issues associated with migrating existing systems is given in Chapter 13.

Technological review

8.3 The main outcome of the technological review should be to decide whether to use the existing technology, upgrade or replace it. The review should establish the benefits of each solution, but the decision is likely to depend on how quickly the existing technology will become obsolete and the costs involved. In making a decision it should be borne in mind that hardware is relatively cheap compared with the costs of redeveloping software and user training. To minimise the cost, a progressive upgrade in stages may be the most effective solution.

8.4 These issues will once again depend on the size of the office and the extent of existing IT. A small office with a small number of PCs might consider whether it would be worthwhile linking these together on a local area network, in order to share information between them. An office, which already has a local area network, might consider organising users into "workgroups" to encourage them to share information and appreciate the full value of a networked system.

Data availability

8.5 The review of current systems should also include an analysis of the data available from them and determine how easy it will be to obtain the additional data required by new systems. How easily the data required is available may affect the implementation plan and the time before full benefits of new systems can be achieved. If the system involves using clients’ computerised data, the legal right of the audit office to access such data would also have to be considered.

Resources

8.6 The availability of cash resources will be a key feature in considering the development plan and the phasing of it. The Senior Management sponsor of the Strategy should decide whether the necessary funds are likely to be available or whether a bid for additional funds will be required.

8.7 Review of current availability of people and their skills is also necessary at this stage. A large audit office may already have sufficient staff with the right skills to implement the strategy, but a small office with no existing IT, will need to decide whether to rely on external staff, or to train existing staff, or a combination of both.

Deliverables

8.8 The main deliverables form this stage are:

a technological review of existing systems and proposals for upgrade or replacement;

a review of data availability, problems and proposed solutions;

a review of resource availability and proposals for resourcing development and implementation.

8.9 This information sets out the background for the next stage - drawing up the systems development plans.

Chapter 9 - Draw up systems development plans

9.1 The systems development plan sets out the strategy (and if necessary - options) for implementing the candidate systems, and should set out costs, resources, priorities, dependencies and timescales. The plan should be formally approved by Senior Management before development proceeds.

Strategic options

9.2 There will always be more than one approach to implementing the desired end product, and at this stage it is necessary to build on the review of current technology to consider and evaluate the range of possible technical solutions including long term considerations. The solution is likely to depend on the number of users of each system and the degree of compatibility and integration required. While integration is more likely to be an issue for a large audit office with many users of different systems, it is important for all audit offices to consider every small system as fitting into an organisation-wide system. The prominent trend is towards integration of systems. This provides organisation-wide sharing of information across technological and application boundaries. The pace of development of IT hardware and software means that there will be advantages of tried and tested technology to be weighed against the risks of leading edge technology, but which is offering potentially greater advantages in the long term.

9.3 These factors should be carefully weighed. The aim is to gain the maximum advantage from the latest technology but to minimise the risks of a delayed or unsuccessful implementation.

9.4 Package solutions are tried and tested and reliable. But they may not exactly match business requirements, nor integrate with each other in the way required. On the other hand, a bespoke solution will require significant development effort, will not be tried and tested until implemented, and will require continuing maintenance and enhancement.

9.5 If a bespoke solution is proposed, the systems development plan should consider how best to achieve precisely what users want. Modern programming tools mean that it is possible for users to sit down with developers and work out screen layouts and functionality together, "on screen". This "prototyping" can shorten the timescale for development and ensures that users can visualise what they will be getting.

9.6 Prototyping also allows for experimentation on a manageable scale before bigger projects are attempted.

9.7 A further key factor in drawing up strategic options is timing - how quickly can the proposed strategy be achieved bearing in mind cost and resource constraints. If plans need to be phased, the dependencies and interfaces between systems becomes a major factor.

9.8 Finally, the future development path should be considered to ensure that the proposed solution will be easily kept up to date as the technology changes. Of course, only known changes can be taken into account, but there would be little point in implementing solutions that are likely to become obsolete in say 3-4 years. The important point is to decide an overall IT architecture and choose systems architecture that retains flexibility for the future to the greatest possible extent. Often this will involve compromise. So called "open systems" make it easier to replace hardware with that from a different manufacturer. However, changes of software can be very expensive, particularly for end user re-training.

System ownership

9.9 For each system proposed for implementation, an "owner" should be appointed as development commences. The owner - who should be a user - is responsible for agreeing specifications with developers, and for final user acceptance. If a decision is to be made, and consensus cannot be achieved, the system owner makes the final decision and stands by it. The owner must be totally committed to the project and the selected person should remain in the role for the duration of the development and implementation. Consulting users at all stages of development often provides many useful ideas that would otherwise be missed.

Costs

9.10 Options for the systems development plan should consider all the costs involved - hardware, software, user training (which can be significant part of implementation costs) and maintenance. If a phased approach is appropriate, or the implementation is planned over a period of years, the cost of options should be compared using discounted cash flow techniques to ensure comparability.

Resources

9.11 Resource options should be considered. For example, it might not be desirable to be totally dependent on outside expertise for implementing new systems. A mixed team of external experts and in house staff, who should receive appropriate training, could help ensure continuity on the development and acquire the skills needed for subsequent maintenance. For a small office the requisite skills are unlikely to be available, and external experts are likely to be the main implementation resource. But ideally at least one member of staff should undergo some appropriate training to provide the link to ensure that what is implemented is what is actually required - and to act as an "intelligent purchaser".

9.12 A small audit office with little or no IT experience and limited resources might have decided when ranking systems to focus on those that were less sophisticated or which delivered potential benefits in terms of user experience and awareness. This approach also helps to build up expertise in development and implementation, and reduces dependence on expensive external resources.

Deliverables

9.13 The outcome of this stage is a fully documented systems development plan, formally approved by Senior Management.

Chapter 10 - Draw up business impacts of new systems

10.1 As the IT strategy develops, particularly in a large audit office with a wide range of systems proposed, possible changes in the organisation of the office and the effect on staff will begin to emerge. This stage considers the effect that implementation of the IT strategy will have on the organisation and culture of the audit office, and the consequential changes that may be needed.

Identify existing culture

10.2 The initial stage is to analyse the current culture of the office, consider how it responds to internal stimulus, and how staff are oriented to each other and to new technology. For an audit office it is likely that the culture will be the traditional one of centralised control and decision making with a low degree of risk taking.

Identify potential impacts

10.3 Implementing an IT strategy is likely to lead to information becoming much more widely available, resulting in a more competitive environment. Some functions (and staff) may become redundant.

10.4 Improved management information and particularly the wide visibility of data should lead to improved accountability at all levels. Not all staff will welcome this. Some will see the new systems as a threat rather than a benefit. For example, time recording systems can be seen as greater management control and conflicting with the corporate objective of greater delegation. Some staff may act adversely and actively seek to discredit new systems.

10.5 It is therefore important to keep staff fully informed whilst the review is underway and to allow them to contribute as much as possible. The wider benefits of new systems must be fully explained so that staff do not just take a "what’s in it for me" approach.

10.6 Implementation plans should ensure that the data presented to users is correct and cannot be discredited. A discredited system will take a great deal of time and effort to recover.

Develop business impacts plan

10.7 The plan should present measures to overcome these threats. Items for consideration are:

staff involvement at all stages;

good communications to explain the objectives of new systems and the benefits;

good quality training prior to using the system and good quality help and support facilities;

continuous demonstration of top management commitment

10.8 As work on the IT strategy proceeds, it may become clear that the new systems will enable greater efficiency to be achieved through reorganisation of work, staff or fundamental changes in the management structure. Top management will need to consider the timing of these more fundamental changes. For example, implementation in parallel with the IT strategy may be too much change at once, and organisational changes might be left until the IT systems have settled in. The decision will depend on a good knowledge of existing organisation culture and anticipating the reactions of staff. Some changes may be needed prior to the implementation of new systems. And the introduction of new technology can be used to change the way the business is run - there is little point in computerising inefficient routines. The plan should set out the various stages of changes, the likely staff reaction, and proposals to ensure they are positively received.

Deliverable

10.9 The outcome of this stage should be a plan, approved by senior management, which sets out the stages of change and action points to ensure success.

Chapter 11 - Draw up implementation and training plan

Implementation

11.1 Once the systems development plan and business impacts plans are approved, the implementation and training plan should be drawn up. This should be a realistic assessment of implementation and include all the necessary stages, for example user training, parallel running and data validation.

11.2 The production of a demonstration prototype system, or parts of a system, is a useful way of obtaining early feedback on whether what is proposed will meet user needs, and is likely to result in helpful suggestions for improved presentation of information or better functionally.

11.3 Implementing pilot projects in a limited area takes this process one stage further. Using the proposed system in the live environment in this limited way means that problems are identified before full live implementation.

11.4 Both these techniques can be very helpful in implementing systems that do not depend on a corporate database, and that run on stand alone machines. For example, audit support tools can be developed very much in conjunction with users in this way, and implemented in stages.

11.5 Whatever the system, implementation may be made in many phases, and each phase must be fully validated and tested before it goes live. The implementation plan should include sufficient time and resources for data take on and validation and for the system to be fully tested in as near to live conditions as possible.

11.6 A successful implementation will be supported by publicity material to generate enthusiasm for the new systems. This will raise user expectations. It is important that these expectations are met and that the system is not discredited through insufficient testing or data validation, or that pre-implementation publicity claims are not delivered. Continued user involvement as the development proceeds, for example, by showing the new system to staff consulted during the early stages of the strategy, helps ensure that what is being delivered is what is expected.

Training

11.7 User training is also a key to success. Users must feel comfortable with new systems from an early stage. Ideally, training should be provided immediately before the user is allowed access to the live system.

11.8 This training should not simply teach which keys to press, but also focus on the reasons for the introduction of new system, benefits to users, the wider benefits, how the systems integrate with others as well as culture change issues.

11.9 Besides general user training, special attention should be paid to the training for senior management, as their support is critical for the successful implementation of IT systems. Their training should focus on how the IT strategy supports the business functions, the IT implementation plan and their role as managers in supporting the implementations.

Deliverable

11.10 The deliverable from this stage is an agreed implementation plan, identifying stages, dates, proposed user consultation and training.

Chapter 12 - Planning post implementation activity - monitoring, maintenance and enhancement

12.1 The final stage of the strategy is to draw up plans for maintenance of the systems, for monitoring to ensure that the systems implemented deliver the anticipated benefits, and for enhancements.

Maintenance

12.2 Maintenance, including both hardware and software upgrades, is a significant cost factor in an IT strategy and should not be underestimated. Day to day "help desk" and support facilities must be fully resourced. In addition, sufficient resources must be provided to allow development to meet changing business requirements and technology changes.

12.3 Maintenance falls into two areas:

meeting changing business requirements

technological enhancements

12.4 The former should be the responsibility of a user - a sponsor for each system - and not the IT maintenance staff, whose responsibility is to respond to sponsor requirements and advise on technology changes. This approach should ensure that technology does not drive system changes, but that the technology is used to best advantage in meeting business requirements.

Monitoring

12.5 A maintenance plan should include a periodic review to ensure that the anticipated benefits of the IT strategy are delivered. This is often difficult to quantify because the business re-engineering environment created by the strategy means that savings are not always attributable to a single system or event. But quantification of the benefits achieved should be made. This could be through a user survey similar to that used in assessing tangible and intangible benefits (Chapter 7) . The overall IT strategy should also be reviewed and updated periodically -say every three years - to ensure that the benefits of the latest available technology are exploited in a cost effective way.

Enhancement

12.6 Once users have become familiar with the new systems they will seek enhancements. This might involve improved functionality or integration. Each will need to be considered on its own merits and costs and benefits should be weighed as with the original strategy. Any changes should be fully documented.

12.7 If a package solution is adopted, it is important to bear in mind that software packages are frequently upgraded, offering enhanced functionality, ease of use, or integration. But it can also mean that changes in software take place at the supplier’s discretion and may not match your requirements.

12.8 Keeping the IT strategy documentation up to date as changes to systems are made will ensure that data is readily available for subsequent strategy reviews, and that the groundwork does not have to be repeated.

12.9 The post implementation plan should take account of all these factors. Resources and costs should include all the elements of maintenance and consider who will undertake the work. The continuing success of the system will depend on its flexibility - the ability to accommodate change quickly when necessary - and good quality maintenance, responsive to the needs of users.

Deliverable

12.9 The outcome of this final stage is an agreed plan to manage maintenance and enhancement, including proposals to ensure that expected benefits are delivered, and to review and update the overall strategy periodically.

Chapter 13 - Strategy for migration - advice for SAIs implementing major systems or strategy changes

Introduction

13.1 The procedures in this guide should be followed both in the situation where there is currently no IT and where migration from existing computer systems or a major change in the existing IT strategy is planned. This chapter offers more detailed advice to SAIs who are considering migrating existing systems and focuses on the specific issues involved.

Review of existing systems and data

13.2 This booklet recommends that an IT strategy should be reviewed and updated periodically (Chapter 12). The review of the business model (Chapter 5) will identify key business systems, some of which may already exist. The review of current technology and data (Chapter 8) should ensure that for these systems, the Project Team fully understand the fund of experience, understanding (or possible misunderstanding), skills, problems and opportunities that currently exist.

13.3 The Project Team will need to review and document existing systems, the hardware, software and any communications network, documentation quality, complexity, interfaces to other systems etc. and evaluate key problems. This review should focus on how IT is already being used, and how it is managed and being delivered to users. The review should highlight issues for senior management’s attention such as:

whether IT is seen by users as a necessary evil, a scarce resource, or an aid to their work. This indicates the overall value placed on existing systems by users and whether business objectives are achieved;

whether the existing systems are considered easy to use and provide a rapid response to users. Do they provide information on-line, or do users have to wait for daily, weekly or monthly batch runs to obtain the information they require? What is the demand for on-line access to the information held?

whether the existing systems can cope with the demand placed upon them. Are there complaints about lack of flexibility, usability, accuracy, response times etc.?

the proportion of resources devoted to maintenance, and the extent to which technology rather than user demands, is driving system changes.

technical support availability, and the wider availability of the skills needed for maintenance (.e.g. does the system rely on the skills of one person who could not easily be replaced?)

the degree of data duplication, and data that is collected but not needed.

Relating existing systems to the new business model

13.4 The Project Team should also relate the functions of the existing systems to business objectives to highlight any gaps in functionality. This helps ensure that the proposed new systems meets the needs of the business and does not simply replicate what currently exists.

Migration options

13.5 If the existing system does not satisfy the current business requirements there are three main options for migration:

use existing technology but enhance functionality

upgrade technology and enhance functionality

replace

13.6 The choice depends on how quickly the existing technology will become obsolete, whether it can handle new requirements, the replacement costs, the resources available, or a combination of all these factors. There is no hard and fast rule for the decision, which will depend on the individual circumstances of each case.

13.7 But in reaching a decision, SAIs should bear in mind that the cost of hardware is relatively cheap compared with the costs of developing bespoke systems. A particularly significant cost of replacing systems, and one which is often underestimated, is the cost of re-training users, even when package solutions are adopted.

13.8 The ideal solution might be a progressive upgrade in stages which allows upgrade and re-training costs to be spread over a suitable period. But this is not always possible if hardware is obsolete or will soon become so, or a major change in functionality is required beyond the capability of the existing system.

13.9 The deliverable at this point - as part of the overall systems development plan (Chapter 9) - is to present the Steering Committee and Senior Management with options for migration, within the framework of an overall IT architecture, drawing up the advantages, disadvantages, risks, upheaval, costs and availability of skilled resources necessary for each. Cost must be comprehensive and include the costs of transition. Maintaining both new and old systems for lengthy periods can be expensive and must be weighed against the risks involved if the new system fails. And the review must take account of the effect on and costs of any changes needed to linked systems.

Developing a migration plan

13.10 The chosen options - as with other approved proposals in the systems development plan - should be reflected in the business impacts assessment (Chapter 10) and implementation and training plan (Chapter 11).

13.11 For systems to be migrated, systems development and other plans should include data capture, data conversion, data loading and validation, user training, preparing training materials, acceptance testing and parallel running where appropriate. Particular care is necessary in planning how the switch over from the existing systems will occur and what fallback to existing systems will be provided if problems arise - for example, the period of parallel running needs to be extended until the new system has been proved. Examining these issues before the systems development plan is finalised and approved ensures that problems do not arise late in the development cycle which are costly to resolve - for example it is easy to overlook or underestimate the additional effort which may be needed to capture and validate new data outside the scope of the existing system.

13.12 Data converted from an existing system will need to be checked to ensure that it has been captured correctly. Acceptance testing is likely to reveal a number of anomalies within the data. Each must be investigated to correct data and assess the implications of the error or inconsistency uncovered, and plans must allow adequate resources for this work.

Planning post implementation activity - monitoring, maintenance and enhancement

13.13 Migrated systems should be included in the plan for post implementation activity (Chapter 12). The agreed plan should include task to ensure that expected benefits are delivered, and that the overall strategy is reviewed and updated periodically.

Chapter 14 - Advice for small audit institutions - getting started

14.1 The full procedures set out in this guide are unlikely to be appropriate for small audit institutions with very limited resources. They are likely to have very different objectives, timescales and problems in mind. This chapter therefore suggests a more streamlined and targeted approach to developing an IT strategy in such bodies.

14.2 Often the first step in introducing IT will be to buy a few personal computers and to implement office systems such as word processing and spreadsheet. But even then, developing a strategy is desirable. The important point - and this is why the guide primarily deals with each stage of the strategy in turn - is to retain a logical and systematic approach. Small size or limited resources makes it even more important that best value is obtained from what is available. This means that a clear strategy must be properly planned in a systematic way. Failure to do so, could lead to nugatory expenditure and wasted effort on systems that do not support business objectives.

14.3 One approach is to streamline development into four stages. The diagram opposite illustrates how this might be achieved. The remainder of this chapter offers advice on each of these stages.

Stage 1 - Plan IT strategy development

14.4 This stage remains key. The main elements are to:

appoint a senior management sponsor;

decide who is going to undertake the strategy review;

draw up a timetable;

start with a review of the business of the audit institution, not the technology available.

Stage 2 - Identify priorities

14.5 The outcome from this stage must be clear statement of proposed systems and priorities. To achieve this it is necessary to:

agree a set of main business objectives and functions, ensuring that there is a full understanding of the business;

consider whether improvements could be achieved by other means, for example, by using manual or card index systems;

consider whether some of the functions which are candidates for computerisation could be managed better by someone else who already has or is developing computer systems, for example, a bureau;

consider the benefits of enabling technology, such as office automation - stand alone PCs with word processing and spreadsheet software - and whether this would be a good introduction to computers and IT. A focus on user awareness and education may well be a first priority.

rank other potential computer systems according to their corporate objectives, but their is little point in, putting a great deal of effort into evaluating systems of lower priority until the organisation has the skills or resources are available for implementation;

ensure that proposals have senior management approval and that the resources to develop, implement and support the strategy will be available.

Stage 3 - Plan implementation and training

14.6 Key points for this stage are to:

consider package solutions - they may not meet requirements precisely, but are much cheaper to support;

train at least one member of staff to act as "an intelligent purchaser’’ and to act as trouble-shooter. This will help cut through some of the gloss from manufacturers and salesmen, and will reduce dependence on expensive external resources;

ensure that all users will receive adequate training to get them started - even with standard word processing and spreadsheet packages. The IT strategy is likely to fail if users are afraid of, or uncomfortable with, using computers or they do not know what is expected of them;

get senior management approval to the plan and a specific commitment for resources to implement it;

ensure that senior managers directly or indirectly concerned with the implementation, receive training regarding the IT strategy, the implementation plan and their role in supporting implementation.

Stage 4 - Handling systems after implementation

14.7 The final stage of developing the strategy is to plan what will happen after implementation. The main features are to:

plan for maintenance of both hardware and software;

plan for monitoring the use of IT implemented to ensure that the expected benefits are being achieved.

plan for enhancements - to meet user requirements once they have become familiar with what computers can do to meet technological change, and to implement other planned systems as resources become available;

keep the documentation produced as part of the strategy review up to date to reflect changes as they arise;

ensure resources are available to keep the system running and that the organisation is not over reliant on a small number of key staff who may leave;

review and update the overall strategy periodically.

And finally!

14.8
The success of the strategy review will not only be measured by number of computers purchased or systems successfully implemented. More important is that all involved will have a much better understanding of the objectives of the business and how the various supporting functions work. Limited resources may mean everything desirable cannot be achieved immediately or in the foreseeable future, but the review will have revealed what should be done, established priorities and set out the path for achieving those most important.

Chapter 15 - Tips for Success

Avoiding Problems

The first tip it to avoid problems. These generally arise for the following reasons:

poor communications between the Project Team and senior management, with consequent loss of commitment;

choosing the wrong methodology which focuses on the wrong level of details;

a technique or tools driven process resulting from lack of management input;

loss of momentum and importance as a result of too long a time frame.

Senior management involvement

This booklet has emphasised the importance of senior management involvement, and not just "rubber stamp" endorsement. To achieve this the Project Team need to:

deal with the issues that affect the business at senior management level;

ensure that proposals help meet corporate objectives;

treat the IT strategy as a business planning function;

maintain informal communications with senior management throughout, but incorporate formal review and sign off procedures which result in formal recommendations.

Managing a successful project

To ensure success, senior management must ensure that the Project Team:

are results oriented;

do not get bogged down in too much detail;

use the resources allocated to them effectively;

remain in tune with senior management objectives;

maintain active senior management involvement.

Key factors for success

A list of success factors is included earlier in this booklet. But it is worth re-iterating key factors here:

active senior management involvement;

involve users at all stages;

the right mix of skills and business experience in the Project Team who should be full time staff;

a tight, but realistic, timescale;

use of an appropriate methodology specifying deliverables, and proper support and documentation tools;

not too much detail;

use of an experienced facilitator;

ensure that business needs rather than technology lead the strategy.

Chapter 16 - Key Terms

Benchmarking

is the comparison of functions and performance with organisations of similar size and character.

Bespoke solutions

are software applications that are written specifically to suit the individual needs of the organisation or users.

Business functions

are discrete components of the work of an office, e.g. management of a financial audit. They can be decomposed in a hierarchy so that at the lowest level the decomposed function represents a single activity.

Business needs

are the activities that the office must perform in order to meet its statutory or operational requirements.

Business strategy

is the top level statement of direction which articulates the aims, objectives and activities of the office, and the resources and commitments to meet its objectives.

Candidate system

are those for which computerisation offer potential benefits.

Information systems

are the IT and non IT based systems which support the business needs.

Intangible benefits

are those which cannot be quantified in cash or time saving terms.

Package solutions

are software packages that come ready to install. They are applications that are suitable for a wide variety of general purposes (e.g. word processing, spreadsheets).

Prototyping

is the iterative development of information systems, or pats of systems, by presenting users with a mock up of screens to illustrate screen layout and functionality.

Tangible benefits

are those which can be quantified in cash or time saving terms.

Back to Publications Index

4.1	The purpose of this preliminary work is to deliver agreed overall objectives, timescales, the project charter, methodology and the composition and role of the Steering Committee and the Project Team. Planning the strategy involves organisational issues, devising terms of reference, selection of a methodology and devising a timetable. These issues, and the relationship between them, are summarised at figure 1.
4.2	As with audit work, good planning is essential for cost effective and timely delivery. Changes, whether made to the strategy plan, or during the subsequent stages, are more expensive to accommodate the later they occur. It is therefore important to have formal review and "sign off" stages agreed as part of the plan. This ensures that all involved, including the Senior Management sponsor, are happy with the outcome so far and future plans before the next stage of the work proceeds.
4.3	These arrangements will not eliminate changes in requirements from occurring. Changes will always arise as the work proceeds. But formal review and sign off arrangements help focus on the added value of changes before final decisions are taken, and enable the reason for change to be understood, costed and monitored.

4.9	The Steering Committee is responsible for managing the strategy and subsequent implementation. It must have full authority to take decisions and therefore must be at the highest level affected by the strategy review. The Committee for a top down strategy review of an audit office is therefore likely to involve at least one member of senior management.
4.10	The responsibilities of the Steering Committee are: to provide active critical review and "sign off" at agreed points in the project; to provide final resolution of difficult issues; to provide the necessary resources for successful completion; to communicate progress and the outcome of the work.

4.11	The Project Team for developing the IT strategy should comprise a team leader and managers who represent the different functional areas of the business. A proven approach is to involve key players from both the audit and administrative functions and to use outside consultants to provide expert advice and to facilitate discussion. This can help to generate some creative conflict within the team. Another benefit is achieving a good balance between what is considered essential and desirable and what might be achieved in practice.
	The size of the Project Team and the mix of internal and external resources will depend on the size of the audit office and the skills available. But, whatever the size of office, the team must be large enough to ensure an understanding of all the functional areas of the office, but small enough to be manageable and to reach decisions quickly. 3-6 members with a mix of audit, administrative and IT skills is probably an optimum size.
4.13	The responsibilities of the Project Team are: to produce the project plan; to carry out the analysis work, and take day to day analysis decisions; to report progress and difficulties to the Steering Committee, and to present results and seek sign off at agreed points in the project (in practice, this involves continuous open communications with the Steering Committee, with periodic progress meetings to ensure that all aspects of the work are reported, and formal review meetings at agreed points); to develop the IT Strategy.
4.14	The Project Team will need support personnel and access to technical advice when necessary. The latter may be provided in-house if available, or from external consultants. Depending on the size of the project they will need access to a computerised project management tool. They will need to agree documentation standards and procedures before the work starts, and to consider the techniques they will use to gather the information required.
4.15	Both the Steering Committee and the Project Team may need some training, before the work starts, in the methodology and techniques to be used.

5.4	For this phase of the work (and the identification of business systems phase, which follows) the Project Team will need to gather information from a wide range of staff.
5.5	Information gathering is likely to involve both interviews (2 or 3 participants) and brain-storming sessions (5 to 20 participants). Interviews are useful where there is a focused objective. Brainstorming helps focus on an accumulation of ideas to resolve a given problem.

5.6	Interviews and brain-storming sessions must be documented, ideally by a member of the Project Team not directly participating in the discussion. The information gathered must be represented to those who originally provided it. This process, known as "review walk through" ensures that the Project Team fully understand both the business functions and relationships between them, and have grasped all the issued involved.
5.7	The formal methodology adopted (paragraph 4.7) should specify the standards to be adopted in formal documentation. For a large audit office, a computerised tool could be used to record the data collected. This helps ensure that the analysis work is structured covering the whole of the business. Such a tool also ensures consistency of documentation and data collection by different members of the Project Team.
5.8	"Review walk throughs" should be formal presentations of structured information to those who have provided information and higher levels of management, including senior management. The aim is to finalise understanding and agreement. Use of visual aids and formal presentation techniques are helpful in communicating understanding and advance circulation of material for review before the meeting is essential. Although the presentation should be formal, questions and disagreements ought to be taken as they arise and the discussion should be focused at isolating disagreement and taking corrective action. A member of the Project Team should act as session recorder. The meeting should be chaired by a neutral moderator, and not the Project Leader.

6.1	Once the business remit and objectives have been identified, the next step is to identify what IT is expected to contribute to the organisation, e.g. improvement in productivity, increased effectiveness, optimising the use of staff or opening up new areas of audit. The organisation needs to develop an IT vision to fit with its business remit, culture and future plans. The IT vision should be kept in mind while identifying the candidate systems (Chapter 6) and ranking them (Chapter 7) in terms of contributions to corporate objectives.
6.2	The next stage is to examine each one of the main business functions to focus on how they might be performed more efficiently, effectively and economically. Before computerisation is considered, the use of manual or technology assisted systems (such as a card index) should be reviewed. For a small audit institution, this can be very cost effective way of providing awareness and easy access to a wide variety of data. Computerisation should be considered only if manual systems do not provide the right level of efficiency, effectiveness and economy appropriate to the circumstances of the office.
6.3	For an audit office, functions that might benefit from organising into information systems include:

Financial audit support (e.g. planning, error evaluation, automated documentation)	Time recording
Performance audit support (e.g. planning, risk identifiers, automated documentation, generate and analyse response to questionnaires)	Strategic Planning
Database of accounts audited	Fees management
Database of reference material (manuals, previous reports, etc.)	Payroll
Job budgeting	General Ledger
Job scheduling	Accounts payable
People scheduling	Asset management
Personnel	Office automation
Recruitment	Desk top publishing
Training administration

6.4	A high level description of each system and the business functions it supports should be prepared setting out its objectives and brief specifications, together with the main users and interfaces to other systems.
6.5	At this stage it is necessary to consider, once again, whether computerisation is appropriate; the temptation to try and computerise everything must be avoided particularly if the data for input and potential output reports are non standard.
6.6	The need for, and the scale of, systems will depend of the size of the audit office. A large office might well need all the systems listed and more; a small office, with few existing systems might focus on computerising audit support tools, and computerising administrative systems might be unnecessary. Some administration functions, such as payroll and accounting, might more economically be handled on behalf of the audit office by another body who already have, or who are developing computerised systems.
6.7	In considering IT systems, it is important not to overlook the benefits of enabling office automation technology. This provides users with knowledge and experience of what IT can achieve and gives insight into how automation in other areas can add value. For an office with no existing IT, word processing and spreadsheets on personal computers might be a good introduction to computers.

6.9	For an audit office these could be characterised diagramatically as shown in figure 4. Benchmarking against other offices of similar size and functions is a useful way of ensuring the right focus on the potential grouping of systems.
6.10	Whatever systems are appropriate, it is necessary to determine a business value for each candidate system in order to assess priorities. This is discussed in the next chapter.

7.1	This stage focuses on establishing priorities so that best value may be obtained if the budget for the IT strategy is limited. The aim is to establish a business value for each of the candidate systems identified. It is highly unlikely that a monetary value will be established at this stage, but it should be possible to consider how such a system will affect the efficiency of the audit business overall.
7.2	At this stage the high level description for each candidate system should be refined for wider circulation. At this point it is necessary to find a way of ranking systems according to their potential contribution to corporate objectives. Of course, this might be obvious for a small office with relatively few candidate systems. But for a larger office this may involve difficult matters of judgement. One possible technique is to circulate the high level specifications and undertake a "user survey". This can be done by sending a questionnaire to a wide range of individuals in the office who are asked to score each system from 1 to 10 on the basis of its contribution to achieving corporate objectives (and not their personal preference from their particular viewpoint in the Office). Scores can be weighted for the importance of each factor. This approach is useful in both identifying a wide range of views, and in obtaining future commitment to potential computer systems. Whatever method of ranking systems is chosen, a score sheet should be drawn up to enable comparisons to be made. An example of a score sheet is at Figure 5.
7.3	A small audit office with no existing IT might wish to focus at this point on user awareness and education in considering ranking of systems. As already stated, implementation of word processing and spreadsheet packages "enable" other systems to follow.

Figure 5 : Ranking of strategic systems by their potential contribution to corporate objectives
	Objectives
Systems (ranked by overall score)	Assurance on Accounting	Assurance on VFM	Assurance on Regularity	High Standards/ Minimum Cost	Best use of staff	Recruit / Maintain High Quality staff	Best use of Non-staff Resources	Maintain External Relations	Weighted Overall Score
Financial audit support
Performance audit support
Accounts audited database
Reference database
Job budgeting
Time Recording
Payroll
Personnel
Office automation

7.4	To establish the tangible and intangible benefits of each system, once again a user survey might be appropriate. Tangible benefits are those which can easily be quantified in cash or time saving terms; such as reduced staffing or delegation to more junior staff. Intangible benefits are secondary, and may not be quantifiable in cash or time terms; for example, improved quality of output or decision making.
7.5	Potential users could be asked to score potential benefits and again these scores can be weighted for the importance of each factor. Examples of score sheets are at Figure 6 and 7. It is important to avoid becoming too bogged down in a detailed mathematical exercise in this stage of strategy. The main point is to consider contribution to corporate objectives and potential benefits in a logical way, keeping the corporate overview in mind throughout.
7.6	For a small audit office with limited resources, adopting a phased approach to ranking systems and identifying benefits might be more appropriate. The aim should be to identify candidate systems at an early stage, establish their suitability for computerisation and undertake a detailed analysis of contribution to objectives and potential benefits of only those systems which are likely to be shortlisted for computerisation in the near future.

7.7	The main deliverable from this stage of the work is a list of candidate strategic systems ranked according to their contribution to corporate objectives and potential tangible and intangible benefits.
7.8	The next step is to consider how to tackle the technological and resourcing issues involved, so as to maximise the potential benefits of the new systems identified.

Figure 6 : Ranking of strategic systems by potential tangible benefit

Systems (ranked by overall score)	Descriptions	Staff reduction	Reduced Recruit-ment	Reallocation to other duties	Work done at lower levels	Better use of equipment	Better use of property	Better use of money	Total £ 000 p.a.
Financial audit support
Performance audit support
Accounts audited database
Reference database
Job budgeting
Time Recording
Payroll
Personnel
Office automation
TOTAL

Figure 7 : Ranking of strategic systems by potential intangible benefit
	Potential Intangible Benefits
Systems (ranked by overall score)	Staff time saved	Improved Communication	Improved Quality of Output	Improved Quality of Service	Improved Quality of Information	Improved Quality of Decision Making	Improved Speed of Decision Making	Better Planning	Total Score
Financial audit support
Performance audit support
Accounts audited database
Reference database
Job budgeting
Time Recording
Payroll
Personnel
Office automation
E.g.: High = 5, Medium = 3, Low = 1

8.6	The availability of cash resources will be a key feature in considering the development plan and the phasing of it. The Senior Management sponsor of the Strategy should decide whether the necessary funds are likely to be available or whether a bid for additional funds will be required.
8.7	Review of current availability of people and their skills is also necessary at this stage. A large audit office may already have sufficient staff with the right skills to implement the strategy, but a small office with no existing IT, will need to decide whether to rely on external staff, or to train existing staff, or a combination of both.

8.8	The main deliverables form this stage are: a technological review of existing systems and proposals for upgrade or replacement; a review of data availability, problems and proposed solutions; a review of resource availability and proposals for resourcing development and implementation.
8.9	This information sets out the background for the next stage - drawing up the systems development plans.

9.2	There will always be more than one approach to implementing the desired end product, and at this stage it is necessary to build on the review of current technology to consider and evaluate the range of possible technical solutions including long term considerations. The solution is likely to depend on the number of users of each system and the degree of compatibility and integration required. While integration is more likely to be an issue for a large audit office with many users of different systems, it is important for all audit offices to consider every small system as fitting into an organisation-wide system. The prominent trend is towards integration of systems. This provides organisation-wide sharing of information across technological and application boundaries. The pace of development of IT hardware and software means that there will be advantages of tried and tested technology to be weighed against the risks of leading edge technology, but which is offering potentially greater advantages in the long term.
9.3	These factors should be carefully weighed. The aim is to gain the maximum advantage from the latest technology but to minimise the risks of a delayed or unsuccessful implementation.
9.4	Package solutions are tried and tested and reliable. But they may not exactly match business requirements, nor integrate with each other in the way required. On the other hand, a bespoke solution will require significant development effort, will not be tried and tested until implemented, and will require continuing maintenance and enhancement.
9.5	If a bespoke solution is proposed, the systems development plan should consider how best to achieve precisely what users want. Modern programming tools mean that it is possible for users to sit down with developers and work out screen layouts and functionality together, "on screen". This "prototyping" can shorten the timescale for development and ensures that users can visualise what they will be getting.
9.6	Prototyping also allows for experimentation on a manageable scale before bigger projects are attempted.
9.7	A further key factor in drawing up strategic options is timing - how quickly can the proposed strategy be achieved bearing in mind cost and resource constraints. If plans need to be phased, the dependencies and interfaces between systems becomes a major factor.
9.8	Finally, the future development path should be considered to ensure that the proposed solution will be easily kept up to date as the technology changes. Of course, only known changes can be taken into account, but there would be little point in implementing solutions that are likely to become obsolete in say 3-4 years. The important point is to decide an overall IT architecture and choose systems architecture that retains flexibility for the future to the greatest possible extent. Often this will involve compromise. So called "open systems" make it easier to replace hardware with that from a different manufacturer. However, changes of software can be very expensive, particularly for end user re-training.

10.3	Implementing an IT strategy is likely to lead to information becoming much more widely available, resulting in a more competitive environment. Some functions (and staff) may become redundant.
10.4	Improved management information and particularly the wide visibility of data should lead to improved accountability at all levels. Not all staff will welcome this. Some will see the new systems as a threat rather than a benefit. For example, time recording systems can be seen as greater management control and conflicting with the corporate objective of greater delegation. Some staff may act adversely and actively seek to discredit new systems.
10.5	It is therefore important to keep staff fully informed whilst the review is underway and to allow them to contribute as much as possible. The wider benefits of new systems must be fully explained so that staff do not just take a "what’s in it for me" approach.
10.6	Implementation plans should ensure that the data presented to users is correct and cannot be discredited. A discredited system will take a great deal of time and effort to recover.

11.1	Once the systems development plan and business impacts plans are approved, the implementation and training plan should be drawn up. This should be a realistic assessment of implementation and include all the necessary stages, for example user training, parallel running and data validation.
11.2	The production of a demonstration prototype system, or parts of a system, is a useful way of obtaining early feedback on whether what is proposed will meet user needs, and is likely to result in helpful suggestions for improved presentation of information or better functionally.
11.3	Implementing pilot projects in a limited area takes this process one stage further. Using the proposed system in the live environment in this limited way means that problems are identified before full live implementation.
11.4	Both these techniques can be very helpful in implementing systems that do not depend on a corporate database, and that run on stand alone machines. For example, audit support tools can be developed very much in conjunction with users in this way, and implemented in stages.
11.5	Whatever the system, implementation may be made in many phases, and each phase must be fully validated and tested before it goes live. The implementation plan should include sufficient time and resources for data take on and validation and for the system to be fully tested in as near to live conditions as possible.
11.6	A successful implementation will be supported by publicity material to generate enthusiasm for the new systems. This will raise user expectations. It is important that these expectations are met and that the system is not discredited through insufficient testing or data validation, or that pre-implementation publicity claims are not delivered. Continued user involvement as the development proceeds, for example, by showing the new system to staff consulted during the early stages of the strategy, helps ensure that what is being delivered is what is expected.

11.7	User training is also a key to success. Users must feel comfortable with new systems from an early stage. Ideally, training should be provided immediately before the user is allowed access to the live system.
11.8	This training should not simply teach which keys to press, but also focus on the reasons for the introduction of new system, benefits to users, the wider benefits, how the systems integrate with others as well as culture change issues.
11.9	Besides general user training, special attention should be paid to the training for senior management, as their support is critical for the successful implementation of IT systems. Their training should focus on how the IT strategy supports the business functions, the IT implementation plan and their role as managers in supporting the implementations.

12.2	Maintenance, including both hardware and software upgrades, is a significant cost factor in an IT strategy and should not be underestimated. Day to day "help desk" and support facilities must be fully resourced. In addition, sufficient resources must be provided to allow development to meet changing business requirements and technology changes.
12.3	Maintenance falls into two areas: meeting changing business requirements technological enhancements
12.4	The former should be the responsibility of a user - a sponsor for each system - and not the IT maintenance staff, whose responsibility is to respond to sponsor requirements and advise on technology changes. This approach should ensure that technology does not drive system changes, but that the technology is used to best advantage in meeting business requirements.

12.6	Once users have become familiar with the new systems they will seek enhancements. This might involve improved functionality or integration. Each will need to be considered on its own merits and costs and benefits should be weighed as with the original strategy. Any changes should be fully documented.
12.7	If a package solution is adopted, it is important to bear in mind that software packages are frequently upgraded, offering enhanced functionality, ease of use, or integration. But it can also mean that changes in software take place at the supplier’s discretion and may not match your requirements.
12.8	Keeping the IT strategy documentation up to date as changes to systems are made will ensure that data is readily available for subsequent strategy reviews, and that the groundwork does not have to be repeated.
12.9	The post implementation plan should take account of all these factors. Resources and costs should include all the elements of maintenance and consider who will undertake the work. The continuing success of the system will depend on its flexibility - the ability to accommodate change quickly when necessary - and good quality maintenance, responsive to the needs of users.

13.5	If the existing system does not satisfy the current business requirements there are three main options for migration: use existing technology but enhance functionality upgrade technology and enhance functionality replace
13.6	The choice depends on how quickly the existing technology will become obsolete, whether it can handle new requirements, the replacement costs, the resources available, or a combination of all these factors. There is no hard and fast rule for the decision, which will depend on the individual circumstances of each case.
13.7	But in reaching a decision, SAIs should bear in mind that the cost of hardware is relatively cheap compared with the costs of developing bespoke systems. A particularly significant cost of replacing systems, and one which is often underestimated, is the cost of re-training users, even when package solutions are adopted.
13.8	The ideal solution might be a progressive upgrade in stages which allows upgrade and re-training costs to be spread over a suitable period. But this is not always possible if hardware is obsolete or will soon become so, or a major change in functionality is required beyond the capability of the existing system.
13.9	The deliverable at this point - as part of the overall systems development plan (Chapter 9) - is to present the Steering Committee and Senior Management with options for migration, within the framework of an overall IT architecture, drawing up the advantages, disadvantages, risks, upheaval, costs and availability of skilled resources necessary for each. Cost must be comprehensive and include the costs of transition. Maintaining both new and old systems for lengthy periods can be expensive and must be weighed against the risks involved if the new system fails. And the review must take account of the effect on and costs of any changes needed to linked systems.

13.10	The chosen options - as with other approved proposals in the systems development plan - should be reflected in the business impacts assessment (Chapter 10) and implementation and training plan (Chapter 11).
13.11	For systems to be migrated, systems development and other plans should include data capture, data conversion, data loading and validation, user training, preparing training materials, acceptance testing and parallel running where appropriate. Particular care is necessary in planning how the switch over from the existing systems will occur and what fallback to existing systems will be provided if problems arise - for example, the period of parallel running needs to be extended until the new system has been proved. Examining these issues before the systems development plan is finalised and approved ensures that problems do not arise late in the development cycle which are costly to resolve - for example it is easy to overlook or underestimate the additional effort which may be needed to capture and validate new data outside the scope of the existing system.
13.12	Data converted from an existing system will need to be checked to ensure that it has been captured correctly. Acceptance testing is likely to reveal a number of anomalies within the data. Each must be investigated to correct data and assess the implications of the error or inconsistency uncovered, and plans must allow adequate resources for this work.

14.1	The full procedures set out in this guide are unlikely to be appropriate for small audit institutions with very limited resources. They are likely to have very different objectives, timescales and problems in mind. This chapter therefore suggests a more streamlined and targeted approach to developing an IT strategy in such bodies.
14.2	Often the first step in introducing IT will be to buy a few personal computers and to implement office systems such as word processing and spreadsheet. But even then, developing a strategy is desirable. The important point - and this is why the guide primarily deals with each stage of the strategy in turn - is to retain a logical and systematic approach. Small size or limited resources makes it even more important that best value is obtained from what is available. This means that a clear strategy must be properly planned in a systematic way. Failure to do so, could lead to nugatory expenditure and wasted effort on systems that do not support business objectives.
14.3	One approach is to streamline development into four stages. The diagram opposite illustrates how this might be achieved. The remainder of this chapter offers advice on each of these stages.

Benchmarking	is the comparison of functions and performance with organisations of similar size and character.
Bespoke solutions	are software applications that are written specifically to suit the individual needs of the organisation or users.
Business functions	are discrete components of the work of an office, e.g. management of a financial audit. They can be decomposed in a hierarchy so that at the lowest level the decomposed function represents a single activity.
Business needs	are the activities that the office must perform in order to meet its statutory or operational requirements.
Business strategy	is the top level statement of direction which articulates the aims, objectives and activities of the office, and the resources and commitments to meet its objectives.
Candidate system	are those for which computerisation offer potential benefits.
Information systems	are the IT and non IT based systems which support the business needs.
Intangible benefits	are those which cannot be quantified in cash or time saving terms.
Package solutions	are software packages that come ready to install. They are applications that are suitable for a wide variety of general purposes (e.g. word processing, spreadsheets).
Prototyping	is the iterative development of information systems, or pats of systems, by presenting users with a mock up of screens to illustrate screen layout and functionality.
Tangible benefits	are those which can be quantified in cash or time saving terms.