31–40 of 111 posts
Earlier quoted context omitted.
Hofstadter's Law is my favorite law of all time: "It always takes longer than you expect, even when you take into account Hofstadter's Law." — Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid
This always bugged me cause it means every project estimate should be infinite in length.
Expected time = (best + 4 * likely + worst) / 6
There is actually a nugget of thought in the article beyond the explanations you always hear (and which make up all the comments in this thread as I'm writing this): Even if you base your project schedules on accurate estimates of the median time required for each step, you will still be behind schedule for most projects. The reason is actually quite simple: when things go well, they can only go so well, but when the…
There are unknown unknown in projects, people won't pay you for a full analysis and there is always the option that one library you rely on has a nasty bug you cannot foresee. One doesn't have to go very far and look for psychological issues when a major source of indeterminism comes from directly the imperfect tooling itself we use. Sometimes software is compared to construction, except you don't get to start with a…
For stuff that's been built a thousand times, you can state with a fair amount of confidence how long a project should take and how much it should cost. You can obtain financing and insurance because the dataset is large enough.
For stuff that's unusual or bespoke -- the kind of thing that will appear in an architecture magazine or in a newspaper investigatory report -- then estimates are very likely to be wildly optimistic.
So it's the same, insofar as the further you stray into research, the less certainty there is. The bigger the bet, the fewer such things have been built, the bigger the risk will be that things go awry.
I have a book in my collection -- Industrial Megaprojects -- which makes fascinating reading for enumerating all the ways that chemical process plants, giant mines, gas pipelines, gigantic factories etc can blast through the budgets and schedules.
My personal favourite: a chemical plant built relying on an adjacent river for cooling. To save costs, only one water temperature sample was taken during planning ... in winter. Three billion dollars later, the owners found that the plant was inoperable for about half the year because the river water was too warm.
Earlier quoted context omitted.
This always bugged me cause it means every project estimate should be infinite in length.
That's why PERT has problems. Estimate times for "best case", "likely case" and "worst case" Expected time = (best + 4 * likely + worst) / 6
I went hunting for the origins of that formula a few years ago. I couldn't find the original source, and certainly none of the sources I found had a justification for it.
Someone who works at RAND could probably pull the original internal work and tell us. But I suspect it was chosen for ease of calculation.
While it's been criticised for being normal-esque instead of pessimistically skewed, it still outperforms single-point estimations. I think it's because of the "unpacking effect" that a full PERT estimate causes you to undergo.
There's a literature of people tinkering with the formula, but I don't think it's anywhere near as important as the unpacking effect is.
This is a great writeup on a simple bit of math that violates common sense expectations. Consider you need to go on a 100 mile trip and want to average 100 miles per hour. Conditions are bad and for the first 50 miles you only average 50 miles per hour. How fast do you need to go to average 100 mph for the whole trip? Clearly 150 mph, right? Except of course you are too late and would have to go infinitely fast as yo…
m = 'most likely' time
o = 'optimistic' time
p = 'pessimistic' time
e = ∑(oi + 4mi + pi)/6
[1] https://en.wikipedia.org/wiki/Program_evaluation_and_review_...
The program (or project) evaluation and review technique, commonly abbreviated PERT, is a statistical tool, used in project management, which was designed to analyze and represent the tasks involved in completing a given project. First developed by the United States Navy in the 1950s, it is commonly used in conjunction with the critical path method (CPM).
For every step in a project, there’s about a 50% chance of completion under or on the median step completion time. And there’s about a 50% chance of not. If a project is composed of 2 steps, the probability that both steps are at or under their median times is 50% * 50%, or 25%. For a 3 step project, it’s 50% * 50% * 50%, or 12.5% and so on. If a project has 6 steps, the chances of some of those steps going over its median is greater than 98%.
Hofstadter's law + Parkinson's Law + Murphy's Law = Delay
Hofstadter's Law is my favorite law of all time: "It always takes longer than you expect, even when you take into account Hofstadter's Law." — Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid
The fact that planning estimates represent a probability distribution is well known and there is an established process (PERT)[1] for estimating the expected time of a set of estimates - essentially instead of asking for a single 'most likely' estimate you should as well explicitly walk through some of the risks around this and the ask for an 'optimistic' estimate (which is frequently very similar to the initial esti…
If anyone is interested in trying out the beta version, drop me an email at andre /at/ thebroadbaycompany.com