- 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
Constantly Changing Requirements
Another thing that can cause a project to fail is indecision. Many projects start without a clear idea of what needs to be accomplished and have the design spend months changing over and over while never getting any closer to a ship date. Hundreds of thousands of dollars get spent, and there’s no evidence that the design changed for the better during the process.
Sometimes the trigger for this is user testing; sometimes it’s anecdotal, with someone showing the app to a friend or two and the friend(s) not immediately understanding how the app is supposed to be used. Sometimes someone says it just doesn’t feel like the design is progressing in the right direction. Sometimes the desire is to find something “better” than some competitor’s app, but with no clear idea of what “better” would look like. However it starts, it costs a lot of money and doesn’t accomplish much (if anything).
What makes this especially hard is that there are times you can tell from user testing that an app design really isn’t working. You don’t want to ship a design that people can’t figure out, so it’s important to get a better design. The problem is the amount of money that change will cost.
When I see this happen, it’s usually for apps that went from concept directly to coding and skipped the prototype phase. The point of a prototype is to get a design in front of people to figure out whether it works in the cheapest way possible. If you figure out that users aren’t understanding (or liking) your app, you can try a different design (or several different designs) without needing to have a single line of code written. If there’s confusion in the middle of a project, you could even hopefully move all your development effort to a part of the app that you know will stay the same (like data storage or networking or something) while you show potential users several different prototypes in an effort to get clarification. (For more information, see Chapter 3, “Prototyping and Wireframing Your App.”)
But if you are well into building your app when you run into problems and you try to quickly come up with a new design that you think will be better and have your developers start coding on it before you know whether it’s going to actually improve the user experience, you’re starting a chain of events that can lead to months of churn with nothing useful to show.