How to Fail at Software Development

11. Who originated the schedule? Did it sort of come down from the mountain?

Score at least 1 if each programmer was able to set his own schedule with limited outside influence. The outside influence was limited to a preference for the overall end-of-project date, but some leeway was allowed. During the project, incoming changes affect the amount of work to be done but the schedule never changes to match the changes. This is a common situation. If this situation is blatant and there are a lot of changes, it may score as high as 5.

Score at least 2 if each programmer presented his time estimates, but they were made with outside influence. The programmer is told something like, “Here’s the specification, and these are the parts you will be doing. I want you to take your time and make out your own estimates for how long it will take to do each of these. You can make out your own schedule, and that will be the one you’ll need to stick to. I’ll need your estimates by noon tomorrow and remember—the entire project must be done by July 15th.” You can see that the programmer has very little to do with the actual schedule. In every case, when this happens, the schedule is too tight and something crucial has been left out.

Score at least 3 if the programmer made his best estimates, under any circumstances, and management trimmed the time as an incentive to get the project done sooner. The manager who modifies the schedule most likely has no idea what it takes to write programs. This trimming can be as much as one half, in which case the score should be higher, but even a trimming of ten percent will cause problems because all programmers are optimists anyway. Some of the original estimates are too short to begin with, so shortening them further only increases the level of silliness. But, in the end, the programmer will get the blame because, hey, it was his schedule, right?

Score at least 4 if the schedule came in from elsewhere and the programmers were only allowed comments about some of the items. The person making out the schedule probably has limited knowledge of software development. But if the scheduler knows something about software development, the schedule is made out as a tight estimate of what the scheduler could accomplish, not what another programmer could actually accomplish. The schedule is tight, but the programmer will have some input on the parts that are overly absurd and will be allowed to make some changes.

Score at least 5 if anyone besides the programmers makes out the finished schedule. It will be wrong, of course, as it will be extremely short. It will be fiction. Wishful thinking. The whole project will fall behind in the first week and the schedule will never be seen again as it recedes into the distant past. It will soon be forgotten entirely and the project will struggle on without any kind of schedule or a real plan.

Of course, none of this schedule stuff applies if this is one of those projects that can run forever without end. Believe it or not, such projects do exist. But there is no need to consider such a project here—by the definition of failure, they can’t fail no matter what.

Scheduling is discussed in several places in the book How to Fail at Software Development because there are a number of ways scheduling can be misused to derail a project. Chapter 11 is dedicated to the process of creating unworkable schedules.