veryard projects - innovation for demanding changesystems engineering for business process change

on this page
what is infrastructure?

planning and accounting

who pays for infrastructure?

town planning analogy

IT example

reduce extent of infrastructure


elsewhere on this website
veryard projects home page

organic planning

business case (pdf)

please contact us

Infrastructure and its Cost-Justification

Richard Veryard, December 1997

This page forms part of an argument against top-down planning. For the main argument, click here.

One of the main reasons why top-down planning is thought necessary is that it includes or enables the planning and funding of infrastructure. This page discusses the alternatives to top-down or central planning.

What is infrastructure?

There are several levels or types of infrastructure in IT:

Production infrastructure The hardware, software, procedures, skills, and other facilities required to run information systems
Development infrastructure The hardware, software, procedures, skills, and other facilities required to build and maintain information systems
Information infrastructure The central core databases, on which all information systems are dependent, such as Customer database or Product database
Decision-support superstructure General-purpose query and data manipulation facilities that sit on top of the information systems, including report writers, data extracting, spreadsheet and graphics facilities
Management overhead Including all required administration and coordination

Planning and accounting

Although planning and accounting are closely linked within most organizations, it is not necessary that they follow the same structure. Planning says: this is a good idea, it will generate more benefit (over time) than it costs. This infrastructure is worth having, because it can be paid for. It doesn’t necessarily specify how it will be paid for, in terms of how the costs will be allocated between different organization units over time. This is a matter for accounting.

Obviously, nothing should be planned unless there is a cost distribution algorithm that will leave everyone no worse off (and at least some better off). How can we prove (or at least produce a plausible and reasoned argument) that something can be paid for?

The investment decision may be made by a single manager or board (single funding), or may be shared between several different managers (joint funding). In the case of joint funding, there will be some agreement in advance how the costs and risks are to be shared, although this agreement may sometimes be vague or implicit, with the details to be negotiated later, perhaps after the actual costs and benefits can be measured.

In a hierarchical organization, the infrastructure is usually owned centrally, with some hierarchical charging mechanism to allocate actual costs to the relevant organization units. In a market-oriented organization, infrastructure is owned by the unit or units that have funded its development, who can charge horizontally for its use.

Among market-oriented organizations we include highly decentralized holding companies, where the subsidiaries may trade voluntarily with one other, or not, without interference from the parent company. We also include confederations and associations of companies, with separate ownership, but with some shared operations or interests. For example, many Stock Exchanges and Commodity Exchanges can be seen nothing more than an organization owned jointly by member companies (i.e. brokers and dealers) for the purposes of infrastructure; these members may elect a council for central planning of investment in infrastructure, or they may adopt the market approach, with the larger members selling operational services (i.e. infrastructure) to the smaller members.

There are four combination of these factors, with one or two approaches per combination, making five alternative approaches altogether.


Single funding

Joint funding

Hierarchical transactions

1 Centralized 2 Decentralized
3 Coalition

Market transactions

4 Entrepreneurial 5 Joint enterprise

Coordinated funding - alternative approaches

1 Centralized Top management estimates the total benefits, which are compared with the estimated total costs and the project risks. Although the organization units may be consulted before the investment decision is made, and may participate in the detailed specification of requirements, they are usually given no choice whether they use the infrastructure or not. Top management has the power to allocate charges between organization units as it sees fit.
2 Decentralized A provisional allocation of the costs between organizational units is produced. If the manager of each organizational unit is prepared to bear his/her share of the costs (based on a calculation that his/her estimated benefits exceed his/her estimated costs), then the investment goes ahead.
3 Coalition The organization units funding the investment need not include all of the organization units expected to benefit from the investment, as long as they can estimate enough benefit between them to justify the project. The use of the infrastructure can be extended later, which will bring further reduction in costs to the original participants, but this is an added bonus.
4 Entrepreneurial One organization unit invests in infrastructure, on the assumption that this infrastructure will be of use to other organization units. Depending on the nature of the organization, the use of the infrastructure can then be traded horizontally, either on the basis of a negotiated financial cross-charge, or in return for some other benefits.
5 Joint enterprise A group of organization units agrees to fund infrastructure costing more than they together can justify internally, on the assumption that this can be traded with other organization units later.

From a rationalist point of view, the central planning approach is clearly best. It is the only one that completely balances the total costs with the total benefits, and ensures everything is included, nothing is counted twice, and all risks are properly considered. So why don’t we do all our planning this way?

The rationalist point of view ignores two things. First, that the amount of information available at the centre is limited. Its knowledge is necessarily less (in quantity, accuracy and timeliness) than the sum of the knowledge of the parts, since there will always be some selection, distortion and delay in reporting information from the periphery to the centre. This selection, distortion and delay is repeated at every level of the hierarchy, even with the most up-to-date computerized communication systems. And second, that the ability of the centre to handle complexity is also limited. In a totally centralized system, it is only in the centre that decision-making skills can be developed, and these skills will always be over-stretched.

Therefore, based on inadequate information, and limited capacity for coping with complexity, the centre may not be able to make any better decisions than the periphery, and its mistakes will be bigger and more disastrous. After all, if central planning worked perfectly, the Soviet Union would not have collapsed.

To say this is not to dismiss the idea of central planning altogether. Many centralized organizations do survive and thrive. Central planning is common in Japan and Western Europe, and is not unknown in the United States of America. All successful organizations have a moderate amount of central planning, balanced against some local autonomy. The right balance varies from one organization to another, and from one culture to another. Some organizations, seeking the ideal balance, swing violently from one extreme to the other: total decentralization one year, followed by central power the following year. Pragmatists (and Taoists) stick to the middle way.

One of the problems with the coalition solution is the fear of the free-rider. Managers of organizational units often find it difficult to forget that they are competing with one another. Thus if one manager doubles revenue at reduced cost, only to find that another manager has trebled revenue and halved cost, the first will be made to feel a failure. Even if the costs are shared equitably between organizational units after the project has been completed, the manager(s) who took the original risk may feel inadequately compensated for having taken the risk in the first place.

Who pays for infrastructure?

With any resource that is to be shared between several users, there is always a problem allocating costs. Whatever algorithm you come up with, someone is bound to object. Indeed, it is perfectly possible to come up with an algorithm under which everybody believes themselves disadvantaged. (Technocrats take this outcome - perhaps rather optimistically - as a sign that justice has been done after all.)

Note: the planned distribution algorithm may include contingent elements, as long as the risks are properly balanced. In other words, there may be different algorithms for different scenarios.

Since the actual benefits from the use of the resource are likely to differ from the expected benefits, there will inevitably be some users who would do better sharing costs according to the expected benefits, while others would do better sharing costs according to the actual benefits. Even when algorithms are agreed in advance, based on the expected benefits, it is common for user departments who have done comparatively less well to argue for a ‘fairer’ redistribution of costs.

However, there is an important difference between social distributive justice and distribution within an enterprise. Whereas a human society usually contains people who do not contribute economically to the society, and have no prospect of doing so in the future (perhaps the old, the severely handicapped, etc.), an enterprise should not include any parts that do not and never will make a nett contribution to the objectives of the enterprise. This applies both to profit-making organizations and NFPs (Not-For-Profit organizations), although in the case of NFPs, the contribution may be difficult to express in economic terms.

However, this may not be reflected in the internal accounting systems. Some organizations have so-called cost centres, to which costs are allocated, but whose benefits are not directly accounted for. This does not prevent planning, as long as the benefits from the investment can be estimated.

Town planning analogy

If a builder puts an office block in the middle of nowhere, who pays for the transport links and utilities? There are several possible approaches:

  • The builder pays, and this cost is absorbed by the tenants of the office block, in return for the privilege of seclusion. However, this makes the area very attractive to other builders, who can then take advantage of an existing low-cost infrastructure. This may then erode the benefits to the first tenants.
  • One builder (or a consortium of builders) must plan to build enough office space to cost-justify the required infrastructure.
  • The local authority and utility companies pay, and this cost is spread across the area/region/country.
  • The local authority and utility companies pay, and this cost will be spread across future users of the infrastructure.
  • The first office block makes do with inadequate infrastructure, until more office blocks are built nearby. When sufficient ‘critical mass’ is attained, a proper infrastructure can be cost-justified and built.
  • Note: there are important planning questions as to whether we want a cluster of office developments in this particular area. What we cannot afford is to have infrastructure that brings less benefit than it costs.

    The differences between London Docklands and Paris La Defense are instructive here. In London, although the funding of public transport links became something of a political question, the Conservative government was able to demonstrate the success (in their own terms) of its hands-off approach to planning, since large amounts of cheap office space was made available to civil service departments and private sector companies, mainly at the expense of Canadian and Scandinavian property companies, without public funding. However, critics of the Docklands project would adopt different evaluation criteria.

    IT example

    One large organization had the following planning dilemma. Several large application systems were being developed. Each would require substantial investment in telecommunications. Furthermore, the telecommunications links had a significant installation lead time. The group responsible for installing these telecommunications links therefore put pressure on the systems development projects to specify the number of users that would be connected to each systems, from which locations.

    The system development projects were not able to determine this, because the user organizations were undergoing a fundamental rethink of their locations.

    One solution might have been for the telecommunications group to provide telecommunications links to all major offices buildings, on the assumption that these could be allocated to the different application systems at a later date. There would of course be a risk that the capacity thus installed might not be best distributed, but this would be offset by the advantages of being able to plan well in advance.

    However, because the telecommunications group had no budget for such anticipatory planning, and could only install telecommunications links based on the business case for a specific application system, the organization was unable to exploit this planning flexibility. The telecommunications infrastructure had to be tightly coordinated with the development projects, as a matter of policy.

    This kind of coordination may appear to be necessary to ensure money does not get wasted on unnecessary infrastructure. However, it often prevents planning decisions being taken at the best time. Either the application projects must seek premature closure on questions of user distribution, or the telecommunications group must risk delay or excessive expense in trying to provide links at short notice.

    Reduce extent of infrastructure

    The problem can be eased, if not solved, by applying the principle of subsidiarity. This principle states that central planning only applies to those things that require central planning.

    Some IT planners seem to think that because some IT investment has to be centrally planned, it is therefore a good idea to apply central planning to all IT investment. Log-rolling tactics are used, in which large investment packages are put together, from which every decision-maker will gain something.

    This approach is ultimately unmanageable, since nobody can realistically assess the total costs and benefits of such a large package. Investment decisions are taken for the wrong reasons, development and implementation projects are inflated in size and risk, and there are too many failures for comfort.

    Instead, the approach should be to prune down all global infrastructure proposals, to exclude any facilities that could be provided locally, and concentrate on small manageable elements of centrally planned infrastructure.


    There are several alternative approaches to the planning and design of infrastructure. The choice of approach will depend on the enterprise circumstances and culture.

    If central IT planning is merely a devious way of burying investment in infrastructure that could not otherwise be justified, then it should be exposed and abandoned. This paper argues for focussed planning, to enable each component to be judged on its merits. Although investments sometimes cannot be judged in isolation from one another, that is no reason to go to the other extreme. If central planning is required for elements of infrastructure, then focused techniques should be developed for planning and accounting for these specific elements.

    This document is an adapted extract from Chapter 3 of my book: Information Coordination: The Management of Information Models, Systems and Organizations (Prentice Hall, 1994).


    veryard projects home page.

    This page last updated on June 21st, 1999.
    Copyright © 1994, 1997, 1999 Richard Veryard


    Please send feedback to the author.