Organising the service-oriented IT function

This is first of a series of follow ups to my blog post about a service-oriented operating model for IT. These posts are based upon some of my insights and experience of putting this model into practice and I hope they will either help you develop your own thinking or provoke you to share your own ideas.

In these follow up posts I am going to cover:

1. engaging the rest of the organisation
2. mapping out the IT value chain
3. developing the IT bill of materials
4. designing the IT organisation structure
5. aligning funding and resources
6. implementing the change.

Most of the comments and reactions to the original blog post concern organisation so I am going to start there although, logically, it is the fourth step.

If you can’t wait for more on the earlier steps you could look at an article in CIO magazine written by Craig Symons of Forrester Research. Craig’s article on running IT in a more business like way includes some similar concepts. You could also look at a techrepublic article by @JeanneMorain. Jeanne writes about migrating systems to the cloud but includes a service model which has parallels with the IT bill of materials

Let me know which of the other steps you would like me to cover next. Use the comment box or Twitter button at the end of this post.

Structuring a service-oriented IT department

Quite often the IT industry and the IT media conspire to paint IT as special and unique. In some, exciting ways I think this is justified (which is why I started @CIOPortfolio) but in many respects it is not. Although IT involves highly specialised tools and fast moving technology many aspects of how IT organisations work and need to be managed apply to any other discipline or any other team of people. A considerable amount of good practice and thought leadership is available on the subject of organisation design. Don’t be fooled into thinking that you can design the IT organisation without taking these proven basic principles into account. Rather than try to repeat the generic good practice let me pick out some key aspects which, although they might not be unique to IT, have particular significance or are often neglected.

There are limits to IT economies of scale

There are a number of practical constraints which are often neglected in the design of the IT organisation. I have already dedicated another blog post to this topic and listed out a number of factors which can be used in the organisation design. An illustration of how these factors can affect the IT organisation can be seen in this simplified example for an IT shared service. Various trade-offs have been made to allocate activities to different types of operating unit. Some of these have been aligned with the IT function, others with specific business units. At a more detailed level some of these organisations may be split along geographic lines.

Use all of the pieces on the chess board

When you talk about “IT” in your organisation what do you mean? Is it:

• everyone who is employed in the IT department
• everything under the authority of the CIO or head of IT
• all of the computers, software, digital networks and the specialists who keep them working
• everyone who is involved in making decisions about IT?

In almost every organisation these versions of IT will be different. So which IT are you going to organise? How you answer this question will have a huge impact on the scope of your design and the impact of making changes. To make the most of the service-oriented operating model you need to start with a very wide scope. I find it helpful to encourage people to distinguish between a conceptual IT function including all IT related activity and the physical teams or departments which might be labelled as IT.

To help illustrate this look at the generic structure in the diagram above. This is a high level view of the IT functions that need to be performed in any organisation. Many of these functions will be carried out in collaboration with users and business managers or supplier staff. For example, to manage the performance of IT services internal IT specialists will need to collaborate with supplier staff and users. They will need to look at the performance of IT equipment and engineers against their targets. They will also need to consider user behaviour and how the level of demand compares to agreed business plans. The demand factors have just as much impact as the supply factors and the IT function needs to manage both.

Taking the functional view of IT allows opportunities for improvement across the IT value chain to be explored. It can also help to challenge assumptions about what are “IT” activities and “business” activities which would otherwise get in the way of designing the optimum organisation. It should be obvious that this cannot be done in isolation by the CIO and their team. The design of the IT organisation is an enterprise wide activity.

Looking back at the example shared services structure earlier in the blog you might notice this blurring of boundaries is explicit. Deciding where these boundary roles will report (into the IT chain of command or into the business unit chain of command) and what “dotted-lines” are needed is a key outcome of the organisation design process.

Maintain the workload balance

By the time that you are designing the organisation structure to support your service-oriented operating model for IT you will have built up a number of different views of the IT operation. These will include:

• services
• value chains
• bill of materials
• functions and activities
• processes and roles

A common next step is to group roles under a management hierarchy and start implementing the structure. This is a mistake - the design process is not yet complete. At this stage the roles are just “virtual” jobs which may not be very effective in reality. A common problem is that service operations (see the IT function diagram above) includes a large number of complex activities but relatively low workloads. Implementing this structure directly can lead to over resourcing and potentially increased bureaucracy as this group expands its work to fill the time available. Another common problem is that service delivery workload can be quite volatile and the overhead required to manage the peaks is not considered.

To complete the picture the service demand model (which will include risks and tolerances) needs to be pushed through the various views of the operation to create a model of role workloads. The roles can then be split or combined into manageable “physical” jobs with reasonable coverage for peak workloads and staff turn-over.

What’s next?

What challenges have you faced in organising IT? Add a comment to this blog or use the Twitter button below to let me know what you think.