Impossible and difficult

I've been thinking a lot about impossible schedules. I'm talking about the project schedules that no matter how you organize the project, it's not possible for this group of people to cram that set of features into this much time. At least, the developers don't think so.

If people are up against impossible schedules, in my experience, they stop thinking. They cannot imagine a new technique or tool will help them. So even if their configuration management is in the pits, they will limp along instead of acquiring and using a new tool. And a change in technique is even worse. People who can't imagine any way to success resist any ideas like iterations, implementing by feature, test-driven development, or even peer review of code. (This happens to testers too, it's just that my examples here are for development.)

People aren't stupid. When they're up against an impossible schedule, they will hunker down and do what they can, so they won't be fired. That's all.

But with merely a difficult schedule, people will consider alternatives. They know that with alternatives they could make this into a not-so-difficult schedule, and they may be willing to take the chance on a different technique or tool -- or even both.

So if you have an impossible schedule, don't try to change anything. Or, change enough of the schedule that people have a little breathing room to try something new. But don't expect people to try something new in an impossible schedule. The personal risk is too high. It's much safer not to take a risk and miss the schedule than it is to take a risk with something new and miss the schedule.

So if you want your project staff to think, make a difficult schedule, and then set a personal challenge: "How can we make this schedule more reasonable?" In my experience, this is the kind of challenge many of us thrive on. But don't set a stretch goal. That discourages thinking and will encourage people to throw out any good ideas that have not yet become good habits.