Moving Always Costs, but Who Pays?

In my last post I hinted at the dilemma of who pays for a cloud project. There would appear to be few issues and some major advantages to scaling out to the Public Cloud, as you can pay as you go or pay for what you use. But is this really the case? The problem with transitions to any shared platform is that nasty subject of who pays. Typically organisations will allocate shared service costs, with an allocation key for the costs to various groups using the shared service. This allocation key will determine how much each person pays. It is obvious that as the shared service grows the unit price will trend downwards and will eventually level to a free market unit price but the first or last user may for an interim period pay much higher prices.  This “first man in” or “last man out” problem causes all sorts of grief for projects in the real world, not only for cloud, but for many wider IT projects.

Let us look at a real-world example that I remember from my personal experience. A bank where I was working was constantly trying to implement a strategic platform for their international credit lending business.  The legacy global platform had a seven figure running cost for each of the international entities using it and was so old it was long past fit for purpose. However despite the pressing need for replacement, time and again the project faltered because no one could agree how to handle the transition to the proposed new platform. Put simply, the last branch using the old one could be left paying ten times what it used to, meanwhile the first one to the new platform could suffer all the bedding in issues. This meant, nobody wanted to be first to transfer and nobody wanted to be last. Year after year no agreement was reached on how to share the transition costs, so nothing ever got off the ground.

The same issue can apply to a cloud project, clearly this is exacerbated many times over when the project is an internal Private Cloud project, since the costs cannot be shared with the wider market, so remain internally constrained. As processes and systems move over to the cloud, unit prices will drop, so there is a clear cost for remaining behind and suffering rising unit prices. Conversely, fear of the effort to be the first to move will stop many from wanting to risk change and represents a potential penalty to any prime mover. It is therefore no surprise, that in some organisations we are are already seeing cloud projects with the potential to save the whole organisation, reaching stalemate at the budget approval stage, because the internal bill payers in the departments will not move from the status quo. It takes creative accounting and sound cost benefit analysis to break this deadlock but it can be broken.

Time and again in this blog I come back to finance not technology.  The techies out there may hate it but money and sound financial planning are critical in any IT project and cannot be ignored.