Thursday, May 19, 2011

Why Mail On the Move Isn't Working

More and more of the people I interact with on a daily basis are doing all or very nearly all of their email on a mobile device - mostly iPads, iPhones (if they have a choice on the device) or blackberries (usually if they don't have a choice).

But email tools on these devices have not evolved much in the last few years.

- They are still, essentially, one large inbox (and often one inbox with email from multiple accounts in them). Managing sub-folders is cumbersome.

- They support only basic searching (Apple's iPad email search is significantly poorer in capability than its spotlight search built into the device and much worse than Mac Mail or Microsoft Outlook). Searching To/From/Subject just doesn't find what I need often enough (and why can't I search across all sent mail in one go?)

- There is little or no support for flagging email, moving it to a task application, attaching it to something else you're working on. In short, if you don't deal with an email the moment you see it, then you are unlikely to ever go back to it and so your mobile device suddenly becomes a bottleneck - either you're not answering your email or you're constantly marking items read/unread as you try and juggle your task list.

- As soon as you have more than one email account, any effort to manage a simple non-duplicated contact list is doomed. I know people who 5 or even 10 copies of every person they know in their address book. The effort to sort that is huge - and you have no guarantee it won't recur as soon as you've fixed it

Lots of work is needed - to build on the advances already achieved (I don't want to take anything anyway from the effort expended to get universal inbox, the basic search capability, exchange on iPhone etc) - to ensure that we can be genuinely productive whilst on the move.

Monday, May 02, 2011

TUPE or not TUPE

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.