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.

Contractor Day Rates - Is there a Better Way?

So let me get one thing clear right up front. I think Contractors play a valuable role in IT functions delivering solutions to Customers. Like most people in our industry, they are professional, diligent and hard-working.

Having said that, I look at the way we reward contractors and it seems somehow out of kilter with the role they often play. Our approach – agreeing a rate for a ‘professional day’ – is tried and tested. Or rather, it’s simple, easy to administer, and we’ve been paying for these services in this way for ever. But on reflection, does this encourage us to get the best value possible from this expensive resource? And is it offering the Contractor the best possible return for their efforts?

By and large we recruit Contractors for two main reasons: as workload supplementation for our Business-as-usual (BAU) activity, or as specialist resource to deliver a specific ‘ thing’. Much of what I am suggesting here applies more easily to the second of these two contexts i.e. the delivery of something specific. Having said that, I’m sure it could also be looked at in the light of BAU activity.

Let’s assume we hire a plumber into our home to fit a new bathroom suite, and they tell us it will take five days and that’s the effort for which they will charge us. If at the end of those five days the suite is installed but all the taps leak and the toilet doesn’t flush properly, what will we do? We’d expect the plumber to fix these things for the price quoted. If he tells us it will take another three days effort – and therefore cost – to put right, we wouldn’t accept it, would we? Why then do we take a different approach with Contract resource in our professional life?

Well, partly it’s because we are paying them for turning up (the day rate), not for delivering. There is a certain irony here in that we often employ contractors to deliver something specific and then don’t reward them accordingly. More than that, we often compound the problem in two further ways. Firstly we endeavour to incentivise our permanent staff around specific deliverables where this is often inappropriate as they may be more engaged in a more ‘fluid’ and less measurable BAU activity. And secondly, our permanent staff see Contractors doing the same / similar work and raking in more money without any additional pressure or constraint. The second case may be unavoidable where the work is BAU related and hard to break down into specific deliverables, of course. Here the argument for the differential is the same as it has always been: risk, job security etc. – although I would argue that in today’s commercial world this differential is not as great as it once was!

For me, this begs the question about whether or not there is a better way; the possibility to tweak the day rate system to drive more value from what is likely to be the most expensive resource we employ. And if there is, then can we extend these principles beyond the individual contractors to encompass the broader, wider-ranging engagement of Consultancies and Systems Integrators?

The core suggestion is that we explicitly link reward to the deliverable, to getting the job done. Just like we do for the plumber. This would have the immediate benefit of getting a little more skin in the game – the plumber would know for sure that he wasn’t getting paid any more than agreed only when the taps worked properly. Surely this would drive engagement and delivery in a very real way – and in a way that was different from permanent employees, thereby helping to mitigate any sense of injustice they might have against Contractors. For us, it might also help to improve certainty about the cost of getting things done, and aid our ability to hit project budgets.

I would argue that we should consider trying to arrive at some kind of ‘split fee’ approach. Let’s assume that we are paying a Contractor £500 a day. In the new model, we would still pay a day rate – perhaps £400 or £450 – with a ‘bonus’ when the deliverable was produced (the bathroom installed!) which would end up equating to the £500 day rate. That way, if the Contractor delivers as planned, no-one loses out. If they deliver late or deliver a bad product, then we have some comeback against the cost. And – this is important – if they deliver early and/or a ‘better’ product than we had asked for, we need to be able to reward that too i.e. they make more than the averaged £500 a day.  This might get us more hours in our ‘professional day’ and improve engagement and commitment (and in a way that’s harder to achieve with permanent resource?). Win-win!

Of course, it isn’t that simple.

It doesn’t work for all assignments. Where we have contract resource working on operational BAU activity such as support, the deliverables will be harder to define. Whilst there may be some generic targets we might expect them to hit, the simple day rate is probably still the best solution here – at least until we are sophisticated enough to be more specific.

We need to include metrics into the contracts. We have to agree the metric up-front. Some will be simple, binary even: something is either delivered or it isn’t. Then we more in to more quantitative measures: time and cost are the obvious ones in this area. The hardest ones are the qualitative measures. Some you can attempt to be specific about – zero defects, for example – but what about the quality of a document, or the efficacy of a strategy?

We need to agree the outcome. Having agreed the metrics, at the end of the job we need to agree the outcome. The quantitative and binary measures should be easy enough: yes/no, six days instead of five, and so on. The qualitative measures will be harder, especially those that are based upon personal opinion. Your hired resource might think their presentation is top notch, but you don’t. What do you do then? You need to be clear about as many of the metrics as possible at the start of the assignment, and probably leave out anything that could be dangerously contentious – at least for your first time round. You will need to be prepared for the “It wasn’t my fault” argument when things don’t go quite so well, when there are mitigating circumstances outside of the control of the Contractor that impacted their ability to deliver. Here, your integrity and honesty needs to be spot on. If you try and use these kind of graduated rewards as a means of getting a job done on the cheap then shame on you – and the word will spread as to how you operate!

The rewards? I would suggest a simple scale. For example, delivering on time to agreed quality would net a bonus that would work out to equalling the ‘normal’ day rate e.g. the £500. For being late or delivering a poor quality product, then maybe anything from a zero ‘bonus’ up to the day rate i.e. in the £400-499 per day equivalent. For delivering early and/or something of superior quality that exceeds expectation, well, take your pick – but being able to go beyond the £500 average is clearly the ‘carrot’.

Bottom line. Does it work? I have seen examples of fixed contracts where individuals have agreed to deliver a specific ‘thing’ to agreed levels of quality based on it taking them a certain amount of effort (hours or days). That becomes the fee. If they deliver it early, they get paid the same amount – effectively their ‘day rate’ goes up. If they deliver late, clearly the opposite applies. These people were focussed, motivated and delivered; they were engaged and committed. It really was win-win.

So tweaking the system – where appropriate – can work. Certainly it should be something worth thinking about, at least to try and calculate if the additional admin effort up-front will yield sufficient benefits downstream…

-*-

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.

The Marginalisation of the IT Function

In case you hadn’t noticed, for some time now there has been something of a quiet insurgency afoot in relation to Information Technology (IT) functions in the context of the businesses they serve, and particularly in SMEs. Put simply, the traditional foundations of IT – primarily around the uniqueness or specialism of the role – are being eroded. The boundaries that have been in place to ‘protect’ the fiefdom of IT are being breached. To survive, to adapt, to add value, it is time to ‘re-envision’ what IT is actually all about, what it is for, and what its role is.

There is clear and undeniable evidence to support this premise – especially if you compare how things were perhaps 15 years or more ago, in an age when many of the IT frameworks and structures we still employ today were drawn up. A list of what’s different now is telling:

IT as commodity. It was always going to happen at some point, but now IT is more commoditised and available than it ever has been.

There are more Users of IT – and these Users are more sophisticated. Everyone is now an expert. Everyone has a PC or laptop at home – often more powerful than the one they use at work. People blog, build websites, edit photographs. Children are now more articulate on a computer than they will ever be on paper.

There is a greater range of solutions available, faster, and more flexible than before. What do you want? What kind of application do you need? The chances are that you can get it – fast – on some kind of pay-as-you-go deal. You can be up-and-running more quickly than ever.

The Cloud. And it’s not just in the area of business applications. In the virtual world we have created, you can get hosting, storage, disaster recovery – and take them for granted, not worry about them. The kinds of business models being pursued by technology providers today means you can get virtually everything you need with minimal IT expertise – in theory you only need to know about your business.

The growth of comprehensive Systems’ Integrators. The big technology companies are becoming broad SIs; all things to all men. Traditional hardware firms now offer consultancy and applications; consulting firms now offer hosting; network providers offer hardware. Everyone does everything, and these are the domains where unique IT specialisms are concentrating.

The Intellectual Property of IT is now diluted. Because of all of these factors, IT professionals (working within Business organisations vs. technology service providers or the SIs, above) now own less IP in relation to their function than ever before. They are losing the primacy of their expertise, their unique selling point. It’s a transition we saw way back when step changes in programming languages happened – but now it’s in all disciplines, and is happening more quickly.

IT becoming more integrated into business functions. And perhaps one of the most obvious symptoms of the entire transition is the migration of functions (such as Business Intelligence) and skills (for example in the area of Financial Management systems’ configuration) out of the domain of IT and into ‘business teams’.

Is any of that wrong in some way? Undoubtedly not – and even if it were, there’s little we can do about it! Should the majority of these shifts to using new models of IT service provision bring benefits to our businesses? Yes, they should – though undoubtedly they bring some fresh risks too.

But above all, it demands that business-domiciled IT functions align themselves against this new world. And to be as effective and flexible as our customers need us to be, this alignment may need to be radical considering where we are starting from.

The traditional in-house IT function is becoming rapidly out-dated. But let’s go even further. Is it actually needed anymore?! If you can outsource the entire gamut of IT services, from hosting through to DR, from networks to applications, do you really need an IT team at all? To some extent it depends on appetite, but some ownership of IT will surely need to remain – and that ownership must have enough specialist knowledge to get the best from your technology suppliers. And we need to avoid the ‘baby and the bathwater’ scenario i.e. we throw away the really valuable stuff – perhaps elements of competitive advantage – just to pursue some kind of minimalist ideal.

But how do we get there? How do we re-envision and re-engineer our in-house IT capability? How do we re-establish our credibility and contribution in a hostile environment? We have some ideas. We think we might need to adopt Agile development processes. We know we should be more innovative. Some elements of our service are too expensive, or too weak and of poor quality. We think we could outsource some of that operational “stuff”, but have never taken the leap. And we know, for certain, that we need to be seen by our business colleagues as a partner, and not the Necessary Evil.

The answer is to redesign the IT Business Model.

There are some fundamental questions worth asking. In your business environment, what is IT ‘for’? What value does it bring? Where does it contribute? Where is it an enabler – and where a blocker? How important is technology; leading edge or not? What about mobile? Is ‘good enough’, good enough, or do you have to be world class?... And a large proportion of these questions will not be answered by IT folk, but by people in the business, our customers.

Beneath these philosophical questions, there is a wealth of detail to be uncovered and discovered. Luckily, frameworks – and consultants! – abound to help you. Frameworks that talk about the journey from Strategy to Operation, Direction to Execution; about how you build things, support them, retire them; about suppliers and outsourcing… Breaking what IT does down into its component parts – like a Lego house to its bricks – you will arrive at, who knows, maybe 30 to70 elements. There will be a focus on Customers, Administration (how you ‘run’ IT – and it should be like a business!), Information Management, Services, Support, business solutions and so on.

1 – So, settle on a framework and, if you need it, someone to help you through it. All of the big SIs and Consultancies will have an offering in this space.

2 – Spend some time planning the activity and prepping the people who are going to contribute – some of the Leads in your IT function, but more importantly the key players in your business.

3 – Work through the framework, starting at the business engagement end. For each ‘brick’, most likely you will need to recognise a) where you are (and you could be nowhere in that you just don’t do ‘X’ right now!), b) where you need to be, and c) the challenges and prerequisites of getting from one to the other.

4 – Once you have assessed all the components in the framework, you will have a series individually coherent but potentially disjointed models. The final activity will be to take these and align them, and ensure they are complimentary. This will give you a new overall operating model at which to aim.

5 – Then comes the planning process i.e. identifying what you need to do and when you need to do it in order to make your new model a reality. And validate again the benefit of doing so. The plan and benefits case is what you need to sell.

But let’s be realistic here; this process is complex and can take a long time to do well. If you are looking at reviewing a traditional in-house IT function that covers all the bases, then expect steps 1-5 to take three to six months. Implementation – if it involves new outsourcing contracts, root and branch surgery of your organisation – could take two years to put in place and be effective. For many, this timescale – and the cost of the endeavour – will be too great, or at least off-putting. If you have a pressing need to go faster in some areas, then I would suggest you still execute steps 1 and 2 for the totality, but then have an iteration of the remainder by ‘area’ e.g. Operations, Business Engagement, IT Administration, Service Support etc. This will give you the advantage of seeing some results earlier, but overall will probably take longer and may cost more. It may also prove to be a more flexible approach. But whichever approach you choose, you have to start with the big business-related questions up-front; these will give you your boundaries within which to work. If you start by looking at the support processes in isolation, you may optimise what you currently do – but this will make little difference if what you are doing is profoundly inappropriate.

It’s a journey that will take funding, time and commitment, but at the end of it you will find yourself with a different pile of Lego bricks than before – and therefore a different house. And hopefully one much more in tune with what your business actually needs. If you fail to undertake the journey, then you may find that two things happen: the first is that someone in the business might ‘do it to you’, and the second is that there is a continuous and subtle leak of IT responsibility and expertise away from your function which will lead to less effective, disjointed and uncontrolled solutions provision to the business – and that will be a bigger problem to solve!

-*-

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.

 

What the Hell is Matrix Management?

It’s a common enough term these days, but what does ‘Matrix Management’ actually mean? what is it trying to achieve? and is it working?

If you search on-line you can find numerous definitions. Here are just three:

·       “A style of management where an individual has two reporting superiors (bosses) - one functional and one operational.”
·   “Multiple command-and-control structure in which some employees have dual responsibilities and dual bosses”
·   “A style of management in which one person works for more than one supervisor on a riety of tasks”
 
The common thread is obvious; it’s the one-to-many relationship between an individual carrying out a series of designated tasks and the two (or more!) people who need to get those things done. The other key theme is that the Managers concerned will often have different agendas – e.g. functional vs. operational – and/or responsibilities. By definition, this must mean that a proportion of the delegated tasks (and maybe up to 100%!) will not be common or shared. Again, by definition, this must imply that some degree of conflict or ambiguity will be an everyday reality for the employee charged with carrying out the tasks concerned.

So why do it? What is it intended to achieve? Well, many things. Here are some suggestions.

It’s a recognition of / response to increased complexity in business / IT. Perhaps especially in IT, the days of people having just one job with a single focus have long gone. People’s roles have broadened, and in many cases they have to know more or contribute to more things – and often these ‘things’ or areas of expertise are explicitly owned by different individuals e.g. Bill owns the Oracle Databases but Charlie owns everything to do with the Disaster Recovery regime including those databases. Dave is the technical expert who has to execute tasks for both of them.

It’s a way of responding to multiple perspectives. Less technical perhaps, but there are examples where people are pulled in multiple directions: they work for a specific country business unit, but have to contribute to a global initiative or service. Or customers in a single business are perhaps brand-based, and these brands have different requirements on the same resource. Or in order to instil greater service excellence into a technical discipline, people have to work with/for the service management guys as well as their operational line manager. And so on.

It’s a means to reduce headcount / control costs. More for less. If we can get our people focussed in two directions, meeting two requirements simultaneously, then we could just be saving on headcount, cost etc. – and in these difficult financial times, that’s clearly important.

However, my concern is that matrix management can actually be more of an excuse than a solution.

Look at what’s wrong with the model from a practical perspective.

·         It will tend to create a lack of clarity and confusion: what’s more important, task A or task B? whose agenda is the most important one? does the operational boss trump the functional boss – or is it the other way round?
·         The potential for instilling ambiguity is high. Instinctively, people struggle with ambiguity, especially if they can’t do anything about it. And that can lead to them mentally disengaging; you lose their enthusiasm, goodwill…
·         If people become torn between tasks, bosses, agendas, if they start to disengage, then they might proactively (if unconsciously) adopt a position of refusing accountability. “How could I be accountable and deliver this”, they might say, “because A, B, C was out of my control. Bill said this and Charlie said that…” And so on.
·         We face over-working people. It doesn’t matter one iota that we explicitly agreed that Bill would get 60% of Dave’s time and Charlie 40% - both Bill and Charlie will either behave as if they have 100% of Dave’s time and allocate work accordingly, or, if they do stick to the 60-40 split, they will expect their tasks to be completed first and will ignore and negative effects on the other’s agenda. It’s not their problem…
·         For all of these reasons (and more) it becomes harder and harder for people to commit to achieving things. Bill and Charlie might commit – and when they fail it’s clearly Dave’s fault(!) – but for Dave, how can he commit when he’s being pulled in two different directions, and has too much work to do anyway?!
·         If matrix management is being adopted to save headcount and cost, might it actually end up being more expensive in the long run as we face significant levels of missed deadlines (and longer deadlines, anyway), unengaged and unproductive staff, or – and this could be the biggest kicker! – a dramatic reduction in quality of output.

The cynics among you might also point out that all too often matrix management is driven by people who are NOT in a matrix structure, so they don’t actually see or really understand the effects adoption of this kind of ‘structure’ is having on those actually carrying out the work. (Dave’s on the verge of a nervous breakdown and is looking to leave the company, by the way..!)

But let’s face it, matrix management isn’t going away anytime soon. In order to meet the demands of complexity, multiple perspectives, ‘more for less’, having multiple reporting lines and workload streams will be a fact of life for some time to come. If that’s really the case, then what do we need to do to improve the effectiveness of working within this kind of structure? what do we need to be better at? Well here are some ideas…

Resource Management. At the end of the day, the core capability that we need to nail is how we manage our resources. It is anyway, but in a matrix situation it needs to be razor sharp.

Delegation. When we allocate a task to someone, we need to be truly explicit in the parameters of that task and what the desired deliverables are. Often we are too vague about the required output with the result that we over-shoot initial timescales.

Estimating. Both better resource management and improved delegation are intimately linked with better estimating. “5-10 days” is no longer a good enough answer in a pressured world where there is always something urgent next in the queue.

Commitment. On two fronts. Firstly from the Bill / Charlie end in terms of making a commitment that what they are asking for is actually what they really want – and they know it! – and that they will stick to their 60-40 deal and any agreed priorities. And secondly from the Dave end, who, having said “7 days” rather than “5-10 days”, is actually committed to hitting that estimate (i.e. accepting accountability).

Honesty and Integrity. All of these things only work if all parties are completely straight with each other. Build any element on sand or using ‘smoke and mirrors’, and the whole thing falls apart: “I said 7 days but I knew it would be 12…”; “I agreed to 60%, but I knew I’d need 75%...” etc.

Listening to Dave! And we must listen to Dave, the power of the doing resource. Most of the time they actually know what they are talking about – and far too often we ignore their input assuming it is being given for reasons of self-interest, self-protection and so forth.

Clearly these things are all intimately linked, and improving them will take time. But what can we practically consider doing in order to help us along? As ever, no silver bullets, but hopefully no blanks either!

·         Process undoubtedly plays a part, especially in areas such as Resource Management (RM) and Estimating. How good are your processes – really? – and where can they be improved? And this may mean simplified, don’t forget!
·         Good communication and reporting is key, between all parties concerned and along the entire journey of any task from estimate to progress tracking. Bill needs to have sight of how Dave’s work is progressing for Charlie, not because he has any direct interest in it, but because potentially he will be affected by any over-run. And the communication has to be effective. This doesn’t mean detailed, but rather something that is actually read / listened to and understood.
·         If you have a PMO (Project Management Office) function of some kind, this could be where some of this responsibility sits. They may already have a hand in resource management and reporting, so offer a natural home for any improvements. If you don’t have a PMO – and can’t see the need for or justify having one – then you will need to rely on your Project Managers and Team Leaders buying into any service improvement package (in terms of RM, process, comms and reporting).
·         Perhaps one of the most effective mechanisms to shift culture in this area (which is, after all, what we are talking about) is to change the reward mechanisms for your staff. Consider adopting some kind of ‘one fail, all fail’ approach. There are various ways you can achieve this through objectives or bonuses; for example, perhaps trying a scheme where part of Bill and Dave’s bonus is based on Charlie being successful, and vice versa.

Undoubtedly, there are many more levers that can be pulled to make Matrix Management operationally more effective, and turn it from a nice theory to something that actually works OK in the real world. How much of this you choose to disclose to or hide from your end customer will depend on your style and the ethos of your organisation. In theory they shouldn’t really care as long as you are delivering what they want and what you promise them – and making Matrix Management work just a little bit better should repay any investment you make.

-*-

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.