- 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
Poorly Defined Requirements
With software, the old adage is true: “The devil is in the details.” Software can have lots of details, and each one has to be decided upon and communicated. As discussed in the proceeding sections, sometimes the details aren’t considered important, and sometimes they become the source of arguments, but sometimes the problem is one of communication. On many projects, the app creator has an understanding of what he or she wants the app to do but does a poor job of transferring that understanding to the developer who is doing the implementation.
Sometimes this is because the app creator is trying to avoid what he or she considers unnecessary paperwork. When this is the case, requirements documents, if they exist at all, often take the form of lists of bullet points—short phrases that can mean very different things to different people. Often the developers don’t object to this because they don’t like paperwork, either. Then the developers implement what they think is meant by a given line item, the app creator thinks that work has just started on it, and the cycle repeats for a while. It usually comes to a head when the developers check some number of items off the list, and the app creator objects because those items aren’t done yet. Arguments and recriminations may follow from there, and the likelihood of a successful project is greatly diminished.
Other times, the opposite is true. On projects for very large companies, sometimes the requirements document is a large binder full of contradictory legalese that is the output of many rounds of the request for proposal (RFP) process. Verbiage from an early section implies that a feature should be implemented one way, and many pages later in the binder, an answer to an RFP question seems to say that a different implementation is required. Jargon can be a problem here, too, as large organizations often create their own vocabulary. Here, the problem is not a lack of detail but a lack of clarity.
In either case, what ends up happening is that both sides work on the project as if they understand each other—after all, there is documentation that purportedly explains what should be built. The project can go a long time like this, with both sides thinking that everything is going well. And then one day, one side says something that the other side disagrees with, and then the gloves come off. Voices are raised and accusations fly as the two sides begin to realize how far apart they are. Success is not a likely outcome.