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

71–80 of 111 posts

Re: Why Are Projects Always Behind Schedule?

#71

Post by skeolawn »

yason wrote: post #14

When I was doing more project work I outright refused to give estimates, explaining that I could come up with a random figure that's so low they won't believe it or so high they won't like it, and in any case the figure would have nothing to do with when the project would be complete. Instead I offered broad time ranges that would narrow down to more accurate ones as work progressed. The managers who had to report th…

"instead I offered broad time ranges that would narrow down to more accurate ones as work progressed"

Well, that is an estimate according to managers who actually understand what they're doing ;-)

Re: Why Are Projects Always Behind Schedule?

#72

Post by zzalpha »

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…

So it's like shorting a stock... Limited upside, unlimited downside.

Interesting observation, I'd never thought of project planning that way.

Re: Why Are Projects Always Behind Schedule?

#73

Post by jodrellblank »

analog31 wrote: post #25
elorant wrote: post #8

Cheap, fast, good. You can only have two.

In practice, you can't even have two. That's because the cheap-fast-good rule assumes that you're already close to an optimum, whereas in practice, things are expensive, slow, and bad, for reasons that are unrelated to one another. As a result, a team will lower the requirements, or agree to spend more money, and discover that the project still takes just as long. I've seen this happen over and over.

In the words of DevOps_Borat: Software project 1) On time 2) On budget 3) With quality. You can not able pick any.

- https://twitter.com/devops_borat/status/289782091250532352?l...

Re: Why Are Projects Always Behind Schedule?

#74

Post by 21echoes »

gkop wrote: post #58
21echoes wrote: post #49

Earlier quoted context omitted.

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.

There's more to it than your easy fix, the article alludes to it but does a poor job of covering it: if you know the distributions of the intermediate steps, but you only sum the means of the steps, then you are throwing away data that could help you calculate a better estimate.

Oh of course! More data (sanely applied) is almost always going to result in more accuracy. I just found it very strange that the core assumption of the article -- that the default setting is to add median times of subtasks -- was never questioned. Why was that the chosen method to begin with? Most time estimating tools (Pivotal Tracker, etc.) work with averages, not medians, for precisely this reason.

Re: Why Are Projects Always Behind Schedule?

#75

Post by SixSigma »

jacques_chester wrote: post #67
SixSigma wrote: post #64

Earlier quoted context omitted.

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.

Oh yes, you did say that, sorry. I only responded to your first point and then remembered the second myself.

PERT is taught as a time based planning tool but it also has a earned value element. The tools for that have moved on too.

https://en.wikipedia.org/wiki/Earned_value_management

I suppose the unpacking effect does make more sense though, over CPA.

"How long will it take?"

"6-8 weeks"

So what do you put in CPA - 6, 7, 8 ? PERT says 7.

Re: Why Are Projects Always Behind Schedule?

#76

Post by pixl97 »

coldcode wrote: post #63
Scarblac wrote: post #62

Earlier quoted context omitted.

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.

> Canceling or changing my project cannot be done.

Oh, yes it can. It's called your parent company going out of business.

Re: Why Are Projects Always Behind Schedule?

#77

Post by jwatte »

Another common source is delay and procrastination up front.

First, a dev estimate is given of six months.

Plan is made to ship in six months.

Then, stakeholders bicker for four months on whether, how, and when to actually do it.

Then, dev gets started, being told that they already spent four months, so they should be done in two, according to the "initial estimate."

Was it "debugging the development process" that called this out? Or "code complete" perhaps?

Re: Why Are Projects Always Behind Schedule?

#78

Post by quietplatypus »

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 it's a long tailed distribution knowing the expected value isn't going to tell you anything you can count on

Re: Why Are Projects Always Behind Schedule?

#80

Post by ThomPete »

calinet6 wrote: post #53
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…

That's a good point, but it has two issues you should consider. First, the industrial world also had significant issues with project definition and understanding. The problems were not already solved, and the process, inputs, outputs and the whole system was constantly changing. Every project was already about problem solving and scoping. So there's a bit of rose-colored glasses toward the past here. Second, the idea…

It is my experience that there is absolutely not predictability in learning from the past unless you are doing exactly the same. For something like an agency that are hired to come up with something else thats normally not an option.
Post reply on HN