Brutal Truths About Software Project Scheduling Estimates

The scheduling of software projects has confounded managers for decades. The only effective antidote to poor scheduling is experience, something our industry tends not to value.

I've always wanted to post a well-informed treatise on scheduling estimates but I was concerned that it would lapse into a rant. I suppose it's impossible to tackle this subject dispassionately but I'll limit this to bullet point observations and try not to make it a big think piece.

• The brutal truths about scheduling software project estimates are both brutal and truths. Don't fight them.
• Experience and honesty are the only protection you have against bad scheduling estimates. It is okay to be inexperienced. If you are, get guidance from someone with more experience when it comes to scheduling projects. Accept that intelligence and grit have nothing to do with effective scheduling estimates. It doesn't matter if you are the smartest person in the room - estimating has nothing to do with intelligence.
• If you have not done something before, you do not know how long it will take to do. Most projects have novel elements, which are unknowable to you. A car manufacturer may produce a hundred identical vehicles a day - they can tell you how long it takes to produce one. A home builder may complete ten identical structures a month - they can tell you how long it takes to erect one. When you have produced something three times, you will know how long it takes. Until then, you don't.
• There is nothing wrong with saying you don't know how long it will take to do something you've never done before. A manager who accepts an estimate for a project full of unknowns is as inept as the one offering the estimate.
• When a manager asks a report for an estimate, the report should not focus on trying to make the manager happy. There is nothing happy about scheduling software. At best, you should get a disgusted look and a somber nod. If the report is very lucky, the manager will tell them their estimate is low. This has happened exactly once in my entire career.
• The ambition of a project is inversely proportional to the expected precision of the project schedule.
• When you believe the project is "code complete" or "feature complete", the project is only halfway done. Don't fall for the head-fake of thinking the last development contribution means the project is nearly over.
• If you were to survey software companies and ask them if they were in a "crunch mode", my guess is over eighty percent would say yes. "Crunch mode" is a meaningless term used by weak managers as a crutch.
• Software projects are not "late", only manager comprehension is late.
• Measuring progress is more important than measuring deadlines.
• "Therapy" sessions are an eventuality when inexperienced managers try to cope with "late" projects. These meetings always have a similar progression. Everyone comes together and feels bad. No one smiles. There are apologies, excuses and shrugs. Yet nothing changes except for the morale of the team. Developers should not be wasting their time guiding inexperienced managers through the seven stages of scheduling grief. The correct way to hold these types of meetings is to determine which person in the room is truly astonished by the state of the project and assign them a reading of Mythical Man Month.

last update 2019-02-17