Who Owns Information Technology? The 1998 Charity Finance

Many charities, when faced with the decision to invest in information technology, are like a rabbit, mesmerised by the oncoming lights of a car.

Deciding to spend money on IT should be viewed as a commercial decision which needs to be justified in precisely the same way as deciding whether to open a new project or what pay rise to allow in the coming year. Instead we wrap the subject in mystique and treat it as something special that only certain well-qualified ‘technical’ people can have a view on. Indeed, by calling it an ‘investment decision’ we tend to take IT outside the normal business processes and end up making it a battleground within the organisation. The only comfort is that charities are not alone – the same problem pervades much of the commercial sector too.

Four main questions cover most of the database which the pundits now often refer to as IT governance. To put it another way, a reader who has clear answers in their organisation to the following four questions ought to be avoiding the ‘mesmerised rabbit’ syndrome:

(1) Who owns IT?

(2) Who pays for IT?

(3) How do we co-ordinate IT?

(4) How do we control IT projects?

Who owns IT?

In some respects the answer to who owns IT and who pays for it should be one and the same. However, this is often not the case. At the very least, perceptions of who owns IT can differ greatly within an organisation. In the past, the Barnardo’s experience has been very much one of the IT department being seen as the owners of all things IT related, passing on the costs to a bemused and disenfranchised customer base, much like the utility companies of old charging the captive domestic market.

Following a recent review of Barnardo’s IT (carried out with the assistance of Z/Yen Limited) a new analogy is being worked towards – that of an IT department acting like Railtrack in the provision of the IT infrastructure (the track and signalling systems on which the train operators run their trains) and the user departments responsible for and owning the applications (the trains that run on the track).

Even within this clear division of roles there is a dilemma. How can the project leader in any one of Barnardo’s 250 project sites around the country really feel as if they ‘own’ the application? Someone has to make the decision to go ahead and spend often considerable sums of money, and this decision cannot be taken on the basis of a consensus opinion. The balancing factor therefore has to be the establishment of a clearly focussed user group, drawing membership from across the organisation, who can identify the issues and needs that are arising and who can moderate initiatives that are emanating from the centre.

One interesting logical development that flows from the concept of the user owning the application is that it is the user department which commissions the purchase of the application, and therefore can choose from whom they will purchase it. The in-house IT department becomes another supplier from whom tenders can be sought but who will not necessarily get the work unless they are able to demonstrate their competence to provide the service. The plus side of the equation from the IT manager’s point of view is that the IT department does not have to be diverted by non-core systems and may choose instead to allow a system to be supported externally, freeing up resources to manage the more strategic side of the business in house. Given that most IT managers are closet Bill Gateses, this world view can prove particularly attractive.

Who pays for IT?

Having sorted out the relationships above the answer to the question of who pays becomes simple – the owner! The spend on a particular application becomes a simple budget allocation decision for the user department: ‘Either I buy this new application or I can recruit two new managers to develop another initiative. Which is more important to me?’

For many organisations consideration also needs to be given to whether funding partners should be expected to share the cost of IT. On the assumption that an IT application is proposed in order to enhance the service provided, then the answer ought to be an unequivocal yes. If we cannot demonstrate improvements to the service then why are we taking the IT application on in the first place? Partner funders in this context can mean direct partners (for example, local authorities in the contract environment or corporates and trusts in sponsorships) and/or indirect partners (such as individual donors).

The decision to expend should be taken in the same way as other expenditures, within normal authority levels. IT expenditure is prone to ‘fudging’ between capital and revenue definitions, so rules should be simple and clear. At Z/Yen, for example, new IT equipment is all treated as capital (and written off over three years). Operating systems software (for example, Windows 95, Windows NT) is deemed to be part of the equipment for the purposes of budgeting, authority and accounting policy. Application software (for example, Office ’97, financial systems, risk modelling and time recording programmes) is treated as expenditure and written off in the year it is incurred.

Recharging policies should not be allowed to confuse the fundamental issue of how much cash has been laid out, and should be defined so that the spending department is given a genuine choice between the IT spend and alternative uses of the funds. Often the budgets for IT are held centrally and the game plan for managers is a question of: ‘How much of the central pot can I snaffle for my own department?’

How do we co-ordinate IT?

The pure marketplace model outlined above has one fundamental flaw in the IT context – if we allow the user to be paramount in all matters concerning IT, then they will tend to go off and do their own thing, resulting in a proliferation of incompatible systems and equipment. This will lead, if we are not careful, to the organisation losing any form of control over IT strategy.

A worst, such freedom can lead to an inability to achieve a system’s objectives – for example, imagine your organisation’s e-mail system if everyone is free to choose their favourite e-mail program – at best, uncoordinated freedom will simply push up the cost of ownership of IT to unacceptable levels. If the reader really wants to depress themselves, an exercise working out what IT really costs their organisation in terms of pounds per annum per user is guaranteed to provoke a moment’s pause for thought – even if the pause is simply for mental arithmetic because the file server which holds the spreadsheet program is down.

Given the need to control this vital area, the IT department should retain a clear responsibility to coordinate the IT standards to which the organisation will adhere: defining the technology platform that the organisation is prepared to sustain, the database strategy, the operating systems and so on. Any IT project proposal that wishes to go ‘off road’ from the standards needs to be carefully justified and in particular the additional costs should be recognised in full. This is significantly different from ‘just saying no’ to any proposal for a solution which is outside current standards.

Even with standards in place there is still the need for system integration and co-ordination, particularly where systems are proposed that have a pan-organisational aspect to them. It is important therefore that the overall IT strategy is owned at the highest level within the organisation and that project proposals are put through a common filter to check on consistency and application of the ‘rules’. In practice the IT department will be integral to the development of new ideas and should have an early eye to possible problems, but it is important that those taking decisions are working within a clear project framework (or ‘meta process’). Here too the user voice is important in helping to set priorities and to spot potential conflicts of interest. For larger organisations complex relationships exist between top management, user voice, IT department, operational department and so on. In such circumstances, a defined constitution or set of governance principles helps to ensure clarity of roles, responsibilities and decision making.

How do we control projects?

Most people would not set off on a driving holiday without a route map, nor would they buy and sell their homes without costings and contingency plans. But IT projects, which are inherently risky, are all too often initiated on a wing and prayer. Recent surveys of IT projects indicate that risky in this context really means risky. For example, the Standish Group found in 1995 that only 9 per cent of systems projects come in on time and on budget; the University of Sheffield’s Institute of Work Psychology concluded that 80 percent of business systems projects are late to a material extent.

Controlling IT projects is a substantial subject in its own right; we can only offer a whistle stop tour of good practice in this article. We shall focus on the planning stage, which should in any event set the framework for sound project management and thoughtful evaluation of projects.

At the planning stage, you should not proceed without a business case which has a clear project definition, defined benefits (yes, some voluntary sector outputs, outcomes and impacts are difficult to measure but it should at least be possible to define them), risk adjusted costings (you know what you want it to cost, but how much might it really end up costing?), project organisation (at least a project champion and a project manager) and an implementation plan with milestones and deliverables.

Good project management requires clear thinking, an ability to make decisions, sometimes tough ones, in a rigorous approach to achieving the project’s objectives. You should revisit some of the planning stages as the project progresses, especially if the goal posts move. You should also be prepared to pull the plug on the project if the goal posts move such that the expected benefits no longer outweigh the risk adjusted costs. Remarkably few projects are evaluated post project, despite the fact that the post project review can yield substantial benefits, both for the project being reviewed (ensuring that benefits sought have been gained, and if not, working out how to achieve the missing benefits) and identifying learning points for future projects. The following questions as a minimum should be helpful:

¨ What did we set out to do?

¨ What actually happened?

¨ Why did it not work out the way we thought?

¨ What did we learn from the project?

We began by posing four questions. The table below shows each of those four organisations together with the principles which we believe organisations should establish in order to address those questions.

For larger charities most of the principles require significant thought, but substantial benefits accrue from having clear principles. Smaller charities should not shirk the task of establishing these principles; most of the principles are quite easy to establish in smaller organisations too and can be most beneficial.

In IT governance, as in so many areas, charities are really no different from commercial and public sector organisations – and fewer rabbits need die in the process.