6 ms·

Software development: dealing with awful estimates

8 points by Unosolo 16y ago

cromulent 16y ago
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".
- gte910h 16y ago
  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.
  - cromulent 16y ago
    They are a good customer, with a bad process that was given to them by consultants.
    - gte910h 16y ago
      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.
      - cromulent 16y ago
        > 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.
- matei 16y ago
  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.
  - cromulent 16y ago
    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".
    - gte910h 16y ago
      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".
      - cromulent 16y ago
        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.
gte910h 16y ago
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.
- rix0r 16y ago
  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.
StudyAnimal 16y ago
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.

8 points by Unosolo 16y ago

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".

gte910h 16y ago
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.
- cromulent 16y ago
  They are a good customer, with a bad process that was given to them by consultants.
  - gte910h 16y ago
    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.
    - cromulent 16y ago
      > 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.
matei 16y ago
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.
- cromulent 16y ago
  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".
  - gte910h 16y ago
    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".
    - cromulent 16y ago
      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.

gte910h 16y ago

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.

rix0r 16y ago
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.

StudyAnimal 16y ago

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.