I’d like to talk about something that you all know: the real systems development cycle. This is significantly different from the cycle discussed in most systems design books.

All projects begin with a kick-off. This can range from a visit to your cubicle by your manager to a major meeting where managers sign off on some budget document. At the kick-off (or shortly thereafter), a set of dates is published, listing the milestones for the project and when they’re to be achieved.

Let’s skip ahead over the initial milestones and get to the first one that matters: the day the project leader realizes that you’re not going to make the deadline. Shortly after this, a new schedule is published in which the final deadline for the project doesn’t move. Instead, the project is redefined, or a few resources are added to the project, or some other action is taken to “keep the project on track.”

I’ll skip over the dates in the revised schedule to get to the second real milestone: the day that management admits that you’re not going to make the deadline. A new schedule is published with the project’s date moved out. Either at this point, or after the next schedule revision that moves the delivery day out, a new feature is added to the project: the change management process.

The importance of the change management process can’t be overstated. Its first purpose, of course, is to provide a mechanism for denying service to your customers (“No, you can’t have that now”). The second purpose is to blame the user for causing the project to be late (“If it weren’t for the changes, we would have delivered by now”).

Introducing the change management process triggers the appearance of the backlog. Rather than simply tell users that they’ll never have some feature, management mollifies them by putting all requests “on the backlog.” The implied promise is that those requests will be handled at some point after the project is completed. The illusion of this promise is sometimes enhanced by a priority system that stipulates how long after the project is completed a request will be processed. No one discusses the implied staffing levels that would be required to process the backlog. Management also now segments the project into several projects that will be implemented in series.

The last real milestone occurs when the do-or-die delivery date for the first of these segments is published. Typically, the system (or some part of it) is inflicted on the users one or two weeks after this date.

With installation, the backlog immediately increases by a factor of 10, and all previous requests fade into oblivion.

Now that the system is being used and has an impact on the company’s ability to do business, real people (i.e., not managers or IT staff) start complaining. Significant resources are assigned to the team. Dramatic reduction in the backlog is achieved over the next three to six months.

Eventually, complaints about the system are reduced to what’s regarded as the standard level for computer systems in the company. The realization that the rest of the system isn’t really necessary sinks in. The team is distributed through attrition to other projects, leaving one programmer to maintain the system (usually the most expendable member — lucky users). The project ends.

I told you that you already knew this.