Software development: dealing with awful estimates | Hacker News Reader

Software development: dealing with awful estimates

programmers.stackexchange.com

8 pointsUnosolo13 comments

I have a customer whose strictly-enforced process is:

  1. Estimate (based on one-sentence title of feature)
  2. Wait for approval
  3. Find out detailed requirements
  4. Design and document
  5. Implement and deploy

3,4, and 5 should be included in your original estimate.

If you try to do 3 first, you are not following the process. The process is touted as "best practice 2.0".

This sounds like the type of customer it is good to find other customers to replace them, then start giving very very large numbers for #1 equal to the pain this causes.

They are a good customer, with a bad process that was given to them by consultants.

By what measure of good customer? A customer who pays on time and has friendly employees but insists on a process which leads to repeated "failure" and bad blood can still be a bad customer.

Sorry you're the victim of consultants. I've replied in a different post to a more explicit project management scenario I've seen work in a past with this sort of "Too much for the timebox" issue.

> By what measure of good customer?

My measure - the only one that counts ;)

I'm used to working in adverse situations, and charge accordingly. Don't spend any time feeling sorry for me. Where there's muck there's brass.

Unfortunately, there are many situations in which you get 3 after the initial estimation, since 3 is a long process which usually can occur only after a deal was made with the client. And in most(every) case, the client wants to have a clear price before signing a deal. The price usually depends on the number of man hours required for the project, so the estimate has to come before step 3. It's a defective process, but difficult to correct.

Sure, but in our case we have an ongoing deal. What happens is that quality (think % of requirements met) varies to meet the estimate, and the customer loses. They are trying to control budget, but the granularity is wrong.

It's actually fairly easy to correct, but then it wouldn't be "best practice 2.0".

Sounds like this customer needs to work of a priority list. You get all the features you could implement, and stick them in a list with rough estimates of time (at like a small medium, large, very large type sizing). You then get the customer to reorder them. Then, work from the top down. You can likely predict a certainty line and a maybe line. Share these depending on customer "maturity".

The same "don't get all the features done" thing you were suffering before will happen with the client, however this time, they'll get the most important ones done, and they'll understand "oh hey, giving a bit more time will get X out the door".

And this can be done "outside the process" possibly slipping past the consultants dicta as just "helping you out to figure out what's most important to them".

Thanks, but we have a high level of awareness of what could be done better, and a high level of experience in doing it the right way. I'm not looking for ideas here, I was just trying to illustrate that bureaucracies can win quite a few rounds before you can wear them down with "I refuse to give an estimate until I do due diligence" approaches.

That's what iterative development is built for. Set the initial price as a small core object you can discern definitely needs to be made, then get the rest built as a follow on project from the customer after you've wowed them buy building the initial on time and to the specified parameters.

I do like that he puts forth the "don't agree to stupid" and "don't agree to hurry unduly" positions.

I disagree with him on "Normally, the way it works, is that your estimate is first scanned for odd looking or relatively large items. Hence be prepared to defend anything with “non-standard” name. Also split larger tasks so that all tasks have same order of magnitude, i.e. if most tasks take 2 days and one single task is 10 days be prepared to get drilled."

I believe generally you should actually communicate the hard parts of the project to people. You should actually communicate what about it is hard if you have any ability to do so, and you should state alternative risk management strategies you've turned down for what reasons if they ask about them.

Sure, but what I think he meant was: if one work item is very large, it should be broken down to make sure there's no work hiding in there that got overlooked.

This is one thing the agilists have gotten right.

Estimate the size of the problem in abstract units like story points, and do it in small chunks.

Reply on news.ycombinator.com