Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Are Projects Always Behind Schedule?

priceonomics.com

Post reply on HN
Print view View original

81–90 of 111 posts

Re: Why Are Projects Always Behind Schedule?

#81

Post by vitd »

_paulc wrote: post #37

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…

I'm in an organization that uses this method, and I don't think it helps. I believe our "optimistic" metric is supposed to be something like "We have a 10% chance of hitting this goal," our "realistic" metric is supposed to be something like "We have a 50% chance of hitting this goal" and our pessimistic is "We have a 90% chance of hitting it". (Or something like that. I don't remember the exact values off the top of my head.) But what happens is the engineers estimate what they think it will take, claim that's the "realistic" option, then add or subtract some percentage from that for the pessimistic and optimistic values. Nobody really understands how (or if) it's supposed to work, so the estimates are still bad.

Re: Why Are Projects Always Behind Schedule?

#82

Post by gutnor »

Scarblac wrote: post #65
astazangasta wrote: post #48

Earlier quoted context omitted.

According to this reasoning you should set targets based on expected time, not "median" time. You're saying the tail of "completion time" is long, and so the median is a poor estimator for expected time. But if you actually knew the distribution of times for task completion (which is implied if you know the 'median time'), you could simply use the expected value of this distribution and your projects would then tend…

Another reason is a kind of selection bias: an organisation wants something built, gets offers from various software companies, and picks the cheapest. That is, if you are doing the project, your company's initial estimate was the one that had the highest chance of being too low.

That's not only that, the field is full of bullshit. Advertising feature as available when they have not even been discussed seriously is the usual in the companies I have worked for the last 10 years. Our website and sales all go advertising "We support X. We are ready for regulation Y", while we are actually waiting for a paying customer to buy it to even look into it.

And that's all companies. You can't really be honest as all your competitors are similarly bullshitting. ( I used to be upset about that thinking I was always working for the black sheep, then over the years, you always end up working with your competitor one way or another and you find out it is the same everywhere )

There is also the deadline game. The client will push for earlier and earlier release date. The provider will accept because the provider knows that the client will not be able to test the product. I used to be upset to deliver code that would not even compile. Then over the years, we have had client not ready to test for several years. An extreme case, is a client that took a package I developed 5 years after delivering the working version of it.

That's the biggest problem I have had with Agile. Very often companies are not ready to support the lack of bullshit even internally - no more schrodinger status, no creative budget allocation - developer appear to be slower and cost more.

Re: Why Are Projects Always Behind Schedule?

#83

Post by ldd »

jacques_chester wrote: post #35
SixSigma wrote: post #31

Earlier quoted context omitted.

That's why PERT has problems. Estimate times for "best case", "likely case" and "worst case" Expected time = (best + 4 * likely + worst) / 6

For those reading at home, the meaning is that the "most likely" is multiplied by 4, giving a triangular distribution that (very very) roughly approximates a normal distribution. 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 wo…

It reminds me of Simpson's Rule:

https://en.wikipedia.org/wiki/Simpson%27s_rule

Re: Why Are Projects Always Behind Schedule?

#84

Post by tdaltonc »

astazangasta wrote: post #48
nhaehnle wrote: post #9

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…

According to this reasoning you should set targets based on expected time, not "median" time. You're saying the tail of "completion time" is long, and so the median is a poor estimator for expected time. But if you actually knew the distribution of times for task completion (which is implied if you know the 'median time'), you could simply use the expected value of this distribution and your projects would then tend…

If you're working with censored data, it's possible to know the median but not the mean of your data.

https://en.wikipedia.org/wiki/Censoring_(statistics)

Re: Why Are Projects Always Behind Schedule?

#85

Post by mianos »

mason55 wrote: post #19
nhaehnle wrote: post #9

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…

Projects timelines are like naked shorts in the stock market. You have a capped upside but unlimited downside - things can never be done faster than instantly but they can take literally forever (i.e. just never get finished).

You are being a bit loose with the term 'unlimited' but I guess that's marketing for you. You stand to lose the difference between your strike and zero. Last time I looked that's not 'unlimited'.

Re: Why Are Projects Always Behind Schedule?

#86

Post by tbrownaw »

mianos wrote: post #85
mason55 wrote: post #19

Earlier quoted context omitted.

Projects timelines are like naked shorts in the stock market. You have a capped upside but unlimited downside - things can never be done faster than instantly but they can take literally forever (i.e. just never get finished).

You are being a bit loose with the term 'unlimited' but I guess that's marketing for you. You stand to lose the difference between your strike and zero. Last time I looked that's not 'unlimited'.

I thought 'strike' was an options thing rather than a short thing?

Re: Why Are Projects Always Behind Schedule?

#87

Post by connect2hcb »

One reason is perhaps to do with what really happens when someone is trying to win a project. Given that winning involves beating others in the fray, all including the winner would end up making commitments which are higher than the capabilities and competencies available with them at that point in time. This initial gap creates risk right at the beginning and if it is not mitigated in time, would amplify to bigger proportions. This mismatch eventually results in projects running behind schedule which in turn becomes a self-feeding vicious cycle with short-cuts being taken to cover up. That then leads to a compounding effect on schedule slippage.

Re: Why Are Projects Always Behind Schedule?

#88

Post by dclowd9901 »

astazangasta wrote: post #48
nhaehnle wrote: post #9

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…

According to this reasoning you should set targets based on expected time, not "median" time. You're saying the tail of "completion time" is long, and so the median is a poor estimator for expected time. But if you actually knew the distribution of times for task completion (which is implied if you know the 'median time'), you could simply use the expected value of this distribution and your projects would then tend…

I think what he/she's saying is you can't predict how badly something can go (since it can go infinitely badly), you can only predict how well it can go (because it actually touches the finite minimum). Which passes the logical sniff test and is in fact the correct explanation. At least it has been for absolutely every project I've ever been on.

You could feasibly be on a project that could last until the heat death of the universe.

Re: Why Are Projects Always Behind Schedule?

#89

Post by jldugger »

zacharycohn wrote: post #38

This is such.an elegant way of explaining the problem: 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 st…

But some of those steps will go under the median as well. The problem is the distribution is not normal -- if the range of possible outcomes below the median n is [0,n], the range of possible outcomes above the median is far wider than [n,2n]. Going by the chart the article offered, I suspect a sort of mixture distribution: the better understood tasks have normal distributions, and the poorly understood ones have bullshit estimate distributions.

Re: Why Are Projects Always Behind Schedule?

#90

Post by mason55 »

mianos wrote: post #85
mason55 wrote: post #19

Earlier quoted context omitted.

Projects timelines are like naked shorts in the stock market. You have a capped upside but unlimited downside - things can never be done faster than instantly but they can take literally forever (i.e. just never get finished).

You are being a bit loose with the term 'unlimited' but I guess that's marketing for you. You stand to lose the difference between your strike and zero. Last time I looked that's not 'unlimited'.

I'm not really sure what you mean. If you naked short without covering with options then the price can pretty much go up forever and you cover the difference. I don't understand where zero comes into play.
Post reply on HN