How to Avoid Web/Mobile App Failure

The Mobile App that Failed America

This week the Iowa Democrats caucus experienced an epic fail with their mobile/web app. The ugly truth is nearly every enterprise client has had the same failure; so much so that our #1 source of new business is to succeed where a prior vendor failed.

The stories of a mobile/web app failure all have the same components -- it was delayed, it was delivered without key features and capabilities, the release experienced catastrophic errors and issues, or the selected technology/platform wasn't robust enough. Ultimately, the stories also share the same fate -- the VP of Marketing that made the decision will be fired, a manager will quit out of frustration for being blamed for the decision of their boss, and the end-users -- the customers -- will lose confidence and faith in the brand.

Also, the company will look to blame someone else for the failure, and that blame often falls upon the prior vendor that led them astray. SHERPA will spend the next few months, if not years, course correcting the new client to a better, safer place. We don't relish these situations  -- there are many frustrated parties involved, documentation is non-existent, and there is a lack of institutional knowledge available to us.

As a letter to this future client, here's how these web/mobile app failures can be avoided; all informed from wisdom gained from two decades of building custom web applications.

7 Steps to Avoid a Web/Mobile App Failure

1. What's Your Problem!?

Before you start planning a solution, first understand the problem you will be solving.  This seems intuitive, as the horse has to be in front of the cart, right? Yet, it rarely happens.

Here's what identifying the problem looks like:

• What are you trying to achieve?

• Who will it affect?

• What have the users said needs to be fixed?

• Why are you investing resources into solving this problem?

This is the most critical step of starting on the path towards a technical solution, and yet it is often overlooked. Don't be that person; instead, define the what and why first.

2. How Will Success Be Measured?

You will notice above that we never asked "how" -- as in "how will we solve this?" or "how much will this cost?" That's because those "hows" will come later in the process.

If you are just itching for a "how", then answer this one -- "how will success be measured?" What will the effect be after the solution is put into place? Implicit to this aspect of measurement are two things:

1. What is the current baseline measurement?

2. What is the expected/desired measurement after?

With these two "hows" answered, you can begin to calculate the value of the initiative, and thus a possible budget you might need to start building your web/mobile app.

3. Calculate Return on Investment

Once you have a baseline and expected result measurements in place, you can now establish the elusive treasure of all web/mobile app development projects -- return on investment (ROI).  The good news is that there are many ways to calculate ROI; so many, in fact, that the subject will be covered in another post altogether. In the meantime, here are two quick and easy formulas for your immediate consideration:

1. Monthy Potential Revenue = (# of Leads/Month) x (Customer Lifetime Value)

2. Monthly Cost Savings = (# of workers) x (# of hours/week) X (# of weeks) x (avg. hourly rate) x (% time savings)

4. Define What Users Want

Ok, so now we can start the fun part -- thinking about and tinkering with technical solutions, right? Not so fast. We still need to define the features that the key stakeholders -- investors, leadership, employees, customers -- want from your solution. To do that, you have to engage in another challenging part of building a web/mobile app -- listening to users.

When you ask a lay user what they want, you will experience something magically refreshing-- they will rarely mention a specific platform or technology!  They are not going to say "leverage Drupal feature X to enable the desired effect", nor will they say "build app with Python because I hear it is neat." Rather, you will hear what they want and expect:

• "I want to be able to access X thing while on my mobile device."

• "I want the app to load faster than the current one."

• "I want to be able to export Y data into a spreadsheet, where I can report on it."

Use this user-based feedback to start to build your solution's list of desired features.

5. Prioritize When Users Will Get Features

The full feature-list in hand, it is now time to prioritize it. No web/mobile app release will provide every desired feature on the first-go. Rather, you will work on that list of prioritized features across multiple small iterations across a span of time.  When it comes to web/mobile apps, there is no "build once." There is only "iterate often."

Need help prioritizing the features for your web/mobile app? Try this simple-as-it-gets chart:

6. Figure Out a Solution

Finally, we have arrived -- the Solution!  Now is the time to begin considering which platforms and technologies can help you achieve the prioritized capabilities sought by your users. Unfortunately, this is when you realize that you don't have the resources -- time or money -- to build a custom web/mobile app! Instead, you may seek a more cost-effective, turn-key solution that "mostly fits" your users' immediate needs,  or you will "value-engineer" your first deployment. Don't worry -- you can roll-out a more robust custom web/mobile app several months later after you have proven some success with your first iteration. When it comes to web/mobile app development, the name of the game is "kaizen" -- Japanese for "continuous improvement."

This is also the time you can begin setting expectations with your key stakeholders on the roll-out schedule. If they want something faster, be ready to ask for more budget to commit more resources. However, more is not necessarily better, or even feasible. Sure, China just built two 1,000 bed hospitals in just 10 days, but that required construction teams of 7,000 workers with armies of trucks and excavators dug and scraped around the clock to complete the project. And have you seen what it looks like inside?  These "hospitals" are warehouses filled with rows of cheap wood pallet beds. Then again, maybe that's all that was ever needed -- see steps 1-5 before passing judgment.

7. Schedule to Test. Test Again. And Test One More Time.

So you are ready to go live? Or maybe your boss is demanding you deliver the final product before a big, high-exposure deadline. At this point, there are two things you should say to your boss:

1. Remind them that your roadmap has no "final" product. Rather, you have a strategic roadmap with periodic, planned iterations.

2. Clarify that you have weeks or months of testing.  If they balk, remind them of the fact that testing will ensure their success with their own boss.

When it comes to testing, there is no right length of time. As a rule of thumb, however, we recommend a minimum of one week for every month of development, with a minimum of 4 weeks. Seem like a lot to you? Here's all the testing you will need to consider in your process:

1. Quality assurance by the vendor

2. User scenario testing by the vendor or client

3. Key stakeholder feedback/review by the client

4. Stress and/or load testing by the vendor

Once a round of testing is completed, you will need to decide which of the unforeseen issues revealed during testing you want to address now, or later.   If you elect to address some issues now, prepare your budget and timeline for another round of testing.

Final Thoughts on Web/Mobile Apps

The Iowa Democrat caucus app built by Shadow, Inc cost only $60,000 -- and that was enough to deliver a failed, untested mobile app!  We get it -- change is hard, and improvement is even harder.  To be successful, just keep asking "what/why", avoid buzzword bingo, and focus on execution.

If you are thinking about your next web application or stuck with current web app development, just holler for a SHERPA to help guide you to success!