The Minimal IT Function

Is it a joke, or is it a myth? “Size matters”. Well to some people it clearly does, and whether you are crowing about your in-house IT Empire or trying to recruit someone to run one, the size of that estate – in terms of the numbers of people who work there – is often quoted as the boast / carrot. Perhaps that used to be relevant in the days when you had to do everything yourself, but in our brave new world of Cloud, outsourcing, managed services, comprehensive composite service providers, applications-as-a-service and the like, surely the measure is less relevant than it used to be. Indeed, I suspect its partner measure of ‘size of budget’ may (or should) go the same way too, usurped by some kind of assessment of business value or benefit delivered.

So if we resist the temptation to think that ‘big is beautiful’ in terms of in-house IT functions, what about going to the other extreme? Just how small could your team be and still have all the bases covered? I suspect pretty minimal – but it will take a mind-set change and the acceptance of some risk to get there.

But is any attempt to ‘downsize’ simply an intellectual exercise? Well only in part. There are now a number of things in play that might legitimately drive us this way:

·         Complexity. The IT landscape is becoming increasingly more complex and the days when an in-house IT function could truly cover all bases is probably long past. For example, Telephony used to mean just ‘phones’; now it’s a whole complex eco-system of its own!

·         Breadth and depth. Even if we do try to operate the entire portfolio, it is likely we will run into skills issues, both in terms of breadth (numbers) and depth (knowledge) within the resources available to us in our organisations. We will find we can’t have all the expertise we need, or that we will be single-handed in some key skills, or perhaps know just enough to keep the lights on but not move anything forward.

·         Business drivers. One answer would be more people, but this is against a backdrop of severe business drivers that continually want us to ‘do more with less’ and where having smaller IT functions (both people and budgets) is often seen as a sign of success – at least from the CEO’s or Finance Director’s perspective.

·         Innovation. If we don’t have the people and the knowledge, then our capacity for innovation – at a very time when innovation is critical and the pace of change is frightening – will be negligible, we will always be playing catch-up, and our business competitors who have made the change and who can adapt and be more agile will always win.

So the challenge is as much one for the business as it is for IT, because that is where the end impact will be felt. And it forces us to ask a fundamental question.

If we accept that we can’t do everything in-house, then it follows that there are choices to be made. We need to decide what we ‘keep’ and what we ‘let go’. And the way we do that is to ask where we add value. Take everything else off the table, where do we in IT make the difference for the company in which we work? Where is there true tangible benefit in us owning, operating, supporting, hosting, managing etc. as opposed to third party service providers who are able – because of scale and expertise – to offer those things back to us as homogenous commodities?

I suspect it may be in no more than three main areas:

·         Business knowledge. No-one should know our business – and how IT relates and contributes to that business – better than we do. This is knowledge gained over years of experience and interaction. You can’t buy this, in spite of what some consultancy organisations might say.

·         Areas of intellectual property. It is entirely possible that we have applications or uses of IT that are unique to us, and that this IP is valuable. It might be, for example, more in the area of business process and the way we utilise IT to support those business processes; or it could be in the way we have configured our network to support a diverse geographic organisation. It could be the way we manage risk, or assets, or how we have set up our Project Office. Anything which is demonstrably ‘better’/’tailored’ than a generic norm (but resist thinking that means everything!).

·         Areas of competitive advantage. It could be that we have developed specific ‘best-in-class applications’ (in the broadest sense) that give us the edge over our competitors. Most likely this will be in the area of business applications, and should be considered across the widest spectrum i.e. including web- and mobile-based applications.

Taking all that as read, where do we start?

As with many things, it would make sense for us to adopt a structured approach when analysing our overall IT offering with a view to making the in-house component as ‘minimal’ as possible. But we must make sure we are doing it for the right reasons – or, more explicitly, that we are not doing it for the wrong ones! And the most wrong of these is to save cost. If we assume that the breadth of responsibility and workload does not go away (indeed it may increase), outsourcing more of our service provision will not necessarily save money. Yes, the internal headcount will fall and thus the wage bill, but the amount of money we spend with third parties will go up – and may increase by more than the reduction in salaries. The right reasons for undertaking the exercise (at least to see how things could look) will be to address some of the challenges to which we have already referred: complexity, breadth, depth, meeting business demands / drivers (e.g. being faster to market, more agile etc.), and innovation.

To keep things simple, I’ll assume that outsourcing IT entirely (i.e. having no in-house IT staff at all) is not being considered. And we’ll focus on the activity that gets us to a picture of what our minimal organisation could look like.

One basic principle is that, whatever discipline we are talking about, we need to retain management of it. This is simply saying that whoever does the work, the responsibility for IT remains with “us”. Therefore the most miniscule IT organisation would be a small management team with functional responsibility for each discipline. If everything else were outsourced, that’s your entire IT team; ten people? eight? six? four?

And why not?! Well hopefully because you do have some ‘value add’ to offer somewhere: business knowledge, intellectual property, competitive advantage… So here’s a detailed method you could try to get you to a potential ‘minimal IT function’.

Step 1 – Break down your function into the range of disciplines that works for you in your industry and business environment. There is no perfect organisational shape, but it could for example comprise of these things: Infrastructure / hosting; Networks & security; Service support; Application development; Project management; Governance; Procurement.

Step 2 – For each function, assess what you actually do. This could be in terms of the activities you perform (database administration, service desk call handling, project reporting etc.), and the ‘things’ you support (the telephone system, the ERP application, the demand management process, the computer room!). Hopefully it will be a large and comprehensive list; you should be impressed at the end of the exercise – “Do we really do all that?!”

Step 3 – Next, you need to take that comprehensive list from Step 2 and assess each item in terms of ‘value add’. Which elements are actually generic or homogenous activities – perhaps Windows administration or firewall management – and where do you genuinely contribute business knowledge, intellectual property, competitive advantage? The answer is unlikely to be black-and-white; you may need to scale your response e.g. high-medium-low or some such. If in doubt, ask the tie breaker question: could you get a third party to carry out the work for you? Honestly? Ignore cost, knowledge transfer and any other automatic objections you might come up with. Take that old legacy, in-house built bespoke application; surely there’s no way anyone else could maintain that?! Well be careful to divorce the mechanics of code building, testing etc. – which is an execution of skill and development process – from the design and analysis of solutions – which is where engrained business and application knowledge comes into play.

Step 4 – Finally, for each activity in your list, roughly allocate the amount of effort (in full-time equivalents) that is provided from your existing team. When you first do this, you are likely to end up with a bigger FTE number than the actual people you have – that’s wishful thinking! Your current headcount is your very real checksum and the total you need to arrive at.

Step 5 – One could now argue that, in theory, your minimal IT organisation will simply be made up of the people needed to continue to provide the high-rated value services (activities and ‘things’) from your detailed list (not forgetting to ensure you have overall management responsibility covered). However, you are likely to find that you will be dealing in fractions here. For example, one value-generating activity requires just 25% of one individual; organisationally that just won’t work. So you will need validate that it is truly high-value activity, and if so, then think through how you might be able to sensibly combine other activities to create a meaningful and practical FTE role. This is where some of the medium-rated activities will be included back into the picture – or where a high-rated activity is left out! Take some time and care over this step. If you rush it two things could happen: one, you end up with the organisation you have now; or two, your final structure will have left something out or be taking too many risks with service provision (e.g. inadequate cover for out-of-hours support).

Step 6 – Now review. Stand back and, perhaps after a few days, take a look at what you’ve come up with. Could it work? Are all the bases covered? Are the risks manageable? Is the scale of change likely to be enough to stand up to scrutiny? Does it make a good business case? And then look at it from the outside-in. Those parcels of responsibility that you now wish to buy-in from outside; are they going to be attractive to a service provider? Will you be taking an impractical proposition to market? Are you going to outsource activities that are already well-managed and under control – or are you simply trying to give your chaos to someone else?!

At the end of this process, the key questions will be:

·         Is the outline proposition practical?

·         Is it different enough?

·         Is it commercially attractive / does it stand up to scrutiny?

·         Can you sell it?

·         Do you want to sell it?!

Oh, and if Steps 2 through 6 are a little too much for you, then take your output from Step 1 and decide at the macro level what’s in or out. It will be quicker for sure, but too crude to give you the best chance of getting to the right answer. And even worse if your breakdown in Step 1 is actually flawed…

-*-

About the author / copyright

Ian Gouge is widely experienced in business-driven Information Technology, culminating in significant achievements majoring on organisational and process change, and with a proven track record in turning around / re-engineering IT functions. He possesses in-depth experience of change, transformation, IT delivery, customer and supplier engagement, and broad International exposure. Also the author of management books on the topics of IT Strategy and Project Management, the impact on IT of e-Business, and the IT Organisation.

This material is copyright of Ian Gouge © 2012. All rights reserved. Any similarity to actual IT or business organisations is entirely coincidental and unintentional.

Any redistribution or reproduction of part or all of the contents in any form is prohibited other than the following:

·         you may print or download to a local hard disk extracts for your personal and non-commercial use only;

·         you may copy the content to individual third parties for their personal and non-commercial use, but only if you acknowledge the author and blog as the source of the material.

You may not, except with express written permission from the author, distribute or commercially exploit the content. Nor may you transmit it or store it in any other website or other form of electronic retrieval system.