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

41–50 of 111 posts

Re: Why Are Projects Always Behind Schedule?

#41

Post by ThomPete »

Time estimations is an industrial way of thinking applied to a post-industrial world.

In the post industrial world time isn't the problem but rather project definition and scoping.

In the industrial world the problem was already solved (machine was built, market often established and output depended on a few factors that could be adjusted. Need more output add more of X)

In the post industrial world every project is about problem solving and scoping.

To put it into comparison.

If we apply post-industrial reality to an industrial world. It means that each time a product needed to be done, if not the factory, then the machines would have to be developed.

It will take many many years before time estimation will die, but it will happen.

Re: Why Are Projects Always Behind Schedule?

#42

Post by dilap »

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…

Yup. If you look at the factor your estimates are off, they'll follow a lognormal distribution.

   *
And it's natural, if you think about it, that any schedule which doesn't include slack between tasks will almost certainly run long. (Even assuming you've got a mean of 0 -- as many tasks go short as go long -- you're not going to get lucky enough that the tasks that go short do it 'just right' to make up for the tasks that go long.)

So maybe include some slack.

Still, maybe you want to know how often will your schedule run long. So do some measurements of historical data to find out how your task estimates work out in practice.

Plug those in and do a few simulations, and viola, you can get a precise number of how you're likely to do. Plus handy tool to evaluate schedule quality.

Re: Why Are Projects Always Behind Schedule?

#43

Post by SixSigma »

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…

No, there is no justification, they just picked that because it has finite limits. They say it's a Beta distribution.

PERT was invented by the US Navy but these days the DoD recommends not using it but just use normal Critical Path Analysis instead where you just estimate a single time - hard enough on it's on without having to do it three times.

Re: Why Are Projects Always Behind Schedule?

#44

Post by jacques_chester »

SixSigma wrote: post #43
jacques_chester wrote: post #35

Earlier quoted context omitted.

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…

No, there is no justification, they just picked that because it has finite limits. They say it's a Beta distribution. PERT was invented by the US Navy but these days the DoD recommends not using it but just use normal Critical Path Analysis instead where you just estimate a single time - hard enough on it's on without having to do it three times.

Right, 3-points are tedious to do by hand. That's why I began working on a tool. I figured if it's easy enough, people would actually do it.

Re: Why Are Projects Always Behind Schedule?

#45

Post by caseysoftware »

mikekchar wrote: post #23
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…

This is very true. The best way I have found to combat it is by splitting up the tasks into many smaller pieces. If you have a task that is scheduled to take a month, then it can easily go out to 10 months in the worst case. If you have a task that is scheduled to take a day, it can easily go out to 10 days in the worst case. This allows you to make corrections to your schedule. There are 2 other important issues. Fi…

There's another hidden aspect: Be aware of dependencies.

When you have a series of dependencies (A -> B -> C) stacked against each other, once A is late, B and C are almost guaranteed to be late. If B is late too, C suffers even more and has little chance of being on time.

If you can lay out the tasks so that dependencies have slack between them so that lateness can be absorbed without shifting later tasks, you are more likely chance to hit deadlines and potentially complete the project on time. Or in more formal terms, track the Critical Path.

In practical terms, I would see this all the time commuting home in DC. I walked to the train to the bus to home. If I timed it perfectly, my commute was ~25 minutes. But if I couldn't cross the street in time, I'd catch a later train which made for a later bus. Or a slightly later train would be a much later bus. When those variances stacked up, it could take an hour.

Re: Why Are Projects Always Behind Schedule?

#46

Post by crdoconnor »

mikekchar wrote: post #23
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…

This is very true. The best way I have found to combat it is by splitting up the tasks into many smaller pieces. If you have a task that is scheduled to take a month, then it can easily go out to 10 months in the worst case. If you have a task that is scheduled to take a day, it can easily go out to 10 days in the worst case. This allows you to make corrections to your schedule. There are 2 other important issues. Fi…

There is some stuff that can easily take almost no time or can end up taking months. Two items that are commonly like this on software projects are fixing bugs (that can either turn out to be really, really hard or not bugs at all) or upgrading package dependencies (can require no changes whatsoever or can require a significant rearchitecture).

I think scheduling these issues would benefit more from splitting up risk and estimated duration and estimating both separately. Perhaps by drawing a mini probability distribution for each task.

Breaking down the task only helps if, in some way, analysing the constituent pieces actually helps you better estimate the risk or brings unconsidered requirements to light. Sometimes it doesn't. If you do too much of it it can also end up being a contributing factor to the delays (analysing every last detail).

Re: Why Are Projects Always Behind Schedule?

#47

Post by ape4 »

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…

I'll take me 2 weeks to use this API to make this application. If I work diligently it'll be done on time. But....oh no, the API can't do everything I need. Now its going to take 6 months.

Re: Why Are Projects Always Behind Schedule?

#48

Post by astazangasta »

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 to complete on time.

I don't think this is the correct explanation. I think it's far more likely that (1) people don't know the true distribution of task times, so estimates are just crap guesses based on hubris, what managers want to hear, etc., and (2) scope creep.

Re: Why Are Projects Always Behind Schedule?

#49

Post by 21echoes »

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…

Exactly. All this article is really saying is "most of the time, adding together median expected times underestimates the sum of mean expected times". Well then, easy fix: add together the mean expected times off the bat.

Re: Why Are Projects Always Behind Schedule?

#50

Post by netghost »

If you want a tool that goes beyond assuming the mean, take a look at LiquidPlanner. It can model complex plans, and is based on ranged estimates that let you capture uncertainty in ways that most other told can't.

Full disclaimer, I wrote a large chunk of the scheduling engine, so if you're curious about it, just shout.

Heads up though, my son was just born, so it might take me a while to respond ;)

Post reply on HN