This is a post about why mobile projects, as well as the wider mobile transformation fails in the enterprise. It is not specifically about why mobile is not being adopted at the rates we all expected to see. Those issues can be mired in politics, lack of vision and also lack of understanding.
No. This post is about the practicalities. Why projects or the wider transformation fails at the outset, part way through a project or even after the go live. We have been given the green light, all should be well, everyone is on board who matters…and then it all goes horribly wrong.
Picking apart failed mobile projects and initiatives will no doubt throw up all sorts of reasons but I believe they can all be put into three buckets
So specifically we are looking at the period from a go live and on to the fun(!) stuff. But naivety, inexperience, incorrect risk analysis, and a whole other bunch of reasons and issues can either mean we never actually get stated or, if we do, fall at one of the many unknown or ignored challenges
Lets take a broad look at the three reasons individually.
It is really hard
App that ‘just work’ do not ‘just happen’
It is easy to look at an app that works and see just the simplicity and how easy it is to use. But this belies the fact that so much effort has been put in at the design stage. Like anything, to make something simple to use requires much more effort upfront. But this is where ‘start simple / iterate quickly’ mantra comes in.
However even with a simple start deep understanding and good insight into how the app could develop is crucial. For instance, how and why certain sObjects and records will be made available offline. This is where efficiency, not just in data, but in process, really lays the future for a ‘fit for purpose’ foundation application.
Design, as a process, as well as a discipline in not yet a big focus in enterprise apps. But with mobile this must change. We should not be in doubt why this effort should be put in upfront. And then continuing the effort once the feedback from the users starts to come in (here you can see why it is critical to build a feedback loop into every app, every process)
When every CEO and CTO realises that the effectiveness of the organisations employees will hinge on these apps, this initial cost and time will be seen as a small down payment for the success that enterprise mobility can bring.
Offline is a massive but often ignored issue.
Offline is starting to get more coverage with both Forrester and Gartner including in high level reports. My personal stance on this, after a number of years building fully offline capabable applications is that there is no question. All mobile apps should be highly fault tolerant and data connection is just one of the items we do not control or can guarantee to the uptime for. Therefore remove the issue before it can manifest into a problem by building offline first apps from the get go.
Remember offline is not just about no data connection. It is about a failed transmission, patchy connection or how some term it ‘occasionally connected’ (we used to use this term but, as will become apparent, I think this leads to some incorrect assumptions).
‘Occasionally connected’ would be great if we know when we will be occasionally disconnected. Then we could build our app to handle these known scenarios. However the whole point of being fully offline capable and ROBUST is we handle the unknown. So having data always saved to a local store first solves this issue – which is commonly referred to as offline first.
Offline is only one part of a robust application
So now we have removed the ‘are we/aren’t we’ in terms of building an app that is offline first we come to appreciate very quickly that this in itself does not make a robust app. In fact it brings with it a whole host of new issues.
The biggest of these is the concept of ‘offline applications versions’. That is where the app on a device may well be different, in terms of data and configuration from other apps out in the field. It is vitally important that the platform has the intelligence to know which particular device is running which particular version of the app, in terms of both data and configuration.
Secondly robustness is about handling more than just the lack of connection. It is about record conflicts (as you can see here from out CTO, posted on our developers site), database failures, config conflicts (due to platform config changes not being incorporated into our app) and a whole host of other ‘minor’ but potentially app crippling issues.
Mobile workers are ‘mobile’
Lastly we have the issue that our app users are mobile. So support and fault finding ramps up very quickly. Again we need to cater for this as going mobile should not reduce administration or overheads costs only to be replaced by support costs in IT.
It is really risky
You are not in control of so many things
When we deploy a new browser application in Salesforce.com we are pretty comfortable that we have control, if not good understanding, of how the app will be used, what type of device it will be run on and the network it will be run over.
With mobile all of this is up in there air. The wrong way is to try and control or lock this down ie only this device type. only this mobile OS etc. This will come back to haunt you, often much quicker than you could believe. That is because devices break, get discontinued. OSs get versioned up withouth our say so. And networks, connections are all out of our hands.
What we need to is to design to expect for these changes and upsets from the outset.
If the app stops so does your business
As we take the leap to mobile the upsides (or mobile promise) are obvious. To deliver the savings and efficiencies we need to quickly remove the items and resources associated with these such as paper based system, back office resources etc, but also add in layers of automation now we have the data flowing in directly from the field. Very soon the app working is now critical to carrying out business as usual.
So if we do not aim for 100% Mobile Uptime then we very quickly move back to ‘pre cloud’ local outages. Worse the users are in the field, most likely scattered everywhere, and are now most likely completely ineffective. The app has stopped so business has stopped. This is a real and quantifiable risk.
Costs spiral as challenges surface
Even with a large experienced development team the specification of the app is often equalled by the enabling effort. Having to write and update sync engines, how to deal with dropped data, how to deal with conflicts, how to deal with changing OSs – and these are all moving targets. Each project seems to throw up new combinations of these issues or just new issues full stop. The knock on affect is not just deployment delays but all the associated costs both direct and indirect.
It is never ending
New. New. New.
Changing. Updating. Deprecating.
The cycle of technology is only going to get faster but even at today’s speed it is incredible. Devices that we have today will be outdated in a year or two year. Frameworks we use for the user interface will evolve many times in the same period. And on and on.
Once we commit to the mobile train there is no getting off.
And of course there is our business. Not only will it take a long time to actually on board all the processes we have or wish to have mobilised, new requirements from new opportunities or changing business landscapes will fuel an ever growing demand for updates or overhauls to our mobile applications.
If there is one thing that is constant it is change. Enhancing and therefore versioning control will be paramount to allow us to answer all of these challenges and the ones we have yet to encounter.
So are all mobile projects doomed to failure?
Just looking at the three categories above it is easy to assume that no enterprise mobile projects ever get off the drawing board, let alone out and operating in the field. But this is not the case. There are definitely shining lights out there although we must be cautious in our evaluation.
As we have seen the upkeep and maintenance is an area that requires continual funding and resourcing. It is a cost of going and being mobile.
And, as MobileCaddy can attest to, there are a number of specialist using a variety of back-end platforms to provide solutions that increase speed, lower cost, and lower risk.
So the takeaway here is not to start mobile projects or transformations without thinking through these categories and weighting the issues to your particular organisation and application. But if it looks too daunting or too risky, look around, there are now a growing number of options to get you on track to delivering robust enterprise mobility.
If you’d like to see how you can move your organisation to rapidly deliver truly robust, fully offline Salesforce.com mobile apps please click below to arrange a demo.