Businesses are moving fast to address the demand for both employee- and customer-facing mobile apps. However, there is a danger in rushing. Here are five ways to avoid pushing out a mobile app too soon.
Workers and consumers are constantly on their smartphones and tablets these days, so it's no surprise that companies are rushing to put out mobile apps to better serve their employees and customers.
Some companies fail because they produce an app too quickly, which forces them to then make updates along the way based on feedback and functionality. To avoid pushing out a mobile app prematurely, here's a laundry list of things you need to do and do right.
[Related: The Enterprise App Store: 10 Must-Have Features ]
[Slideshow: 10 Top Mobile Application Development Platforms ]
1. Develop a Mobile App Roadmap
Before rolling out a mobile app, you must have precise plans in place. Decide on the overall goal of the app, how you will measure its success and how it will make users' lives easier. "The biggest problem for most companies is that they don't have a good definition for what they really want," says Jack Gold, founder and principal analyst at J. Gold Associates.
Gold says companies need to put together a detailed roadmap of what steps need to take place when and how much each will cost. Design and development costs, on average, range from $200,000 to $350,000, according to Forrester so each dollar needs to be carefully spent. Also, make sure to build padding into the timeline of the roadmap. "Assume it will take longer than you think it will and it will cost more than you think it will," Gold says.
For each step, collect deep research about users and their habits because ultimately they will be the ones using, and hopefully benefitting, from the app. "Do your homework, define what you want and get feedback from customers," Gold says. "Do it right the first time if you can and understand what it is you're trying to build, then program it. Don't just do it because competitors are doing it."
2. Choose Between an Outside Agency or Full-Time Mobile App Developers
You should carefully evaluate whether development should stay in-house or be contracted to an agency or freelance developers. Large companies tend to have the resources for full-time in-house developers because they have larger IT staffs. "If it's a larger company with a very robust online presence and lots of mobile apps, they might have a full-time person," says John Reed, senior executive director at Robert Half Technology.
Michael Facemire, senior analyst at Forrester Research, says nominating an internal IT person for a mobile app project requires some questions. "It depends on [more than] how much software work you've done in the past," he says. "People that have done tons of software [work] say mobile is different."
Gold says that it's very difficult to find one person, with design and programmer skills, who can handle an entire project. "Finding a good general practitioner is hard, you are better off finding a certain skill set," he says, in which case a group of independent developers or an agency team would be a better option.
More often than not, companies think they can find the right person internally but come to find out later that they should've gone with an outside agency. "It's more common to see folks that say they can do it, [but as the project goes on they realize] it's not really working out," Facemire says.
This seems to ring true, according to a recent Forrester report [ Build Your Mobile Engagement Strategy] that found that only 17 percent of IT decision makers consider it a priority to hire IT staff with mobile development skills this year.
When considering signing with an agency, look for firms that match the size of your organization. Gold says big companies often go with big consultancies and mid-size companies may go with smaller consultants, and so on. "Your representation may precede you," he says. "Generally it's big consultant houses that get big contracts."
Going with an outside agency is similar to buying enterprise software, says Facemire. He recommends starting with a Web search of agencies in your region and looking at what each has done in the past. "A lot of efforts that are done for other enterprises are public things," he says.
Gold says you should demand evidence of the agency's prior work, similar to how engaged couples would select a wedding photographer. "'Show me,' that's what I'd be asking," he says. "Ask them, if you're serious, to do a sample, put something together and show what the design might look like and do a few screens."
Lastly, be sure to find out how the agency has integrated apps with existing software systems or lifecycle management systems at previous companies and how they plan to with yours. "You don't want a one-of offering," Facemire says. "You want it to work well with your system so you can continue using it for all your systems and investments around applications."
3. Nominate an IT Project Manager or Business Sponsor
Once you have selected the agency or person to manage your mobile app project, designate someone in IT or the line of business to act as the project sponsor. For example, if the app is going to be designed for marketing employees, nominate someone in the marketing department to oversee the project to make sure it aligns with their goals all the way through. Or, if the app is going to require maintenance or any later work from IT, select an IT person to take part in the process so they are clued in.
Gold says it's more important to have a line of business person associated with the mobile app. "You need to have a champion in the line of business," he says. "Line of business folks are in a better position than IT. Look at this as a partnership. You have to have IT in there, but IT shouldn't lead."
When working with an agency, Facemire says to be aware that "rarely is it a purely business agreement, there are always individuals or internal people doing the work, or internal people that work with agencies to coordinate the work that's being done."
4. Do a Pilot
Feedback is one of the most important things when launching a mobile app because programmers and designers won't be the actual users. Developers should take a break from the computer and immerse themselves in the app, to anticipate what users will like and dislike about it. "The one thing that will doom an app faster than anything is to have a programmer who never uses it [design it without getting] feedback from users," Gold says.
You can do pilots in small groups or push it out to the entire user base. They should ask users to use it like they would any other app and note pros and cons.
5. Ask for User Feedback
During the pilot, request tons of feedback and meticulously look at it before the app goes to market. Then, once it has launched, the feedback loop should not end, but rather it should be a continuous process throughout the lifecycle of the app.
In a recent report [ Build Five Star Mobile Apps], Forrester recommends using mobile feedback management tools such as TestFlight, HockeyApp or App47 to automatically collect feedback from users. You can get feedback through the app itself but also through many other channels such as social media, the company Website, or the app store. Feedback doesn't have to be a voluntary thing either; companies should be out there requesting it whenever appropriate.
Eventually all the feedback will start to pile up at which point Forrester says it's helpful to assign someone or a group of people to listen to the responses and circle back with users, especially the unhappy ones.
Gold says all-in-all the process of developing and launching a mobile app should never be like throwing spaghetti against the wall. A lot can ride on a mobile app such as perception of the company, customer satisfaction and big money investments. "[A] bad approach, is costly," Gold says. "This stuff isn't free and it ticks off customers. Once they try it and don't like it, the chance of them coming back is not real high."
Read more about mobile/wireless in CIO's Mobile/Wireless Drilldown.
This story, "5 Ways to Avoid Mobile App Development Failure" was originally published by CIO.