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

101–110 of 111 posts

Re: Why Are Projects Always Behind Schedule?

#101

Post by mianos »

mason55 wrote: post #90
mianos wrote: post #85

Earlier quoted context omitted.

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.

Sorry, my mistake. I was thinking the option on the back of it. Yes, you are correct, for simple stocks, if the stock price rises forever you theoretically have the possibility of infinite losses. Practically I'd not use infinite, but that has busted many people.

Re: Why Are Projects Always Behind Schedule?

#102

Post by foz »

21echoes wrote: post #49
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…

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.

The problem with high estimates, if accepted by the stakeholders, is the risk of over-engineering. When given lots of time, development teams often will find ways to use that time which don't add to the value of the features being delivered: over-testing, making things "re-usable", a chance to try something new. And the project is late anyway.

Maybe optimistic estimates are a motivating factor for teams. The desire to finish faster, to be more efficient than you were before, a commitment with a challenge.

In my experience, it takes a strong product owner and a mature development team to meet deadlines. Shipping on-time is always a game of tradeoffs. Accuracy in estimates is usually the result of doing things in a known, measurable way. And by keeping the stakeholders close, you can make critical decisions together to keep a project on track.

Re: Why Are Projects Always Behind Schedule?

#103

Post by RyJones »

jacques_chester wrote: post #34
LoSboccacc wrote: post #24

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…

Building construction is actually a good analogy. 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…

I worked building a bank once where a detail cost us a bunch of heartburn estimating and building. Having the architect stop by, look at it, and say "I had no idea if you guys could build that" was infuriating.

Re: Why Are Projects Always Behind Schedule?

#104

Post by Scarblac »

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.

Sure, but as long as there are projects where estimation is needed, estimation won't die.

Re: Why Are Projects Always Behind Schedule?

#105

Post by gutnor »

mistermann wrote: post #96
gutnor wrote: post #82

Earlier quoted context omitted.

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…

> An extreme case, is a client that took a package I developed 5 years after delivering the working version of it. You completely lost me there, what happened exactly?

A client wanted to run our application in windows at the latest, a week before I joined the 2 men project. 2 months (?) later we delivered a "patch" (the first version didn't even work at all) of the initial solution using the same unix scripts running in interix.

Seems like they were not in any hurry after all. Some 5 years later, they contacted my company again asking how to install it in their test environment. They were apparently not happy that after 5 years, the solution was still a bodge solution using interix rather than a proper port in windows. I don't know what happened from there, I had moved on to another project right after that delivery, could not remember anything and to be honest only painful memories could come back from that shitty codebase. ( the company was making something like 5K a year gross from that application )

Re: Why Are Projects Always Behind Schedule?

#107

Post by hectormalot »

21echoes wrote: post #49
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…

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.

And account for correlations. It would be interesting to see if multi step projects with overruns tend to overrun in more steps then expected. I could imagine a stakeholder management heavy project to be more likely to overrun in every step. In other words, even by summing the distributions you might be underestimating the expected time of completion.

Re: Why Are Projects Always Behind Schedule?

#109

Post by coldcode »

pixl97 wrote: post #76
coldcode wrote: post #63

Earlier quoted context omitted.

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.

My parent company is one that will never go out of business unless the US tanks completely.

Re: Why Are Projects Always Behind Schedule?

#110

Post by calinet6 »

ThomPete wrote: post #80
calinet6 wrote: post #53

Earlier quoted context omitted.

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.

The idea that each project we tackle is unique and a special snowflake is an illusion.

In reality, most of the factors that influence the outcomes are exactly the same. Same team, same knowledge, same approaches, same psychological biases, same methods, same politics, and so much more.

Those are the things that influence timelines most; not the project itself.

Post reply on HN