“Think-Build-Run” - and Insource or Outsource?

For some people the concept of splitting an IT function into logical components of “Think” (or “Plan”), “Build” and “Run” will be nothing more than a fashion statement. There will also be those who are, for personal or philosophical reasons, totally opposed to the concept. For many, especially where the IT function is small, achieving such a delineation may be impossible given an absence of critical mass in one or all areas. 

Yet for others, “Think - Build - Run” will be a logical move, allowing a sharper degree of focus for them, their people, and their business; giving them the chance to drive up quality and drive down cost. It will be, more or less, the IT equivalent of an efficient production line paralleled with some kind of interpretation of ‘Lean’. For these people, likely to be in larger organisations with larger IT functions, it might simply be ‘the right thing to do’.

For those that adopt T-B-R, there is often a follow-on question when looking at the organisational shift to the new model: Insource or Outsource? Whilst this question is, for CEOs and CIOs always there in the background anyway, T-B-R can throw it further into the spotlight, especially if there is a working assumption that the “Run” part is more or less akin to commoditised computing services. And make no mistake, much of it is. But there is a danger in falling for a too simplistic view of the world. Many people might draw an equation between T-B-R and Insource/Outsource in the following way:

But not only is this a lazy interpretation, it is also flawed. The true line of transformation we should be looking at is something like this:

And why is that?

1 - Because you should never outsource very much of your “Think” activity. This is the area where you are closer to the business, where the relationships between IT and its Customers are most critical, and where in-house expertise can add the most value. If you can truly add differentiating competitive advantage to your organisation as an IT function, then in “Think” is where you will do so.

2 - Because, whether we like it or not, a large proportion of the ‘systems’ IT functions “Build” is likely to be unique to that organisation. Either they are bespoke, one-off solutions, or they are customised versions of commercial software offerings - and sometimes very customised! (And don’t forget all the Excel Warriors..!) It is only when you start to get to homogenous, non-differentiating, more ‘vanilla’ kinds of solution that a greater degree of outsourcing begins to make more sense (and Software as a Service [SaaS] can play a role here).

3 - Because you should never outsource all of “Run”. Even if it is only the management layer that you retain, responsibility for the service still resides in-house, and CIOs need people on their teams who hold that passion and accountability. Again the question of the service being truly commoditised comes to the fore, as do things like scale, practicality etc. There are some elements of “Run” that you simply will not be able to do as well as a third party provider (or at all, come to that: think of networks…), but there may be others where there is enough local differentiation to suggest that keeping it in-house just makes sense.

Of course, other factors come into the equation such as cost differentials and arbitrage, the overall size and philosophy of the company as a whole, appetite, previous experience, in-house expertise and talent, and so on. And the feast is a moving one too, with ‘Cloud’ becoming ever more mature, and the whole notion of Bimodal ’Mode 1’ / ‘Mode 2’ projects adding another new dimension to the mix.

Inevitably the equation is a very complex one, and to which the solution is rarely simple.