- 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
Leaving the Worst for Last
A constant theme I hear when talking to app creators about their failed projects is that things seemed to be going very well right up until the point where they thought they were about to be done.
It’s rare that a project fails a week or two after starting (and if that happens, it’s usually due to an external event). This is because at the beginning of a project (or at least the beginning of the development phase of a project), there’s often nothing to see, so expectations are low. It’s only when the project has been going on long enough that there should be something to see that expectations are raised to the point that failure seems an option.
A common pattern is that the developer periodically meets with the app creator and says that progress is being made. Something might be shown at the meeting, but there seems to be plenty of time in the schedule to get the rest of the work done. As the time remaining in the project dwindles, the app creator might begin to be uncomfortable but is assured that everything is still on schedule, and there’s nothing to worry about. It’s only when the app creator looks at the list of outstanding items and sees that the schedule is almost gone that the platitudes of the developer start to ring hollow, and the app creator can no longer believe that everything is on track. This is when the failure becomes obvious.
There are two ways this can happen. First, the developer may be dishonest and just lie to the app creator, trying to get as much money out of the deal as possible. Second, the developer may be incompetent and genuinely just as surprised as the app creator when things seem to fall apart at the end. The good news is that the same remedy works for both of these cases.
To avoid failure, it’s important to identify the pieces of a project that have the most risk and push them as early into the project as you can. That way, if there is going to be a problem, you can find out about it before you’ve spent most of your budget and you still have money to pay for a different developer.
For what it’s worth, the two things that I find to be the most risky on the majority of projects are integration and performance. Not coincidentally, these are often the last two things that are done in a project before testing starts in earnest. This is not the best risk management strategy.
Figure 1.3 shows a typical project development schedule. Note how right after the project begins, many tasks are started in parallel by several different developers, and only toward the end is their work integrated (connected together) and tested for functionality and performance.
)
Figure 1.3 A simple Gantt chart for part of a fictitious project. Note how all three views are created and styled before the integration test starts at item #4.
Figure 1.4 shows a different schedule for the same project. Note how much earlier the first integration and performance test occurs. This is a much safer plan because, if problems show up in the test, there is far more time to deal with them.
)
Figure 1.4 An alternate Gantt chart for the same part of the same fictitious project as in Figure 1.3. Note that the integration test has been moved much sooner in the project, to item #2.
The downside to using this technique is often calendar time. Typically you can complete an app in the smallest amount of time if the project is chopped up into many small pieces of functionality, and each piece has a different programmer, and all their work is hooked together at the end. The problem is that this is a high-risk strategy: If something goes wrong, you don’t know it until the very end, and then you might not have money left to fix it. Many development shops love this model, though, because they can extract the maximum number of dollars in the minimum amount of time, and they don’t have to show an app that actually works until most of the money is already paid.
But if you want to reduce your risk, time is on your side. By having your developer build a piece at a time and not moving on until it’s integrated and working, you reduce the amount of your budget that you spend before you have evidence that things are proceeding the way you need them to.