In these follow up posts I am going to cover:
- engaging the rest of the organisation
- mapping out the IT value chain
- developing the IT bill of materials
- designing the IT organisation structure
- aligning funding and resources
- implementing the change.
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?
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:
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 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.