- 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
- 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 book spends quite a bit of time discussing risks. The cost of a project turning out to be way more than expected is probably the most likely failure mode in the contract app development space. This is sad because app development billing rates start higher than those of many (if not most) other forms of contract development right now. Costs are high under even the best of circumstances, and they become downright stratospheric if not kept under control.
Much of this book focuses on getting you your money’s worth, but the following sections discuss a few of the most common ways that costs get out of control.
One way that projects run way over budget is by having too many developers. The more developers a project has, the more communication effort is required. Each additional developer is not only less productive than the previous one but actually slows down the existing developers. This effect was documented in 1975 in The Mythical Man-Month by Fred Brooks (which I mention several more times in this book).
Especially when your development company has a number of developers on salary who are idle, the company may pressure you to have more developers on your project than you need. Make sure that the company can articulate what every developer will be doing and why each is necessary before you approve additional headcount.
Unnecessary or Wasteful Work
Not all work gets you closer to the project’s goal. Some work turns out not to have been worth it. Under what circumstances should you have to pay for that?
First, understand that just because a particular piece of work doesn’t make it into the final product doesn’t mean it was wasteful. Sometimes there’s more than one way to implement something, and it makes sense to spend time experimenting with multiple possibilities to figure out which is the best fit for your app. It’s better to do that than to guess with no data and risk ending up with an unworkable solution. These experiments are often referred to as spikes, and we discuss them more in Chapter 2. Mockups and prototypes are also useful work that won’t ever ship, and we discuss them at length in Chapter 3.
However, some kinds of work are wasted. What happens when a developer makes a mistake? What happens when fixing the bugs in a feature turns out to take twice as long as building that feature initially? What happens when the developer you got was less experienced than the developer you needed and ended up making a mess? Under many contracts, that cost is passed directly to the app creator, so there’s not a lot of incentive for the developer to get it right the first time.
Unproductive Billable Time
We touched on this earlier: Developers should be developing. Try to keep meetings and administrative tasks to a minimum and make sure you aren’t being billed for time when the developer is not working on your project. (For example, time spent eating lunch should not normally be billed to you.) Note that explaining and documenting the code that is being written should be considered part of development, not administrative time.
Sometimes projects run into bugs that take a while to fix. Sometimes those bugs are in code that the developer wrote, and sometimes they’re in third-party libraries or the framework for the mobile platform itself. Bugs always happen, but most of the time they don’t take a project off the rails. Sometimes they do. However, project-endangering bugs should not happen in areas of the project that are similar to what your developer has done before. Talk to your developers about what risks they see in your project before you start. (See the “Gap Analysis” section of Chapter 8 for more details.)
Sometimes bad things happen. Sometimes developers become ill or quit or have to leave a project to care for a sick family member. Developers are human, and most humans have chaotic and unpredictable periods at some points in their lives. Discuss what might happen in such a case with your developer before work starts. (See the “Contingency Plans” section of Chapter 8 for more details.)
Poor or Changing Requirements
As discussed earlier in this chapter, requirements need to be clearly decided, communicated, and understood. If they’re not, they might as well be randomly generated.
Poor Initial Estimation
One of the things that can throw project costs far afield is unforeseen work being “discovered” or “found” during the development process. If this sort of thing occurs and wasn’t a result of bad requirements, then it was most likely missed during the estimation process. Ask your developer before work starts about who will pay for poor estimates and how much. (I suggest that you at least should never have to pay full price for work that wasn’t estimated.)
The other common result of poor estimation is everything just taking longer than expected. This could be a result of insufficient information during the estimation process (which happens a lot on projects that involve taking over a code base that someone else wrote and the code base turns out to be worse than you thought). It also happens when the developers who end up on your project are slower and less experienced than the developers that the person doing the estimation had in mind (in which case you probably shouldn’t be paying the same hourly rate as the estimator had in mind either).