Mobile // Mobile Applications
Commentary
2/19/2014
02:00 PM
Quinton Wall
Quinton Wall
Commentary
Connect Directly
Twitter
RSS
E-Mail
50%
50%
Repost This

How To Screw Up Your Enterprise Mobile App

Consider these three wrong ways to develop enterprise apps -- and avoid them.

Most enterprise mobile apps have a long way to go before they can be considered great mobile apps. Unfortunately, apps often fail for the same reason over and over, with organizations neglecting to see the problems before it's too late. Soon, user adoption plummets, shadow apps (those not approved by IT) become commonplace and your business begins to suffer.

With this in mind, here are three guaranteed ways to screw up your enterprise mobile app – and how to avoid doing so. 

1. Give users exactly what they ask for
Start by finding your best business analyst and spend a few weeks compiling a list of requirements for your app. Once you have a good handle on what you need, put out a request for proposal (RFP) and search for a vendor that doesn't understand your business to implement the app. 

[In a mobile business, you need to always be testing for failure. Read Can You Deliver Antifragile Mobile Apps?]

You feel confident that the app is going to be a huge success: you interviewed stakeholders, modeled it after your existing processes and wrote it all down. How could this ever fail?

Mobile Apps

I've got one word for you: iterate. How many times have you ordered exactly what you wanted at a restaurant only to be disappointed when you got what you asked for? This same feeling of regret happens all the time with mobile customers. 

Instead of spending weeks or months gathering requirements, quickly identify the minimal viable product (MVP) and get an app out there -- fast! Once the app is released, ask your users for feedback. Incorporate that feedback. Release the app again and again. Not only will your app not suck, your users will feel they had a stake in it. 

2. Model your app after an existing business process
What if I told you to write down the steps you would take to find the phone number, address, and operating hours of the Atlas Cafe in the Mission District of San Francisco -- but without giving you access to the Internet? You'd look at me like I was crazy, right? So why create enterprise mobile apps modeled after existing processes? 

Your users probably don't like your existing processes too much when they have a full keyboard and a comfortable chair to enter information. Forcing them to do it on a touch keyboard designed for pixies will be downright painful.

Here's an example: Delivery drivers often have a hard time finding the right apartment on the first visit. With the existing process, drivers entered a description of the location in the system. With mobile devices, however, the driver can take a photo of the location and GPS tag it. The mobile process is completely different and more efficient and drivers can complete it much more quickly. 

Try this tactic to avoid the common pitfall of modeling mobile after existing processes: divide a whiteboard into three vertical columns. Label them: Business Process, Mobile-First, and New Opportunities. In the first column draw your existing process in a flow diagram. In the second column, draw lines from the flow diagram for steps that could be re-imagined with mobile and list them in the Mobile-First column. 

Finally, in the third column, based on your brainstormed ideas for a Mobile-First flow, write down any new opportunities for apps or business processes that this new process offers. Using our delivery driver example from above, the fact that the driver has tagged the apartment means that future deliveries can be flagged for "thin packaging only" to allow the driver to slide the delivery under the gate and avoid the customer missing future deliveries, even if they are not home. 

3. Make sure the app doesn't really connect to your business
If you really want to screw up your mobile app, make an app that creates or updates data into one system but forces the user to later edit the data or add more information for the data to be part of a broader process. 

You don't want your mobile app to be separate from your business processes and unable to update core systems. You want data from mobile apps to be a seamless part of the enterprise experience -- what I like to call enterprise UX. 

I constantly see organizations roll out amazing new mobile apps for viewing corporate data that are completely devoid of enterprise UX. These apps let the user view information on the go, but require them to jump to another system to update the data. What actually happens is that your business process is now harder than it was before you gave your users that new fancy mobile app. 

One strategy to avoid poor enterprise UX is to use cloud-based platforms and providers and securely connect existing systems to the cloud as a mobile integration hub. Then, build your apps using this new platform as a single point for mobile app connectivity. 

Cloud-based platforms speak mobile -- with RESTful APIs, efficient data transfers, and native mobile SDKs -- to make it possible to create great enterprise UX without ever spending on costly development cycles updating legacy systems. 

Too often I see enterprises doom their mobile apps. The predominant reason is they approach mobile apps the same way they have always treated projects: creating volumes of requirement specifications, not reimagining processes to use new technologies, and not paying attention to the enterprise UX experience.

Together, these strategies will torpedo any mobile app plan and -- congratulations! -- your app is almost guaranteed to stink. 

Cloud Connect Summit, March 31 to April 1, offers a two-day program colocated at Interop Las Vegas developed around "10 critical cloud decisions." Cloud Connect Summit zeros in on the most pressing cloud technology, policy and organizational decisions, and debates for the cloud-enabled enterprise. Cloud Connect Summit is geared towards a cross-section of disciplines with a stake in the cloud-enabled enterprise. Early Bird rates end Feb 21. Find out more about Cloud Connect Summit and register now.

Quinton Wall is the Director of Platform Technology at Salesforce.com where he focuses on helping customers harness the potential of the cloud and platform-as-a-service. Wall was ranked the most influential force.com blogger in 2010 and is a prolific author of dozens of ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Stratustician
50%
50%
Stratustician,
User Rank: Ninja
2/22/2014 | 12:54:57 PM
Some great advice!
I think you really nailed the key frustrations with enterprise applications here.  The biggest problem I've seen when it comes to releasing applications and getting employee buy-in, is that no matter how much you consult them, they always feel like the application was forced upon them.  Your advice to release in several phases in order to drive adoption is a great way around this!  I also think if more folks spent time mapping the old process, figuring out how mobility affects it, and then working on a next generation application strategy, we would eliminate a ton of the headaches associated with trying to keep a dead process alive.  Great read!
quintonwall
50%
50%
quintonwall,
User Rank: Apprentice
2/19/2014 | 9:14:29 PM
Re: How soon is too soon?
Chris,

Fantastic points. Here at salesforce, we rolled out Salesforce1 internally before making it available to our customers. One of the things we did is make a feedback function right within the app. In-app feedback must be as ubiqitous in any app, not just mobile, as secure login is. If your users are not telling you what they need in an app, I bet they are telling the rest of their social network.
quintonwall
IW Pick
100%
0%
quintonwall,
User Rank: Apprentice
2/19/2014 | 9:10:17 PM
Re: How soon is too soon?
Shane, you make a great point. In my experience complex problems are often best solved by breaking them into smaller problems and solving those. This way, what is your MVP (Minimal Viable Product) today is in the hands of the users fast. It might not have everything everyone wants, but it solves a problem. You can then iterate  to solve the next part of the problem, or as is often the case, your users identify something you didn't even consider to start with. The trick is constant iteration.
Thomas Claburn
100%
0%
Thomas Claburn,
User Rank: Author
2/19/2014 | 5:22:01 PM
Re: How soon is too soon?
Create disposable apps when possible and practical because chances are everything will be different in a few months.
ChrisMurphy
50%
50%
ChrisMurphy,
User Rank: Author
2/19/2014 | 5:07:42 PM
Re: How soon is too soon?
Regarding the iterate advice, a CIO once put it this way: "you can't imagine fast enough." In other words, get mobile apps and devices in people's hands, and see what they want to do. Don't spend forever imagining what's in that third column of "New Opportunities." They'll tell you what's missing as they start using them. The trick -- are most IT shops plugged in enough to their end user colleagues to get that feedback?   
Shane M. O'Neill
50%
50%
Shane M. O'Neill,
User Rank: Author
2/19/2014 | 2:17:30 PM
How soon is too soon?
Quinton, I agree you can't let mobile app development linger and it's important to release fast, gather feedback and update update, update. But how soon is too soon? I imagine IT and developer groups will feel the pressure to release so fast that they end up putting out a skeleton that's not all that useful -- it's a skeleton with potential but it's still a skeleton. 
Building A Mobile Business Mindset
Building A Mobile Business Mindset
Among 688 respondents, 46% have deployed mobile apps, with an additional 24% planning to in the next year. Soon all apps will look like mobile apps and it's past time for those with no plans to get cracking.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Government, May 2014
NIST's cyber-security framework gives critical-infrastructure operators a new tool to assess readiness. But will operators put this voluntary framework to work?
Video
Slideshows
Twitter Feed
Audio Interviews
Archived Audio Interviews
GE is a leader in combining connected devices and advanced analytics in pursuit of practical goals like less downtime, lower operating costs, and higher throughput. At GIO Power & Water, CIO Jim Fowler is part of the team exploring how to apply these techniques to some of the world's essential infrastructure, from power plants to water treatment systems. Join us, and bring your questions, as we talk about what's ahead.