As you move from project to project, have you ever marveled at how the meaning of the word "schedule" seems to change? This is not a delusion! "Schedule" is an emotionally charged word. At present there's no agreement about what a schedule is, or what it's supposed to do. All we know for sure is that the word is supposed to get people excited.
Schedule = "Commitment"
Some schedules are commitments that were given to a customer. The group is expected to believe "we can make this date"-and also believe that the customer needs it done by the given date. No evidence is given for either belief-nor is it asked. Feelings tend to run high on these projects, as some groups claim they are being true to the schedule while other groups are not. Computer problems can't be solved on a faith-determined schedule, and so what happens is mostly failure.
Schedule = "Motivation"
Some schedules are purely executive decisions. They are designed to be impossible in order to "motivate" people on a project that would "otherwise never be finished." Since software development people are often high-IQ types, they immediately see through the fake deadline. These projects slip, and slip-though they may eventually reach their destination. This pattern causes team members to take no deadlines seriously.
Schedule = "Wish"
Some schedules are based on when everybody wants the project to be done. They aren't realistic, but at least everybody is escaping from reality in the same boat. Development is typically optimistic about how long their work will take, but management sometimes negotiates it down from there. At this point it becomes known as an "aggressive schedule," and it becomes permissible to talk about it with a tinge of skepticism, thank heavens! These projects recklessly sail off into stormy weather. Some smaller projects sometimes blunder into port (though never "on schedule"), but in larger projects, the team goes down with the ship.
Schedule = "Charade"
There is a period of time in which the milestones aren't met, but the end-date doesn't change. This is a schedule that "can't slip." In point of fact, this schedule can slip, and does slip, sometimes more than once, but every slip is supposed to be a surprise. This schedule is a charade. It requires a mandated suspension of disbelief and a fair amount of dramatic talent, especially in meetings, so that deadline extensions will make you grateful instead of exasperated.
Paired Schedules = "Official" and "Real"
Some projects have two simultaneous meanings for "schedule," and people need to keep track of both. First there is an "official schedule" that management chooses to believe. These official schedules may have timelines and tasks that are tracked to the hour. But don't be fooled by level of detail: it's still a fantasy. The project actually has a growing list of deliverables that haven't been delivered, and no one wants to know the size of the backlog.
Then there is an underground "real schedule," which is a period of time that people in the trenches think the project will actually take. The people doing the real work know when an official schedule won't be met, but they still have to coordinate their work with the work of other groups. So the experienced people on the project begin to circulate guesstimates, to try to help each other. In my experience, the "real schedule" still turns out to be optimistic. But the existence of "real schedules" shows healthy signs of teamwork, though management isn't a part of it. And a realistic guess from the trenches is better than the Gantt chart mirage.
Schedule = "Schedule"
Your project can unload all the emotional baggage created by illusory schedules, and be guided by a real schedule: a rational plan that attempts to chart the tasks of the project, along with their milestones and dependencies. This schedule is a tool. It's not a mindgame to make people work faster, but a genuine attempt to predict when the project will