6 reasons you should take an iterative approach to your enterprise mobile app strategy

By Arvind Rangarajan

IBM

Have you ever wished for a feature you could incorporate into your favorite mobile app but you continued using the app even without that feature?

A great example of this scenario is the message recall feature on WhatsApp. Users wanted a way to delete messages that had already been sent but continued using WhatsApp even though it didn’t have that feature. Mobile app users will always look for additional features on mobile apps, so app rollouts continue even if those features aren’t available initially.

Organizations will benefit from applying this same principle to their enterprise mobile app strategy. It’s imperative to roll the app out to users once you’ve implemented a base set of features or the app meets the standard of your minimal viable product (MVP). You can address new requirements or even defects with quick app updates. The evidence is in the number and frequency of app updates that you see in platform app stores and the first releases of all your favorite apps.

Enterprise mobile app deployments differ from traditional application releases in many ways and present some unique challenges that impact the success of a single large app rollout. Here are some reasons you should take an iterative approach to rolling out your enterprise mobile apps:

1. Context shift for users

Developers center traditional apps around enterprise systems and almost always provide the same set of functions and interfaces to all types of users. In contrast, mobile apps are tailored to specific users or user groups and follow day-in-the-life scenarios — with some exceptions including the apps for mail and employee directories, for example.

Users experience a huge context shift when making a sudden switch to a mobile app that potentially redefines how they work, especially if it’s the first app that’s rolled out to them. They need to adjust to the workflow provided by the app. The success of any mobile app is defined by its wide adoption by users, and this context shift might be deterrent to its adoption. You can address this by making a steady transition to the full-fledged app by adding features incrementally while incorporating feedback from the shorter initial version.

2. Operating system upgrades

Platform vendors release new and critical mobile operating system (OS) upgrades within a year or less of major OS rollouts. When a single app development spans across two major OS releases, it prolongs the project duration and introduces complexities such as new DevOps tooling in the middle of the project.

Since the new OS features are often known only a few months or weeks before general availability, the public could not have used them in the original mobile solution design. App release cycles must be short and should ideally begin and end within two major OS releases. App upgrades are easier to perform on a stable working version than one under development. But the best practice is to plan a dedicated release for an app upgrade.

3. Form factors

Mobile device vendors launch new models with varying form factors frequently. Getting the enterprise mobile app on the latest device model enables a better adoption of the app by the target users. In some cases, the app designs created for a specific form factor might not be fully compatible with the newest model. So by the end of a major release cycle, users might be left with using a new app on an old device model. Quick app updates are a better option to support a new form factor compared to a redesign of the app during the development cycle.

4. Business and IT priorities

Several factors affect an organization’s business and IT priorities, such as changes in market situations, product vendors and stakeholder needs. An example of this could be a companywide mandate to host applications on the cloud or add a critical enhancement to an existing application. Budget restrictions and changes in app regulations, such as data protection rules, might drive the decision as well. These unplanned requirements will demand updates to the mobile solution design or staffing plan, and often affect the project schedule and costs. If the scope of the enterprise mobile app is small for a specific release, the impact of changes in business and IT priorities will be minimal.

5. Organizational changes

Though mobile app development primarily focuses on the technical aspects of the solution, enterprise apps need business skills and domain expertise. Skilled resources such as business analysts are critical to ensuring development defines and validates business objectives. They play a huge role in requirements analysis and user testing.

Mobile products also involve other essential roles, such as DevOps or user experience consultants. Organizational changes might result in these experts being unavailable for a prolonged period to implement a single solution. Small release cycles drive a better utilization of their time and ensure the necessary expertise is constantly available due to the shorter release time frames.

6. Changing customer needs

Enterprise apps targeted for customer-facing professionals such as field technicians, flight attendants and sales representatives help to enhance an organization’s reputation or improve customer satisfaction. They enable employees to present a professional image to the customer and address their concerns faster when using the apps. It’s not possible to anticipate every customer need and design an app that supports it, so the more quickly the app is put to the test in real-life situations, the faster DevOps can incorporate findings into the app. Apps built incrementally are often better equipped to meet employee needs.

In addition, an app with a lot of functionality might leave some features undiscovered by the users without the proper training. Apps need to be intuitive, but that might not be fully achievable when an app is packed with features. Though an iterative approach makes for better app strategy, releasing an app too quickly presents the risk of low adoption. Choosing a business need that’s common to all the users is a good starting point to plan an app release. This strategy must be supported by teams, infrastructure and process to roll out quick app enhancements.

Written By

Arvind Rangarajan

Architect for IBM MobileFirst for iOS Garage, IBM Client Innovation Center – India

Arvind is an IT Architect at IBM Global Services. He specializes in PLM integration using OSLC, as well as, designing and developing Mobile applications.

Other Articles by Arvind Rangarajan
See All Posts