Blog

Two people, six weeks.
Sunday 12th January 2020
Sean Murphy
I recently sat though a Cloud sales presentation, delivered by a large global consultancy, in which they spent a great deal of time emphasising their ability to rapidly deploy a working instance of a financial ERP system in just six weeks. Within the audience with me were several senior business representatives, as well as IT services and hardened deployment project staff.
Whilst I have no doubt that they could have an instance of the software up and running in six weeks, this would be almost if not completely vanilla, involve no business process optimisation, very basic planning, targeted testing, little to no training and certainly no data migration of any significance. I find this incredibly misleading and unrepresentative of what is truly involved with deploying an application into an environment that has a complex legacy technical footprint that has been in operation for decades.
The business representation was blown away by the messaging and encouraged that we could move archaic systems into a cloud solution in a fraction of the time. The IT Services people could see the ease of transition and the simplification of the architecture (as well as the obvious cost savings) but were rightly skeptical of the suggested deployment window. The project staff, of which I was one, looked at each other smirked, raised eyebrows and sighed deeply.
Moving to cloud is not just about the implementation of an instance of software. It is about fundamentally changing the way a business operates and thinks about its software. It is a complete re-validation of process, which in turn requires a new way of managing the business and in particular expectations of how their existing workflow is going to change in future state. Long gone are the days of generating lists of demands (also known as requirements..) which ultimately create complex customisations within the project deployment. This work, in partnership with the business, takes time; a lot of time. There will be meetings, planning, process flow documenting, identifying gap/fit and coming up with a robust solution that fits the cloud profile without causing a detriment to existing service levels. And all this before we consider the Data requirements.
My point is that we need to be realistic. I am firm believer in planning properly and honestly. I do not like or condone sales approaches that offer the ridiculous; these assumptions feed budget definitions and create a project scope and timeline that becomes impossible to deliver. Cloud is certainly the way forward to release the costs associated with on-premise solutions, but we all need to apply some common sense and experience to the information we are being sold.