📈Why software projects take longer than you think

The ratio of actual time to estimated time is not spread evenly around one. It is skewed, with a long right-hand tail: a task can come in a little early, and it can come in several times late. So the median overrun is small, the average is much larger, and when you add tasks together the total is dominated by the few that blew up. A project plan made of honest typical-case estimates will therefore be late, and the more uncertain its pieces, the later.

• Found on Friday 21 February, nine days after I stood in a room and recommended 📜 Slip the launch from 18 February to 11 March. The essay I needed, a fortnight too late to need it.
• Finished on Saturday morning at Lantern Coffee and wrote both notes before climbing. It was the first Saturday in three weeks that felt like one.
• An engineer with a dataset, not a pundit with an opinion. He plots how long tasks really took against how long people said they would.
• The finding that undid me: our estimates are quite good at the typical case. Half the tasks finish around or under the estimate. The damage is all in the other half, where a task can run over by any amount.
• I had thought I was bad at estimating. I am fine at the median and I was promising the median to Sales as if it were a ceiling.
• Nothing quoted from it. The line I keep beside it is Bennett's 💬 The chief beauty about the constant: nobody can spend time in advance, and an estimate is a promise about hours that have not been issued yet.
• The person who would have recognised the chart at once is 🏛️ W. Edwards Deming. It is an essay about variation, and I had been managing an average.