Enterprise Mobile Apps Development – 9 Pitfalls to Avoid

By the end of 2017, market demand for mobile app development services will grow at least five times faster than internal IT organizations’ capacity to deliver them, according to Gartner, Inc.
Enterprises are already facing a daunting challenge to rapidly develop and deploy mobile apps to meet increasing demand. Here are 9 most common Pitfalls to avoid in a rapid mobile app deployment.

I want Everything but the Kitchen Sink

The most immediate mistake companies make is to try and replicate everything that is available in the backend screens. The mindset of, “Mobile app is just an extension of my backend system” needs to be fixed. In most cases backend system screens are highly fragmented and it becomes very difficult to navigate among different systems / screens and gather data quickly. Users will end up with same issues on a mobile device if the backed screens are replicated as it is, A forward-thinking Mobile strategy could be the solution to clean up this mess.

“Mobile app is just an extension of my current backend system”

– Business Analyst, Healthcare IT provider

Don’t make the mistake of copying an existing business task / transaction screen as-is to a mobile device. Remember that mobilizing a business process is not about dumping user with all the information available from your backend system, but presenting the right information in the right manner.

Different users have different means and needs of information; designing an efficient UI that focuses on increasing the performance with seamless integration into the content by enabling different set of users to see data they like to see, yet reducing the overall number of fields and clicks in the mobile screen is the biggest challenge, you need to solve.

“I don’t care about all those 101 fields on a Purchase Order. All I see is the Vendor Material and Price fields. It may be different for other approvers but that’s all I need.”

– Purchasing Manager, International Mineral Mining company

Be a minimalist. Limit the data to what is absolutely necessary and what is most commonly used. “Knowing your audience and their behavior” is the key to developing an appealing app that strikes the right chord. An important feature that could be helpful is enabling the end user with the power to personalize the app. So the user can make a choice of what fields to display / hide, and in what order.

Bandwagon Fallacy

Mobile apps deployments are becoming tactical, rather than strategic. Don’t develop and deploy mobile apps because your competitors are doing it. Make sure you have a strong valid Mobility Strategy and there is a definite need to mobilize business processes. A lot of companies build an app for a transaction / task and complain about the poor adoption rate. This is like hiring a Master Chef to boil an egg. Well, that’s not using the mobile capability to the fullest extent.

Get out of, an app for a task mode. Try to engage at a deeper level, an app for a process approach yields in better adoption rate. Closely monitor the app adoption and gather feedback on a timely basis and most importantly keep enhancing the apps as you get updated until the desired adoption is reached.

I love Big Bang

A big bang roll-out does not always provide a high yield and it is accompanied with high-risk. Don’t aim for too much too quick and fall flat on your face. Take baby–steps, start with a pilot–important and easy to deploy apps.

Proof-of-concept of a product will give you a good idea of how the solution will fit into the scheme of things. In case, it doesn’t fit your needs you fail fast and move on. Thus avoiding buying something that doesn’t work out and only to realize it is too late. A good POC would be to do a pilot with limited users in a limited Production Roll-out.

I Know What My Users Want

The number one reason for the poor adoption of mobile apps for that matter any IT project is ignoring the end users and thinking the Business / IT know what the users want. Ignoring the end user is escaping the reality, which will come back and bite you hard. A collaborative effort between IT dept., Business, and End –users with the target audience in the driver’s seat will yield rich results. If the users are following a process for a certain period of time. They engage at the core level and are the best judges of what needs to be tweaked to make the process better.

“Involving end-users will result in a tsunami of requirements”

– IT Manager, Portable Storage Industry

It is better to gather user feedback up front and negotiate on the requirements rather than rubbing on something they are already complaining about.

For example, one of our customers was doing an Activity app and the sales reps. complained about manually creating an activity every time they made a phone call or email to a client contact person. Business / IT had no mechanism to tackle this problem as the backend system doesn’t have a solution for this.

We came up with a mobile solution where a user can choose to create an Activity automatically in CRM system anytime they make a phone call / email from their mobile device. Involving target audience right up front and keeping them involved right through the process helped in creating an app which is the actual reflection of user needs and feedback.

Ignoring them would have resulted in an app with missing features and poor adoption rate. Trusting the users and allowing them to pitch in with new ideas and innovations helped.

My Backend System Doesn’t Give This Field

If I have to point out a favorite mistake made by most of the clients this will be right up there. Because the current backend system process is in such a way, sometimes clients fall into the trap of blindly following the same without giving a thought if there is a possibility to better it.

Do not, Do not did I mention Do not design an app solely based on your backend system possibilities. The mobile app is an opportunity for clients to innovate and tweak the process flow to the benefit of end–users, IT, Business. A better approach would be to design the UI first without worrying about the backend API’s and its fields. List out all the important fields that you would like to display on the screen and then worry about how to retrieve or send those fields to the backend system.

Mobility gives you unique opportunity to mash up and present data from different systems. You are no longer limited to a specific business process from a specific backend system.

“I got to open 5 different apps to get all the info. I need”

– Sales Representative, Global Hi-tech Company

For example, a sales executive can get required info. of a contact from different backend systems(SAP , Oracle, salesforce etc), Facebook, LinkedIn etc. all mashed-up and present in one app instead of multiple apps. This feature gives you a unique competitive advantage.

“I would like to enhance my current process flow by making use of the native mobile capability of capturing an Image.”

 – Operations Manager, Portable Storage Industry

And there are lots of features a mobile app brings in like GPS location, camera, Integration with email/phone book etc. that can be incorporated into the business process. Get innovative and make backend APIs to work for you instead of you working around the APIs.

Training is a Luxury

Even though the process looks straightforward, training is important. Make no mistake mobilizing a process is a change that not everyone is comfortable and users have reservations. One may or may not need training on the user-interface but change management is a whole different thing and training must be included to address any fears and / or concerns.

“I don’t want to hire an instructor to teach, how to put together Lego toys. Users have been doing this for years, why do they need training”

– IT Director, Packaged foods company

Even though the process looks straightforward, training is important. Make no mistake mobilizing a process is a change that not everyone is comfortable and users have reservations. One may or may not need training on the user-interface but change management is a whole different thing and training must be included to address any fears and/or concerns.

Training is an opportunity for users to learn / ask questions / raise concerns. A good approach would be to do a round of training and testing with super users and prepare a list of FAQ’s to get your users ready.

Users are used to a particular screen layout and fields, the mobile apps will have different UI layout and it will need some time for users to get used to. Training is important for the users to embrace the change.

My Team is Busy with Other Projects

Mobile development timelines are brought down from months to weeks with an RMAD and/or MDAP, cloud computing etc. This tempts the customer to try out a POC/Pilot with a busy team. Because the team bandwidth is consumed with other projects, there is a tendency to put the mobile project on a back burner.

In the eyes of a busy IT team, mobile apps is an Add-on feature, and there might be other fire-fighting issues that they are tackling with. Their competing priorities will overshadow the mobility vision.
Either you end up doing a POC/Pilot or full-fledged deployment; a devoted team is a must. Gauge the work effort across teams (IT, business, end-users) upfront and prioritize the project

Merge Mobile Deployments With Other Projects
“I have my backend upgrade going on which will go-live next quarter and I will align my mobile deployments with the same go-live, that way I can have the same team work on it and also I can save on training”

– CIO, Life Sciences & Biotechnology company

This may sound very reasonable but this will bring in new challenges like there is a change in scope of the backend project. Backend project is getting delayed for whatever reason etc.

This will directly affect the mobile deployment. This backend system is not available, not stable, test data is not available and so on. Either pre-plan for these possible delays or work on a POC/ Pilot with limited users to get a gauge of the users, learn lessons from implementation as a project, this will be much quicker now.

We Will Not Support This Device

According to Gartner, employees in today’s digital workplace use an average of three different devices in their daily routine, which will increase to five or six devices as technologies such as wearable devices and the IOT eventually become mainstream. Many of these employees are given the autonomy to choose the devices, apps and even the processes with which to complete a task.

It is a big challenge to support different devices available out there in the market. Not to mention the security concerns, new screen sizes / OS upgrades every now and then. Many people go crazy trying to figure out what works for them. It is tempting to say we will only support so and so device / corporate devices only. Corporate devices will soon be a thing of past. Users don’t like to carry two devices. Bring your own device is a must have these days.

While these cover the major areas of the mobile app development lifecycle, it is imperative that the respective business heads for whom the app is being developed contribute right from the beginning. Their contribution should be ensured so that the outcome is something which will enhance their daily routine. appsFreedom is one platform where you can do a live review with contributors while the app is being developed ensuring an agile development lifecycle. Try it here for Free!