The comment below was posted yesterday by someone called Michael; it's a question I've heard a lot - usually from the larger suppliers - so I wanted to raise the issue in a post rather than hide it in the comments:
Do you have any comments on viability of contracts for less than one year? In particular, am I right to think that part of the intention is to avoid the burdens of full EU tendering by keeping contract terms shorter, so reducing cost so contracts do not fall into scope of full tendering rules (before you even get to cost competition through the increased transparency of G-cloud etc)?
The context for this is interesting - at least one major department is grappling with contract duration right now. The one I'm thinking of found it was unable to extend an existing contract and, with the proposed three year replacement contract, only the incumbent was prepared to bid. The others couldn't, they say, figure out a way to take over the existing service, deliver the necessary improvements and cost saves and make money.
So is gCloud wrong in its approach of 12 month contracts?
Let me deal with the EU point first. There is no "avoiding the burdens" of EU tendering with the gCloud procurement. By setting this up as a framework the team have created an entirely legal and comprehensive vehicle for all public sector authorities to buy cloud services. Sure, they've done it on an accelerated timetable (many are hoping that this marks the start of a major trend) but the point of a framework is to allow purchase of services up to the value of the framework (£60m in this case) without substantial modification of the terms and conditions (that is, you buy what's for sale on the terms and conditions posted and don't negotiate variations). I doubt they'll even get close to £60m in this round but there's no limit on the value of the service that can be bought other than that.
Secondly, the aim with gCloud is to show the public sector that there is a better way to buy its IT. In this first iteration it's hoped that lots of government bodies will give cloud services a try - maybe they will buy development and test environments, switch their e-mail, try out collaboration tools, seek consultancy to build a roadmap to cloud, host their website (assuming it isn't captured by the single domain work) and so on. This is not, yet anyway, about transitioning major legacy applications into the cloud but it is about testing, robustly, a new model.
Thirdly, this is definitely a first of its kind - perhaps not an alpha.gov but a beta.gov. I think the team want to try it out fast, see what does and doesn't work and then complete the next iteration quickly. If it didn't make me feel ill, I'd probably want to call it agile procurement. Hopefully those who worked hard to get on this version of the framework won't have to do much to stay on the next version - and those who didn't make it (because they didn't qualify, didn't notice it or didn't think it was real - and there were quite a few in the latter category) will work to qualify then. Wrapped up in this is the fast moving nature of cloud services - as Chris Chant has said, the iPad didn't exist 2 years ago, iCloud didn't exist 6 months ago; why build a framework that is fixed for a long period when within months there will be not only new services and new companies but likely entirely new categories of things that government could buy.
There are certainly downsides to such a short contract period - any department that moves its entire email service (assuming they move all the historic mail too) will not look forward to doing it again only 12 months later. But during that period they will have been able to take advantage of a new service delivered at a much lower cost than their incumbent can deliver it for, they will have learned a lot, and the framework contains provisions for reducing the burden of migration.
This isn't an easy process - right now I expect the gCloud team are buried in evaluating thousands of services and that's before they get into the accreditation process - but as I've said before the transparency and competition it brings will absolutely mark a significant change in the way government buys IT.
gCloud - the logical extension
Imagine you're a CIO in a major department and you are being asked by your business to set up a new delivery programme. The first thing you'll need for the delivery team is probably development and test environments (ok, I'm skipping a few stages ... let's assume that requirements, governance and so on are ready). The incumbent IT provider, in the traditional model, will go out and buy some hardware and software - probably hundreds of thousands worth. In the pre-gCloud model they might look at their own cloud capability and propose a pay as you go service - which might be a hundred k. With gCloud, the CIO now has options - they can look at what the market price is for that service and it might be 10k. The CIO might reasonably achieve an order of magnitude save for the sake of a couple of hours looking at what's available. Without gCloud that isn't easy or even possible in some cases.
Once gCloud is in place, I expect that many government CIOs will benchmark everything that they do against the market that gCloud establishes. Incumbents will be under pressure to reduce their costs significantly and, when they can't, the CIO will buy from a supplier on the gCloud framework. That brings with it all kinds of new problems about integrating and managing multiple suppliers, handling single sign on, dealing with bandwidth, upgrading browsers, handling the relationship with the incumbent to name a few. But all those issues were coming anyway. This way they get confronted faster.
There, hope that's answered the question Michael.