StoryDesk

When iPad Apps Fail: Lessons for Project Leaders

We sat in a stylish conference room in Covent Garden. The head of digital for a major UK interactive agency shut the door and slid the iPad across the table with a pained smile. Her team had developed an app for a major financial services firm. $140,000 and 6 months later they were about to start again. The client was, unsurprisingly, unhappy. The agency was concerned about getting fired.

What went wrong?

As StoryDesk approaches its second anniversary, we’ve seen the casualties of iPad apps gone awry. These failed projects cost businesses time and money. Project leaders are often personally blamed. Domain inexperience is typically the root cause.

In the interest of shared learning, here are the top 3 reasons enterprise iPad apps fail:

1) Static, hard-coded content
Most iPad apps are built with the text, photos, and brand elements “hard-coded” into the software. For both client and developer, this approach is the most expedient path to completion. But then what? If there’s a typo, a product change, or a new piece of content you want included in the app, it requires re-engaging the developer to programmatically make a change. It’s expensive and impractical given the dynamic nature of business content.

2) No innovation plan
Software development is not the same as remodeling your kitchen. When the remodel job ends, the workers gather their tools and leave your home for good. Software is a continual journey of innovation. Apps must constantly be updated, modified, and evolved as they live in a highly dynamic ecosystem. User expectations and needs change. New technologies emerge. New hardware demands new development. Recognize and plan for this – both in terms of the technology you choose and how you fund and staff it. Consider hiring a product manager to own the apps within your company.

3) Try to do too much
The textbook definition of an application is a piece of software designed to perform a specific task. Singular. Apps that are specialized and focused win the day every time. By contrast, apps that take on too much often fail to meet expectations. It’s really easy to dream up the comprehensive solution. It’s much harder to execute on it. It’s even harder to train people to use it. You don’t want to build a version of Microsoft Office. Cross-division teams working on an iPad app are particularly prone to a “no feature left behind” iPad app. As the project leader, you’ll need to get used to saying no more often than yes.

What lessons have you learned from your company’s iPad app deployment? We’d love to hear from you on Twitter.