Strategies for App Development Success: What Could Possibly Go Wrong?
- App Projects Are Not Small and Easy
- Apps Are Not Easy to Program
- Poor Skill Set Fit
- If You Get a Good Developer, You Still Have to Worry
- The Idea Is Not More Important Than the Execution
- Unwillingness to Delegate: Micromanaging
- Bikeshedding
- Poorly Defined Requirements
- Out-of-Date Requirements Documentation
- Constantly Changing Requirements
- Leaving the Worst for Last
- Cost Overruns
- That Last 10%
- The Whack-a-Mole Problem
- Poor Communication
- Abdication of the Management Process
- Wrapping Up
This chapter is from the book
This chapter is from the book
This chapter is from the book
In my consulting practice, I am often asked to take over, or at least examine, app development projects that are in trouble. Usually, months of effort and tens of thousands of dollars have been expended, and I often find that the quality of the existing development is so bad that it would be less work to just start over. I dread few things more than breaking that bad news to entrepreneurs, business owners, and managers. Those conversations are unpleasant and heartbreaking.
I fervently hope the information in this book can reduce the frequency of those conversations—not just for me but for all competent contract app developers.
One aspect of most of those conversations is surprise that the situation could possibly be so bad. Part of it is pure denial: People never want to find out they’ve wasted their effort. But I think there’s more to it than that. I think that there is a common misconception that apps are easy to make and that any developer ought to be able to make them. Unfortunately, that is simply not the case.
App Projects Are Not Small and Easy
Compared to enterprise software running on a desktop or in a web browser, it’s true that apps are smaller and cheaper, but that’s really not saying a whole lot. A fairly typical iPhone app project in 2014 can take two or three developers three or four months and can easily run between a hundred thousand and a quarter of a million lines of code. While that’s not a lot compared to some kinds of development, it’s not trivial.
Through the years, many studies have reported that a significant percentage of software projects fail (although the percentage can vary wildly). App projects are definitely software projects, and they have many of the same issues and risks as any other software project. App projects can and do fail—some of them spectacularly. I haven’t seen any studies specifically on the percentage of app development projects that fail, but I’d expect it to be similar.
I would say that anecdotally more than half and maybe as many as two-thirds of app projects I have knowledge of would be considered failures under the criteria outlined in the following sections. Several examples of such project failures can be found in sidebars in this chapter (and throughout the rest of this book). This is not a scientific survey, and I don’t know how representative my experience might be. I have talked to many would-be app creators about what it would take to rescue their failed projects (some I could help, many I could not), and this might skew my experience. However, I know other app developers who have also spent a significant amount of time attempting to rescue failed projects and their anecdotal estimates are comparable.
Defining Project Failure
Let’s talk about what I mean by the word failure in the context of app development. Different people and different studies use different definitions, which is likely part of the reason that different studies reach such different conclusions. When I say a project failed, I mean that one of these four things happened:
- The app failed to ship (that is, didn’t become available to users).
- The app failed to work (that is, didn’t work as intended for a noticeable percentage of intended users).
- The project cost significantly more money than planned (more than 10% or 20% over budgeted funding).
- The project took significantly more time than planned (more than 10% or 20% over budgeted time).
Let’s talk through these situations.
First, the app has to ship. I think we can all agree that if the app was never seen by any user in its target audience, then the project failed. You have to ship in order to succeed. End of story. This is the least controversial of my criteria.
Second, the app has to work. This doesn’t mean that the app has to be bug-free, as virtually none of them are. But the end user has to be able to use it in order for it to be called a success. This can be a subjective criterion; there can be legitimate arguments on both sides about whether an app is “useable” or “functional.” For purposes of determining via this criterion whether an app has failed, though, it’s usually either clear or irrelevant. (This criterion is irrelevant if the last two criteria fail, and if the app’s functionality is in question, they usually do.)
Finally, the app can’t have gone significantly over budget or schedule. These final two are the most controversial of my criteria, but I stand by them. I live in a world where I have customers, and those customers are depending on me to produce an app for them. Those customers care how much it’s going to cost and when it’s going to be done, and they need to plan on that.
Getting Clarity on Functionality
The second criterion, “the app has to work,” is necessarily subjective. It depends very much on the nature of the app and the project, and it’s just not possible for a book to give an unambiguously measurable way to determine functionality for any possible project. But that doesn’t mean you can’t.
Every app creator should (although most don’t) insist on writing into the contract (or an accompanying statement of work) criteria for determining whether an app is considered fully functional. Agreeing on that up front (and amending it as you go, if needed) can save a lot of disagreement later.
Project Success Is Mostly About Estimates
Notice that the last two criteria—the project cost significantly more money or took significantly more time than planned—make a distinction between the outcome for the app itself and the project that produced it. It’s possible (and not uncommon) for an app to be launched successfully but the project that produced it to have been a failure. Many contract app developers who get paid by the hour would likely count such a project as a success. If the app makes it to market and gets good reviews and the client company paid the bill, then most contractors are happy, even if it took twice as long and cost three times as much as planned.
To me, this feels dishonest. If a contracting company tells you that they will build your app for $50,000, but in the end you end up paying $75,000 or $100,000 or more, I consider that a bait-and-switch tactic. And it’s unfortunate because it creates an incentive for contracting companies to generate unrealistically low estimates, knowing that they’ll just charge the customer more in the end.
Project Success Is Also About Scope
An estimate, however, is only valid for a given scope (a given set of features). If new functionality is added to a project, then the budget and schedule have to be revised.
There is sometimes a disagreement about whether a given feature or bug or issue is within scope. Assuming that everyone is acting in good faith, such disagreements result from failure in the communication process between the client and contractor. Scope should be documented unambiguously.
Communication failures arise consistently, though, and often contractors who work on a time-and-materials basis choose not to clearly define the scope. Assuming that they can talk their clients into continuing to pay, this is to their advantage.
Another tactic contractors use is ignoring the scope as agreed and beginning work on new features as if they are in scope. This leads to unpleasant conversations after the work has been done. It should be incumbent on a contract developer to make sure any changes to the scope are mutually agreed upon and documented before work on the new functionality begins.
The Specter of Unprofitability
There is one important factor about an app project’s success that these criteria do not take into account: profitability. I can’t consider profitability in my criteria because I don’t generally have access to app revenue information. All I (or any contract app developer) can do is build the best app I can within the time and budget I promised.
But profitability (or at least return on investment [ROI]) should be important to app creators. And if I had access to profitability information and could consider ROI goals as a failure criterion, then I would expect an even higher percentage of app projects to be failures. As it stands, app projects have to make it all the way through the funnel depicted in Figure 1.1 to be ultimately successful. I don’t know what percentage of apps fail at each stage, but I’m confident that a large percentage of them don’t make it all the way to profitability.
)
Figure 1.1 App projects must work through this funnel to be ultimately successful to their creators.