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

61–70 of 111 posts

Re: Why Are Projects Always Behind Schedule?

#61

Post by noiv »

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…

> they can only go so well, but when they go bad, they can go really bad.

Well, they can, but usually the acceptable explanation for a project going really well is it actually was less work than estimated and the consequence is fewer resources next time. So, there is virtually no motivation left to drive a project into that area.

Re: Why Are Projects Always Behind Schedule?

#62

Post by Scarblac »

ThomPete wrote: post #41

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…

Time estimation will always be needed, just to decide whether something is worth doing.

Re: Why Are Projects Always Behind Schedule?

#63

Post by coldcode »

Scarblac wrote: post #62
ThomPete wrote: post #41

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…

Time estimation will always be needed, just to decide whether something is worth doing.

Not always true. My project has to be done since it will involve a whole host of hardware installations, marketing and other large expenditures. Canceling or changing my project cannot be done. Thus estimating to decide if it's worth doing is unnecessary. In this case it has to be finished regardless of estimates.

Re: Why Are Projects Always Behind Schedule?

#64

Post by SixSigma »

jacques_chester wrote: post #44
SixSigma wrote: post #43

Earlier quoted context omitted.

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.

And it also assumes that the optimal is just as likely as the pessimistic. As anyone who has ever planned anything knows, more things can conspire to introduce delay than work out just right enough to make it take less than you excepted.

Re: Why Are Projects Always Behind Schedule?

#65

Post by Scarblac »

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…

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.

Re: Why Are Projects Always Behind Schedule?

#66

Post by crdoconnor »

caseysoftware wrote: post #45
mikekchar wrote: post #23

Earlier quoted context omitted.

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 m…

You can also try to eliminate dependencies as well as track them.

This is partly why in software it's so critical to loosely couple software. If you're working on a big old ball of mud there are so many dependencies that even the smallest task ends up taking forever.

Fortunately SCRUM provides you with a block of time which you can use to decouple software independently of working on features or bugs, so this necessary work always gets done. Ha.

Re: Why Are Projects Always Behind Schedule?

#67

Post by jacques_chester »

SixSigma wrote: post #64
jacques_chester wrote: post #44

Earlier quoted context omitted.

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.

And it also assumes that the optimal is just as likely as the pessimistic. As anyone who has ever planned anything knows, more things can conspire to introduce delay than work out just right enough to make it take less than you excepted.

Right, and there's lots of literature jumping on that and trying to repair it. Yet the original formula outperforms single point estimates.

But as I said elsewhere in this thread, my suspicion is that the unpacking effect dominates the "improvement" that's observed and that the particular formula is largely secondary.

Re: Why Are Projects Always Behind Schedule?

#69

Post by _paulc »

netghost wrote: post #52
_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…

The typical PERT three point distribution is better than assuming the mean, but does have a few drawbacks when modeling joint probable outcomes. I honestly can't remember if it over our under represents the optimistic or pessimistic result. The other quirk is that it breaks down when you map from effort or work to duration, the actual time something takes when you factor in availability, interruptions, communication…

I think that the real value is in forcing people to think about optimistic vs worst case estimates - in my experience the initial estimate is almost always actually the optimistic number and when they start to think about risks people tend to become much more conservative.

Re: Why Are Projects Always Behind Schedule?

#70

Post by _paulc »

danieltillett wrote: post #54
_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…

Is there any reason to use a triangular distribution these days? I can see it made sense in the 1950s, but now it should be trivial to use a more accurate distribution.

Probably not, but I would guess that the difference is well within the error margin of the original estimates.
Post reply on HN