In outsourcing almost all of their IT over the last 20 years, government may have complicated their move to the cloud. Talk of the cloud is everywhere and has been for a couple of years. though little progress has yet been made on the journey. Last week, on walking into T5, I was greeted by a huge EMC ad announcing “the journey to the private cloud starts here” – and I thought I was on my way to Copenhagen. The complication arises because of something known as TUPE.
What is TUPE
From Wikipedia: The Transfer of Undertakings (Protection of Employment) Regulations 2006 (SI 2006/246) known colloquially as TUPE, are the United Kingdom’s implementation of the European Union Acquired Rights Directive.
The regulations’ main aims are to ensure that:
– Just because of the transfer, employees are not dismissed before or after (unless there is an ‘economic, technical or organisational’ reason
– Employees’ most important terms and conditions of contracts are not worsened before or after the transfer (unless there is an ‘economic, technical or organisational’ reason
– Affected employees are informed and consulted through representatives
What might TUPE mean for UK government?
Consider two scenarios, both very likely to occur for any given government entity in the very near future.
1) The Insource
In a quest to become more agile, reduce costs, speed delivery and try out open source software, a department at the end of its current website development and hosting contract decides to bring the development in-house. After all, it can hire good quality coders straight from university or with a couple of years experience for hundreds of pounds a day less than paying contractors or service provider staff.
The business case is straight forward. There are 20 people working on the website now, there will be just 10 in-house. The old ones were charged at an average of £650/day, the new ones will be £200/day. Even better, there is no need to spend months running a costly re-procurement. Costs appear to fall by 80% or more. Losing suppliers are also spared the cost and risk of the procurement process.
TUPE, however, rears its head. Those 20 staff need to be considered for transfer. Ordinarily, this would have been a supplier to supplier conversation as the government entity would have retendered for its website and, had the original supplier failed to win, the new supplier would have dealt with the transfer. Some staff, of course, would not have been required (and some would not have been eligible for transfer) and all of the costs would have been wrapped up somewhere in the bids, with new suppliers likely doing some risk-based calculations to judge the likely costs. Outsourcing providers are good at this – some deal with thousands of such transfers a year across dozens of contracts.
Governments, however, rarely deal these days with TUPE and almost no one deals with the transfer of staff back into government. And here’s the problem: transferring all or some of those 20 staff into the business will break the business case. If they’re made redundant, as they’re no longer required, TUPE dictates that the liability is with the recipient of the undertaking, not the sender. The government entity needs, then, to factor the costs of this transfer (either taking the staff on or making staff redundant) into its business case. Taking the staff on will result in little or no saving (and taking on expensive staff whilst releasing others who earn far less is not good business practice), dealing with the redundancy will increase one-off costs and likely severely damage the business case, certainly in the first 1-2 years in which everyone had hoped to book a saving.
2) The Public Cloud
Running dedicated IT is expensive. The foundation of the cloud model is that shared servers achieved through clever virtualisation of everything from processors to storage makes IT far cheaper. We’ve all bought this model, fed by news stories that show startups such as Quora launching using Amazon EC2 at fractions of what it would have cost them in the past. New ideas can be tried out quickly and cheaply – and shutdown even faster with no stranded costs if they fail to work out. Pay as you go IT without the need for upfront capital is ridiculously attractive.
Governments naturally want, in varying degrees, to take advantage of this opportunity. The US government has stated that it believes some 25% of its IT needs can be met by the cloud. Now some governments are actually big enough (although not always clever enough) to create their own clouds (if every department or entity shared the same infrastructure and even software) but the real save is thought to come from using the public cloud. If every public sector worker in the UK switched to gmail or Office 365 tomorrow I doubt google or Microsoft would see even a blip in utilisation figures – they can accommodate new volumes easily without necessarily adding capacity or staff.
So let’s suppose that the department above, having considered insourcing its website, now wants to move to public cloud email. Its current service provider handles all of its IT needs, not just email but there are a few specialist (and dedicated, in both senses of the word) resources who keep email working, it being the lifeblood of the organisation. Perhaps email takes 3 people in this organisation.
In the cloud, of course, 3 people aren’t needed to run email for this organisation. It might be 0.3 or even 0.03 but it’s likely not those same 3. Again, TUPE suggests that they should be transferred to the new organisation – the public cloud operator. That operator may not even be based in the UK or, with some providers or services, not even in Europe (data protection rules to one side for a moment).
The new supplier has the obligation to accept the transfer of those 3 people, or to make them redundant (something that would be far more complicated in the event that the receiving supplier is not in the UK or the EU). My guess is that few cloud providers have any experience at all of TUPE and that, anyway, they will be unwilling to take on staff at a faster pace than their slick processes require. That means that the government department will end up dealing with this with their original supplier – and, on the basis that services will move to the cloud on a piece by piece basis over years, this will be a recurring issue.
I’m not a lawyer – and this post shouldn’t be taken as legal advice – and the likely scenarios are certainly far more complicated than the two I outline above. But the issue is real and needs careful thinking about, both by government and its suppliers.
There may, for instance, be a need for a managed rundown period where in the months leading up to the insource or the cloud move (or the end of contract), the existing team is slowly reduced (through not replacing leavers or transferring staff to other projects/customers) – this may delay the move, of course, or result in a period of reduced service levels (this would be somewhat akin to the, apocryphal (I assume) story that Ken Livingstone changed the phasing of all the traffic lights for a while to really screw up the traffic before resetting them, instantly making the traffic flow smoothly again). At the same time, the department will want to make sure that the supplier is not artificially moving people that it might want to see made redundant or transferred to a new supplier ahead of any move (as if anyone would).
Departments, seeing this risk, may decide to move new projects to the cloud initially – so creating a capability in the cloud through development and eventually production – and delay the transfer of existing services.
Alternatively, central provision could be made for redeploying such staff across departments or even suppliers to bolster weaker areas ensuring that tough projects were well-staffed. In the extreme, central provision for redundancy costs may be the only way to achieve a more rapid move to the cloud.