Last updated: 28 March 2009

This subject is given an in-depth treatment in our publication on the subject:
Read the contents  pages of our Briefing

Structuring the IT function: 
dilemmas and themes

The effective IT reporting structure

It is sometimes said that organization structure is less important than processes, culture, and people themselves. Yet companies with well-structured roles have an advantage over those whose structures and roles create destructive tensions, gaps or overlaps in accountability, or whose jobs demand superhuman qualities. Clear accountability, and roles that focus on the right things and that fit together well must improve the performance of the organization.

Today, many organizations are re-examining how their IT functions are structured. What is the best way to structure the IT function? And what's happening on IT organization structures generally? As so often, there is no single answer to questions like these, but this article might help those who are thinking these questions through. It is derived from parts of a Diaz Research Briefing, "Structuring the IT Function".

The classic IT functional structure

The classic organization structure for IT consists of a development area, a services area and a planning or strategy area, though there are countless variations on this functional theme. (Operations, technical and  customer or user support areas, or some combination thereof might for example replace the single services area.) This kind of structure was almost universal in the early days of IT. It is still common in smaller IT functions, and it is also found in some larger IT functions where there is a need for highly integrated systems. Elsewhere a range of alternative organizational models has replaced it, though even in these some core features of the classic model persist. A good example is the separation of development from operations, still the most salient feature of IT organization structures everywhere.

What factors drive the design of the IT function?

The biggest single factor is the business structure. Loose conglomerates usually have a largely devolved IT function. Tightly knit companies with lots of synergy and information flow across component parts will be much more centralized. But within centralized and devolved models there are many variations. These arise as businesses seek ways of achieving certain other objectives, or design drivers.

One such driver is efficiency or cost-efficiency the need for which might mean that, despite a desire to devolve, some centralized elements are retained to exploit potential economies of scale. So the provision and management of infrastructure may be done centrally.

Another such driver is the nature of the business-IT relationship. Some businesses expect IT to provide leadership in redesigning processes and information flow across large areas (e.g. supply chain). Others simply want IT to be responsive – to act as an internal service provider, meeting the needs identified by the business. Some fall somewhere between these extremes and want to develop a business-IT partnership. This leads to all kinds of ways of managing the business-IT relationship, ranging from the formal central IT Steering Committee to the introduction of devolved teams, with or without formal Relationship Management roles.

The need for effective delivery can also have implications on how IT is structured. This may include project management structures and end-to-end service management structures.

Finally, a factor that is sometimes overlooked is that of learning. Devolved IT functions, for example, often find that their people learn more about the businesses they serve, but their technical and design capability may be stunted. This can lead to steps being taken to compensate for this – processes to share knowledge, to move people around or loan them across the business.

In general, the relative importance of these drivers varies from company to company, as do the business and technical requirements and this explains the wide variations in IT organization structure today.

Shouldn’t we structure to suit the managers we have?

It has at one time or another been fashionable to assert that the organization must be designed round the managers available. Mostly, however, the opposite view has prevailed: an effective organizational blueprint must be designed, and only then will the emerging management structure must be populated with those who have the required capabilities.

The truth usually lies somewhere between these two extremes. IT organizations are usually designed with business objectives and rationales in mind, but they do tend to undergo some modification in the light of the people available. Such modifications might include splitting a large department up, or putting two areas together, to match the capabilities and aspirations of existing candidate managers.

What are the principal organizational models?

The principal models can be defined in terms of two aspects:

- How centralized or devolved they are

- How they manage delivery, relationships and resources.

Looking at the centralized-devolved aspect, Diaz has identified and classified the spectrum of solutions as shown here:

C-D1, the centralized model, is used in smaller businesses, and in businesses where tight integration of systems across many functions is critical.

C-D2 is where business application systems teams are positioned more or less uniquely against specific parts of the business. The heads of those teams typically will form part of the local business team.

C-D3 takes devolution a step further and puts application teams within businesses, where they report to the local head of business unit or chief executive. In C-D3 the infrastructure is provided centrally, giving economies of scale in hardware and in scarce skills.

C-D4 is a model used in some groups, where the centre orchestrates: it leads the process of formulating strategy, facilitating learning across the organization, while all delivery is controlled within business units.

C-D5, the totally devolved IT function, creates a series of IT functions each of which can be characterized as C-D1, C-D2, C-D3 or C-D4 so it is not a fully separate model.

What about relationship management?

A model that gained ground in the 1990s was the account management model - more commonly now called the relationship management model.

Here, in addition to the usual 'delivery' areas such as development, operations, help desk etc. there are relationship managers that orchestrate the relationship that IT has with a nominated part of its user base (e.g. Marketing, Customer Services). They typically have few staff and their role consists largely of planning (including financial and high level project and service planning), ensuring that new requirements are understood and pursued, managing user expectations, reviewing IT's performance, pursuing any breakdown in communications and in general marshalling the resources of IT round the needs of the nominated customer base.

There are a vast number of variations on this theme. Perhaps surprisingly, some organizations have separate relationship managers for 'development' and for 'service' issues. Some assign the management of development resources to the relationship manager; some assign business analysts only to the relationship manager; others only assign lower level service analysts to the relationship or account manager. This model, and its variations, is used in many IT functions today.

Variations on managing delivery

The management of delivery is generally regarded as one of the better-understood areas within IT, certainly compared with managing relationships and resources. Nevertheless, IT Directors often introduce organizational innovations designed to improve delivery.

One such is the introduction of professional project management approaches and roles, which may result in the creation of a central project function which manages projects across the whole of IT.

Developments in managing resources

There has been much debate about how resources are managed. Some companies introduce resource pools, especially into project areas such as in system development. In some IT functions this means that the day-to-day supervision of the individual is separated from the accountability to develop, train them and generally provide management continuity.

This model is often seen in medium-large consultancies where there is a large amount of project work and a high rate of change. The effectiveness, or usefulness, of this depends on factors such as average 'assignment' size, project mix, and size of organization as well as on the capabilities of the managers and the HR processes used.

This use of resource pools can be problematic in IT functions, especially where the rate of allocation and re-allocation of resources is not particularly high. In these circumstances the role of the resource manager, in terms of providing continuity, may be seen as superfluous.

In practice, there is a huge range of definitions of resource pool working, with some amounting to little more career advisors.

Making it happen

How companies approach the organization design task is determined by their circumstances, the personalities involved, and the relative priorities they assign to a number of factors such as efficiency, learning, the nature of the business-IT relationship, the availability of competent managers etc.

It is tempting to think that an IT Director or CIO could sit down, with one or two colleagues and consultants, and sketch out a complete new structure in a few hours. They could then pencil in names against each job. This 'smoke filled room' approach ends frustratingly, and with a loss of credibility, because IT Directors and CIOs do not as a rule understand the details of how their function or how the people in it actually operate. Nor might they know the personal aspirations of all the people involved. And of course the people who have to make it happen - their direct reports and key managers further down - may not want to take the jobs allocated to them, or they may have other  ideas (better, or worse) about how to approach the task.

Restructuring projects must be structured to balance top-down design with the involvement of those affected. They are not exercises in democracy, but involvement in the design process does mean that approaching things this way takes a little longer, but gives much better results: people understand the structure, understand why other alternatives are not so good, and are committed to it.

Contrast that with the situation many of us have seen: an IT Director or CIO publishes a new structure, complete with a new team sheet, and many months or even years are spent fighting patch wars, trying to clarify what was in mind when the structure was published, debating overlooked alternatives, trying to get key people back 'onside' and eventually reversing some of the proposals.

By properly structuring the organization design process, all such messy debates are surfaced and decided on sooner. Better ideas are flushed out sooner. The structure will be both better and more widely accepted, and therefore more effective.

Interested in reading more?

This article is a very brief overview of the subject. More details can be found in Diaz Research publication 'Structuring the IT Function: Dilemmas and themes in the design of the IT organization', Diaz Reference 3009/2.

This highly specialist publication is not included in our programmes but can be bought separately.

Read the contents pages of our Briefing on this subject