During my career in software development, I have encountered three particularly strange project schedules. In general, managers schedule work on a project to determine what it will cost and how long it will take to do it, and then they track actual progress to see whether the project is on schedule. This is actually an exercise in futility, as it is impossible to plan how long an interesting software project will take (Here's a proof of that by J. P. Lewis). But tracking actual progress does help us to know how we're doing, and sometimes even how good the developers are. When actual progress is much less than planned progress, we know we've got to do something.
1. I was particularly struck by one director who clearly kept no schedules at all. “Art,” I said, “Why don't you keep schedules for all your projects?”
If I knew how far behind I was,” Art said, “I wouldn't be able to sleep nights.”
2. Another director I worked for kept a beautiful hand-drawn schedule (he had once been a draftsman) locked in his desk, and it was rarely shown to someone in time of great need. (I glimpsed it once.) His staff knew this was ridiculous; you can have some confidence in a schedule if your whole team likes it, but if you're afraid to show the schedule to the people who are doing the work, it's probably imbecilic. I don't know what the schedule predicted, but we made painfully slow progress on this project.
3. Another group I worked with had only one copy of their project schedule. It was three feet high and forty feet long, and was printed once a month on a special printer after it was updated. Everyone was welcome to examine this schedule (it was pinned to three walls in a large room), but hardly anyone was able to grok it. This project eventually went up in flames and was canceled.