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 be done. A team with a real schedule gets to list for itself everything they need to get done, and track the progress of each process.

An honest, real schedule won't be gospel, and will still slip. But your end-date will be based on real work estimates. Incremental tracking lets you make adjustments as they happen, so you're not startled by a slip at the end. Accurate scheduling may not be possible in this relatively young, unpredictable industry, but exercise improves scheduling muscles just like any other kind. And the act of scheduling connects management to the work as nothing else can, except doing it.

A real schedule is hard to predict, and puts a focus on accuracy that some of us don't want to see ahead of time. In our high-stress community, sometimes we expect rewards for busyness and speed, not for accomplishment and quality. People want to believe that longer hours mean more work gets done, whether this is true or not. Managers want to believe that a pushed project finishes faster, whether this is true or not. Studies have cast doubt on both these notions, but the notions live. We're not quite ready yet to give them up.

High-tech projects are criticized for being "slow"-they're never criticized for being unpredictable. Yet aren't accurate predictions what business needs most? When there is no realistic schedule, people in the trenches conspire to invent one. They have no other choice because they need to do so to plan their work. The actual users want to know what the team in the trenches knows. Have you seen any of these dubious schedules being foisted upon your project team. If so, please add a comment and share how you handled it, and what happened.