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

What do you mean ‘we need more time’? Project schedule estimation in software

blogs.dropbox.com

Post reply on HN
Print view View original

21–30 of 152 posts

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#21

Post by eterm »

13hours wrote: post #20
eterm wrote: post #17

Earlier quoted context omitted.

Absolutely this, clients need to know their costs upfront. Meanwhile, I've been on the other side, working with a shop that insisted they were agile, and so refused to give an upfront cost. That project ended up delivering a substandard project where key parts did not work well. Their answer was to tell us they would of course be happy to be paid for another 2 week sprint to fix those bugs... As a customer it wasn't…

I don't think working fixed price quote would have given you a different outcome though? The team produced bad quality product, fixed cost or agile won't change that. Selecting the team to build the product on price is often a bad idea, and that's all fixed cost gives you above agile (the ability to select on price).

A fixed cost makes it easier to turn and around not pay (in whole or part) if the product is really not up to the standard specified. It's harder to do that if the cost is not fixed but overrunning and the response is "well we just need more time".

Also fwiw, the team wasn't selected on price.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#22

Post by alien3d »

Ensorceled wrote: post #10
13hours wrote: post #7

Almost at the end : "Yes, all this sounds like a lot of work". Exactly. And it will most probably still turn out to be wrong, because you will forget to ask some questions, and there will be things that you simply cannot foresee that will influence the time. Turns out it's pointless to even try to do this. So why waste valuable time to do all this, if you know it's not the truth anyway? The answer is to accept that y…

It's better than this actually. If they want a release by Christmas I can with, high certainty, tell them: Features will be in: A, B, C Features likely to make it in: D, E Features unlikely to make it in: F, G Nope: H, I, J Hell No: K, L, ..., ZZZ The problem I've always found is that, no matter what, you are going to be arguing with sales and management about E, F and L instead of them just working with A, B, and C.

because it treat as creative not engineering.In reality A can be expand to A1, A2, A3.The most issue would be, client paid for A future but not A1, A2, A3

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#23

Post by LoSboccacc »

Ensorceled wrote: post #10
13hours wrote: post #7

Almost at the end : "Yes, all this sounds like a lot of work". Exactly. And it will most probably still turn out to be wrong, because you will forget to ask some questions, and there will be things that you simply cannot foresee that will influence the time. Turns out it's pointless to even try to do this. So why waste valuable time to do all this, if you know it's not the truth anyway? The answer is to accept that y…

It's better than this actually. If they want a release by Christmas I can with, high certainty, tell them: Features will be in: A, B, C Features likely to make it in: D, E Features unlikely to make it in: F, G Nope: H, I, J Hell No: K, L, ..., ZZZ The problem I've always found is that, no matter what, you are going to be arguing with sales and management about E, F and L instead of them just working with A, B, and C.

I do the same, except they give me an updated priority list every month, and once the priority for the month are set they cannot be changed. Misc. fixes are done eating up the time from the low priority features.

It removes me and my team from the losing proposition of agreeing to get something done before any other thing, as nothing of value can come from that discussion. And anyone who tries gets immediately redirected to the wiki page for the next month feature list, which opens one week before the iteration starts, by which time we know which feature will be complete and which will get back in queue.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#24

Post by marcus_holmes »

eterm wrote: post #21
13hours wrote: post #20

Earlier quoted context omitted.

I don't think working fixed price quote would have given you a different outcome though? The team produced bad quality product, fixed cost or agile won't change that. Selecting the team to build the product on price is often a bad idea, and that's all fixed cost gives you above agile (the ability to select on price).

A fixed cost makes it easier to turn and around not pay (in whole or part) if the product is really not up to the standard specified. It's harder to do that if the cost is not fixed but overrunning and the response is "well we just need more time". Also fwiw, the team wasn't selected on price.

In my experience it's easier and less risky doing it the agile way. You give them a 2-week sprint target. If they fail to hit that, then:

a. You don't pay them. b. They're probably going to miss every other target.

If you paid the agile shop for everything they did no matter how crap, and withheld payment from the waterfall shop because quality control, then that's got nothing to do with agile vs waterfall, it's got to do with your QC.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#25

Post by LoSboccacc »

Theodores wrote: post #8

The thing that annoys me most about project estimation is when the micro-managing types don't let you even look at the problem space first, an instant answer is expected. Of course the figure plucked out the air could be 'x days' with 'x' being greater than the time one expects internally so backside is covered, yet that is not really a true answer. At the moment I am putting together a 'simple' feature on a website,…

> don't let you even look at the problem space first

this is the core of the issue. when one has the time to break down all unknowns and discover them, estimate are quite spot on. but who want to pay for the estimate?

so we are left trying to guess what time a particular unknown is going to take to solve.

the good metaphor here is asking how much time it will take to solve a puzzle magazine, from cover to cover by looking at the title.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#26

Post by GFischer »

Theodores wrote: post #8

The thing that annoys me most about project estimation is when the micro-managing types don't let you even look at the problem space first, an instant answer is expected. Of course the figure plucked out the air could be 'x days' with 'x' being greater than the time one expects internally so backside is covered, yet that is not really a true answer. At the moment I am putting together a 'simple' feature on a website,…

Something I took from several articles is, most managers don't really need an estimate - what they need is a commitment, and/or a budget (and the estimate is an input to generate said commitment or budget).

https://www.mountaingoatsoftware.com/blog/separate-estimatin...

https://hbr.org/2014/12/your-agile-project-needs-a-budget-no...

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#27

Post by kbouck »

Regardless of project/planning methodology, having a ever-growing checklist of less-obvious estimation items is a simple way to avoid forgetting to consider them. The book "Software Estimation: Demystifying the Black Art" [1] by Steve McConnell contains a number of these.

Some examples:

  - Team or company meetings
  - Team member sick days, holidays, vacations
  - Bugs in third party software
  - Maintenance of previous systems
  - Maintenance of build automation
  - Demos
  - Interviews
  - ...
... or your own list of whatever other items you have historically forgotten, or tend to forget when estimating.

In the painting example, the moving of the furniture was something I overlooked, despite having made the effort to carefully think of all tasks. A estimation checklist built up from previous painting projects could have triggered me to consider this task.

[1] http://www.amazon.com/Software-Estimation-Demystifying-Devel...

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#28

Post by bluesign »

bliti wrote: post #6
bluesign wrote: post #2

I think also one of the biggest mistakes is making over estimates, or playing too safe. Especially when working with big teams and multiple projects (with a lot of dependencies).

How do you get the right estimates then? Mind sharing your techniques?

I was on the developer side, whose estimates are usually doubled by PMs. (or if we go by the story theme, they always assumed 'primer' may needed on every paint job) Then we had a lot of scheduling problems, and low effiency ( you finish painting the room, but people who will gonna move furniture still not available)

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#29

Post by dreamfactory2 »

melted wrote: post #4
bluesign wrote: post #2

I think also one of the biggest mistakes is making over estimates, or playing too safe. Especially when working with big teams and multiple projects (with a lot of dependencies).

Underpromise and overdeliver — that's the secret to professional success.

and a rookie mistake in sales

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#30

Post by dreamfactory2 »

article assumes specs are known. they might be for some kind of brochureware but for any serious work they never are, and in business reqs change day to day. 60% of software features are never used - so that's 60% overspend right there. there's no reason not to do fixed cost agile (personally wouldn't do it any other way). trying to fix scope otoh is just bad business from the get go - a) you might have target outcomes but you don't know exactly what you're going to need to get there b) useful software tends to be ongoing in terms of reqs
Post reply on HN