Developing a bespoke app for an enterprise is a risk, there is no doubt about it.
Some IT projects, such as moving to the cloud, can be done without significant capital expenditure. The growth of the pay-for-what-you-use model in IT allows (relatively) risk-free innovation, since if the service does not perform you can simply shut it off.
By contrast, building an app to be used in the enterprise is a considerable sunk cost before anyone has even started using it.
An article by Formotus cites a range of different estimates of costs. For example, a Kinvey report from November 2014 saw 18 percent of CIOs and mobile leaders saying they spent from $500,000 to over $1,000,000 per app, with an average across all respondents of $270,000 per app.
According to a review of the market by Savvy Apps in 2015: "Apps built by the largest app companies, the "big boys", likely cost anywhere between $500,000 to $1,000,000. Apps built by agencies like savvy apps cost anywhere between $150,000 to $450,000."
Paul Swaddle, meanwhile, CEO of independent app developer Pocket App, says that an app costs "as much as a car". He means that the quality of product varies considerably with the amount you are willing to pay.
Whatever the specific sum is, the message is clear: a company simply can’t afford simply to get an app wrong.
How can this be avoided? By getting the app wrong, over and over again, until you get it right.
According to Magnus Jern, President of Mobile Applications and Caroline Van Den Berg, VP International of DMI, the key to launching a successful app is testing. The firm provides end-to-end mobility solutions, which has included providing apps to Warburtons, the bread company.
"Test, test, test, test, test is our mantra about everything through from the initial phase to proactive testing," says Van Den Berg.
Jern points out that apps can take one and a half years to build, and by this point may be obsolete. However, as he notes, by this point it is too late to do anything about it.
But perversely, this delay is due to over-caution; the companies are so afraid of putting out something that is bad that they don’t put anything out at all.
"People are so afraid of launching something that is not ready. Everybody talks about agility but not many people actually do it, because once they get into the politics of the company it turns into these monstrous projects.
"Once they get close enough to launch they are just not happy and keep on improving it and improving it," says Jern.
Van Den Berg says that the most successful software companies are deploying much more rapidly than this.
"A company like Amazon releases every 11 seconds because they are constantly prototyping but also doing things like AB testing," she says. "Even once you’ve launched you can use that same process to make sure you’re keeping on top of the game."
Jern also highlights Gmail being in beta mode for ten years.
"So many software projects fail, mainly because of the lack of testing and validation at the beginning. Google changed that quite a lot with its build-test-build-test method," says Van Den Berg.
They argue that getting the software out to the users and seeing how they react is the most effective way to ensure that the final product works.
"Analytics can help you see if you’re converting well, the voice of the customer and the end-user," says Van Den Berg.
To prevent the potentially flawed application from alienating users, the key is to ensure they are aware it is not the final version.
"If you just tell employees that this is not the final version and they get to be part of feedback and improving it, people will be a lot more open to issues. If you’ve already invested twelve months in something, you can’t afford to change it afterwards," says Jern.
According to Jern, if the app is out there quickly there will be the opportunity to improve it.
"No-one expects the final product to be perfect, but no-one wants to be told what to do. They like to be part of it," Van Den Berg says. "That becomes a good part of communicating and ensuring that they do provide that feedback."
However, they argue that the fixes to the problems raised need to be quick; the live testers cannot wait several months for improvements.
Finally, Jern adds that it is important to know what the app is actually trying to do.
"It is also important to have a clear idea about what success is. You may have these big plans at the beginning but they are forgotten along the way. Then you have to justify that whatever you did was good anyway.
"You need to ensure there is accountability in terms of making sure there are very clear metrics," he says.
This article is from the CBROnline archive: some formatting and images may not be present.