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.

Wither ITIL?

Established now as perhaps the de facto standard for service management operational processes and procedures, ITIL (Information Technology Infrastructure Library) is the default starting place when thinking about how we ‘do’ IT service. Notions such as Change, Incident, and Problem Management have all entered the IT lexicon as familiar disciplines which we pursue and in which we strive to excel.

ITIL is certainly based on sound principles, and – properly embraced and adopted – can bring real value to an IT function and hence to the business it supports. Having said that, I do wonder if we might have lost the plot a little bit…

I draw a parallel with Prince2, the similarly accepted default project management standard. Developed primarily as a tool with which to run large public sector projects, it occupies the kind of standing to which ITIL is now close. The problem with it, though, is that at a fundamental level it doesn’t work; it guarantees nothing. If Prince2 did exactly what it said on the tin, then why do so many projects adopting it still fail – and massive value public sector projects in the UK continue to do so spectacularly?

Looking at ITIL (and keeping Prince2 in mind), there are some obvious concerns about where we are with it today.

It’s getting more complex. ITIL started as a number of volumes (the ‘library’ in its title). The move from Version 2 to Version 3 has seen a significant increase in the numbers of books in the library, and an increase in the numbers of processes and procedures proposed by it. Proponents may argue that this is necessary to reflect the current IT world, to ensure better services etc. They may be right. They may not.

Has it become an intellectual exercise in its own right? This explosion of breadth and depth within ITIL could potentially be seen as becoming an intellectual exercise in its own right. ITIL has now an industry of its own. One can imagine the clamour to be part of ITIL v4 (should there be such a thing) where the numbers of volumes expands once again, the qualifications burgeon, the specialist consultants multiply…

An excuse, not a tool? Adopting ITIL guarantees nothing. Just like Prince2. Are we embracing ITIL more as an excuse than a tool? Does it allow us the opportunity to actually not think about the situations we face on the premise that ITIL will fix it? And if it’s not quite there, do we go further in our over-engineering to pursue an idealised vision of a ‘real world’ where simply nothing goes wrong? There are no silver bullets.

I think ITIL – or at least the principles behind it, rather than the ‘thing’ itself – offers true value. Indeed, adopting some of the underlying principles are essential in providing solid IT services. But have we lost our way in that the adoption of ITIL becomes the end in itself, rather than the true outcomes for which we strive – and for which ITIL may not be the best tool, or the only tool, or indeed the right tool. Are we asking ourselves the right questions? Maybe ITIL has some kind of shelf life – like an old movie actor known by everyone, yet everyone also knows they are past their sell-by date.

Heretical stuff.

I recently saw a job advertised where there was non-negotiable application criteria that demanded an ITIL qualification. Adoption of such a crude instrument could actually lead to the preferential recruitment of people with specific pieces of paper (qualifications) over those who have the real scars of battle in providing good quality IT services. What would you rather have, a soldier who had a diploma in rifle shooting, or the best marksman in the world minus the diploma?!

At the very least we owe it to ourselves to take a step back from our ITIL programme, processes, initiatives and metrics, and ask ourselves some fundamental questions.

·         What is important in IT in relation to our business context?

o   What do our customers actually care about – and what don’t they? You aren’t a Bank, so do you need security like Fort Knox?!

§  Do we really know what is important and fundamental to our Users? We need to ignore all ‘received wisdom’ on this one and just ask them. Make the questions as binary as possible.

§  Are there things we spend time and focus on which they don’t want, need, read etc. – because if there are, then maybe we should stop them. Our service proposition could get simpler!

§  What components of ITIL (and associated elements) currently in place could they actually live without?

o   What elements of IT for which we are responsible cause our customers pain and aggravation?

§  Again, do we really know? We may assume that we are failing them in some areas because our metrics tell us so – but they may not care.

§  Ask them what they would change if they had the chance – I guarantee that a significant proportion of what they suggest will be basic, non-ITIL, service fundamentals e.g. make it easier for me to get a new PC..!

·         What problems are we actually trying to solve? Do we know? We may think we do…

o   The output from asking the business about what is important to them will help – and any pain survey conducted certainly will! This should give us a starting list of what really matters.

o   What ‘internal’ IT problems are we trying to fix?

§  These should be easier to identify, right. After all, they’re right under our nose…

§  We should know where we take too long, where quality is poor, where performance (in all its guises!) is inadequate, and so on. The important thing here is not to start with an ITIL manual or list of ITIL processes, otherwise you’ll end up with a list predicated on ”Oh, we haven’t got one of those / aren’t doing that”.

o   Articulate the problems we are trying to solve – both business and IT – in simple language, and identify what will look different after we’re solved it.

·         What are the truly essential ITIL service components from an IT perspective?

o   What would happen if we stopped doing ‘X’?

§  This is tricky too. This is also where we need to be ruthless. But the bottom line is that by stopping doing one thing we might just free up our resources to fix something much more important.

§  For example, we ‘do’ Knowledge Management to a ‘level 2’ competency and our instinct tells us we need to get to level 3. But what if we stopped doing it altogether? What would we lose? And what would we save / free up?

o   What do we really need to do that we aren’t?

§  This is about core, bread-and-butter ITIL processes. Like Change Management. Not doing it? Shame on you! One you can’t live without, I’d suggest. But even then, even if you are doing it, is your approach appropriate to your need? Are you gilding the lily for the sake of it? What does ‘good enough’ look like – do you know?

Questions, questions, questions. But without questions, we don’t get to answers.

And here’s the rub. I suspect that, if we undertake such a review, if we strive to find out what is really important in the context of our ITIL-related, service provision processes, what we will actually find is that we need less ITIL than we thought – fewer processes / less complex ones – and more bread-and-butter management. We will expose weaknesses that cannot be addressed by adopting ITIL or for which ITIL has no solution. We will learn how to become that expert marksman, and use the diploma for target practice!

Whither ITIL? Well it’s going nowhere fast – and probably neither should it. But we should perhaps consider putting it back in its box and re-teach ourselves to recognise what we truly need to get done.

-*-

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.