Before we start, I’ll warn you that this article is much longer than I’d planned it to be, but I think everything in it needs to be in it, so here we go.  Kick off your shoes and grab a coffee (or maybe the other way around – they are your feet after all!….)

I’ve worked in and come into contact with some companies that operate internal recharging models.  The idea is basically that you have internal ‘support’ departments that are constituted as trading units, and they carry out work for other parts of the organisation. This is done on a ‘pay for use’, ‘time and materials’ or some other kind of ‘rate card’ arrangement.  Money is transferred internally and each unit has its own Profit and Loss and so on.

I think (and I’m doing this from memory) when I was at university, it was explained that this type of thing was based on something called the ‘Boston Matrix’.  The idea was that you had a ‘business domain’ and a ‘technology domain’ and they would interact and charge each other for services.  I suspect that this would be at ‘the market rate’ (whatever that is).

Having set up your recharging model, the various business areas of the organisation are free to come forward with projects. These get prioritised, resourced and delivered based on (presumably) some set of meaningful criteria.

It all makes a kind of superficial sense.  But if one looks below the surface at what it leads to, all is not what it seems.  Some people have concerns about the whole idea.

When looking at the wisdom of recharging, there are two main issues involved, and two or three more worth considering afterwards:

1) Large projects need corporate/board approval and investment

For a large project (what that is up for grabs of course), the project is unlikely to be funded solely by a single department or even a combination of departments.  The board are going to have to get involved.  A department’s ‘discretionary spend’ isn’t going to be enough to fund it – though they might have been able to get something developed initially.  And that’s fine – the board are there to make such things happen. The project becomes a corporate investment, and almost certainly something that fits the corporate strategy.


So the question then is:

‘Why are different departments charging each other for work that the organisation has – at a high level –  decided upon, and that we have collectively decided to do?’ 

If the departments involved in the project are not revenue generating (and I’ll return to ‘revenue generating’ in a moment), you then have two non-revenue generating departments charging each other for work that has to happen anyway.  I think the wisdom of this is questionable at least.

The argument that usually gets wheeled out at this point, is that if you don’t have internal recharging, you end up with anarchy: Nobody is able to set priorities, there are projects that never end, no control over costs and so on. The whole organisation collapses in on itself.  Well this is nonsense. Most of an organisation doesn’t operate on a recharging model – I’ve certainly never encountered one that does; nor does most of the business world, and it hasn’t collapsed. 

Also, since projects aren’t actually funded by a department on their own, doesn’t that rather undermine the paradigm of the ‘departments are free to come forward with a project’?  Anything significant will probably be a corporate decision – not a departmental decision – and we’re all in it together, I’m afraid.  We can’t get away from that.

2) Tactical and ‘Discretionary’ projects

That is not to say there isn’t a role for recharging.  In any organisation there is always a mix of projects going on.  Some strategic and some tactical, some will have come out of improvement initiatives, people’s appraisals, and so on.  It makes perfect sense for departments to have some budget to do these – and I don’t see the problem with the IT operation charging for it.  If I want the intranet pages for my team refreshed, and I’d like one of IT’s designers to do it, I’ve no problem in that going into the work queue as a piece of chargeable work.

If I come forward with a plan to re-engineer the global logistics system, that is another matter.

3) Not all departments come forward with a project

Not all departments will come forward with projects.  This is not always easy to prove, but you can get a feel for the parts of the organisation where there are clear needs.  If the work is mission critical but they are still running on Access databases and Excel sheets they’ve knocked up themselves – or perhaps paper-based systems, this is a concern.  So why aren’t they coming forward?  We need to understand what is behind this.

This might be down to nothing more than they don’t know who to talk to in the IT department, I suppose.  But I think there is more to it than that.  

Lets think again about what we said in points 1) and 2) above.  It starts to become clear.

I can only come forward with a project if I have funding available.  So the question is, who chooses which department has funding available and on what basis?  How do they decide how much?  If certain departments have no discretionary spend – or such a poor amount they can’t do anything, that again undermines the paradigm of the charging model:  Why have it at all if parts of your organisation can’t participate?  Again, the wisdom is questionable to put it mildly.

What this leads to is a situation where – assuming they have a clear business need – IT can lend pro-active expertise in putting the business case together for them.  We can help inform them of what’s going on in other departments, how they can collaborate, how they can improve what they do.

Oh, hold on a second.  We’re supposedly a ‘support’ area aren’t we?  And a chargable area?  They come to us.  Silly me.

Having addressed these main issues, there are also these…

4) Recharging implies optionality

Another aspect of charging – which often gets overlooked – is that a charging model implies ‘optionality’.  I can elect to not have the work done, right?  Otherwise it’s not in the spirit of charging, surely?

This can lead to some serious consequences, or at the very least, unexpected consequences, which we have to somehow address.

A colleague of mine recently mentioned that, whilst she isn’t against the idea of recharging in itself, the problem is that business areas and departments don’t recognise that systems and software has a lifespan.  You get to a point where it needs investment, replacement, upgrading.  The department who funded the thing to begin with isn’t likely to be very interested in this.  What do we do then?  For the IT department, it’s a difficult sales job isn’t it?  What happens if they say ‘no’?

Another example I’ve used many times is that of end-user training.  I worked for a company once where you couldn’t get data maintainer access to a system without first sitting an induction (training session conducted by a super-user of the system, lasting 2 or 3 hours – sometimes more), followed by you being given a disclaimer to sign, document explaining the escalation/reporting procedure for faults or problems and so on. Only then would you get given your login details.

The policy was ‘you don’t get access to the system without first attending the induction – no exceptions’.  This was strictly enforced from a high level.

Fine.  I’m a big advocate of this.

So what happens if you’re in an organisation – and there are many of them – that charge for internal training courses?  One could argue you can get away with this if it is for something like Word or Excel – to some extent you can pick it up yourself.  But think again about optionalityWhat happens if you are charging for the induction on a critical system, but the business area says ‘no – I don’t want to pay’?  Or perhaps a variation like ‘It’s ok – I won’t bother sending them on the induction, I’ll just teach them myself’, or, ‘it’s ok, they don’t need to go on the induction – they can just learn off other people’.

The balance of power has shifted.  We can hardly say ‘sorry – no induction, no login’ If we’re charging them can we? And even if we could, you have to ask ‘why bother’ if it’s mandatory anyway?

We’re on the back foot – on the defensive.  Why? 

This is a serious situation:  More serious than people perhaps realise:  It leads to bad practices, misuse of systems, misunderstanding of the terminology, data quality issues, helpdesk calls, inefficiencies.  And that’s just the beginning:  Over time these people become the ‘experts’ called upon to lend knowledge and expertise.   A terrible cocktail.

5) Collaboration is virtually impossible 

It is almost impossible to get departments working together to jointly fund something.  When you think about it, Why should they?  The natural tendency is to wait for some else to fund it and then piggy-back off of that. You can’t get any ‘corporate’ initiative off the ground – even if it patently obviously benefits the whole organisation.

Footnote:  Pocket money and profits

I recently recounted to someone an analogy I’ve used many times before: This is that the situation where you have one non-revenue generating area charging another non-revenue generating area for work that you have to do anyway, is a bit like giving your child pocket money, and then charging them for meals and the use of their bedroom.  You then pat yourself on the back that your household finances are in much better shape and you have somehow gained something through the whole process.

The child, like most business areas, only has the money they have been given. How much they get, who decides it, and what they spend it on (and more importantly, how IT can influence it) is, my friends, the question. 

So where does that leave the ‘revenue generating areas’ we said we would return to earlier?  Well, the answer is that the organisation as a whole is the revenue generating area.  We are all in this together:  for better or worse, for richer and (in my case), poorer.  We all have a part to play if we’re allowed to.  It’s that simple.

« »