3 ms·

Have you ever tried to sell something to management with a 25% confidence level with an estimate that is at least 2x (4-8 weeks). You've just basically said you

Have you ever tried to sell something to management with a 25% confidence level with an estimate that is at least 2x (4-8 weeks). You've just basically said your estimate is anywhere from a week to half a year, which basically means you have no estimate ;) In terms of never having done it before, this is true of most software projects. If you're building the same house from the same plans then this is the same as say installing a Wordpress blog, easy to estimate. But if you were to ask how long it would take to build Wordpress from scratch, even having a Wordpress sample app, it would be very hard. Not only that but there are a lot of assumptions. Is it for a handful of visitors or are we talking a million visitor blog? Ignoring that, let's go back to the pharma example. How long do you estimate developing a new drug will take? It's not the first drug your company has developed. Anything beyond a week is hard to estimate. Back to your estimate of 25% within 4-8 weeks, this would never be accepted because it could mean anything. The worse part, I an tell you right now, even if new functionality or changes are added, you will be elf to 4-8 weeks, the 25% will be ignored. And in most cases management will hold you to 4 weeks because this is what was sold to their bosses.

cpitman 10y ago
Actually, it means a lot. It tells us how much we understand the project's timeline. Many projects get estimated way to early in the process, and the true level of uncertainty at that point is massive. If the low confidence level means the estimate has an upper end that isn't feasible, there are things we can do to increase confidence. Proof of Concepts/Spikes are explicitly for the purpose of taken an unknown feature and getting a better understanding of their complexity, scope, and timeline. (http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/ http://www.construx.com/Thought_Leadership/Books/The_Cone_of...) So then the hard part is communicating to the business the current estimates and confidence level and that we can do some up front work to tighten down our estimate and the schedule. This is actually part of ACM's "Software Engineer Code of Ethics": "3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates." As for pharmaceuticals, I have no experience there. I doubt that they really just let scientists go off and do whatever they want with unlimited budgets, and just live with the results.
- FollowSteph3 10y ago
  So let me ask you a simple question, how much time do I have to give the initial estimate and how long do I get to increase confidence? Is it in the order or days, weeks, or months? I ask because a 25% confidence level on 4-8 weeks would most likely require some time to increase the confidence, more than you would be permitted. I agree with what you're saying and that's all great and awesome but in the real world it unfortunately doesn't work that way. In most cases you have a day to a week to come up with an estimate for a year long project. If you by great luck get a cognate to do a spike, you get maybe an extra day. Ok most cases actually you would've maybe gotten an hour to a day at best and there would be no spike, and if you did get a spike it would be maybe an hour. Again I agree with what you're saying but it just doesn't work this way for the vast majority of companies. Also is this real time or actual time? In other words does it include time for meetings, holidays, sick days, change in staff, etc.
  - HeyLaughingBoy 10y ago
    Not to argue with you Steph, but that indicates a management problem. If I ask one of my guys for an estimate, I expect that it will take them time. If I need a SWAG, I'll say that. If I need an accurate estimate, I'll tell them that and ask how long it will take. Most (competent)management understands that everything has a cost. The problem that I've seen repeatedly is that devs toss off a quick guess without thinking about it very much and then act surprised when they're held to it. That said, I believe that a week is plenty of time to estimate a year-long project. However, you need experience estimating. Look, I'm no genius at this but when asked to estimate a task, this is what my manager would normally get: Time to Research fuzzy task C Find libraries for X, Y, and Z Assume cost of $A for libraries. Make sure we have this in the budget to avoid delays Repository setup time Tool configuration time (if different) Feature A Feature B ... Integration Test time for x, y, z I'm on vacation for a week Bug fix I need to interact with Susie in Manufacturing around this date and she says she will be having a baby and out for 6 months. You need to find me a replacement contact. Incorporate feedback from Manufacturing. Historically this adds about 2 weeks to any project. Add up all the times and provide an estimate along with any confidence intervals around each line item. This is how I have done it in the past before we implemented more rigorous processes and never gotten complaints. It gives management plenty to data to work with and talking points for them to ask questions about.
HeyLaughingBoy 10y ago
But that is exactly how I normally respond to estimate requests. "I have 70% confidence it will take between X and Y hours." That's a huge difference from saying "I have no fucking clue." If I say I think something can be done in 6 weeks and I'm 70% sure, Management now can weigh the risk that I'm wrong against the benefit. Most software projects in a given company really don't vary all that much, so it often is like installing a WP blog. Since most companies do only minor variations of the same thing, you have pretty good history of how long the last variation took. I can think of my last job for example. We built extremely complex medical devices, but yet we could say: software for this product will take us 4 years from concept to getting it on the market and we'd be accurate within a couple of months. It takes work and planning and sitting down and literally thinking of every major task along the way and trying to estimate how long it will take. Estimation of that sort is expensive and you have to have a good reason to take the time to do it. You also have to keep re-estimating as time goes on. Schedules aren't fixed in stone if they are to mean anything. Have to make a market window and you're running late? Well if your estimates mean anything, then features have to be removed or you ain't gonna make it! I do agree with the management comment. You need good management that understands what they're doing. Management that understands if they change features, there is a cost. But it's up to developers to continue to make this clear to them.
- ScottBurson 10y ago
  > Estimation of that sort is expensive and you have to have a good reason to take the time to do it. Just wanted to emphasize this sentence. Good estimates take time and cost money -- time and money that aren't necessarily worth spending. In many cases you're better off living with order-of-magnitude estimates and spending most of your time doing the actual work -- depending on the nature of the business, of course.

cpitman 10y ago

Actually, it means a lot. It tells us how much we understand the project's timeline. Many projects get estimated way to early in the process, and the true level of uncertainty at that point is massive. If the low confidence level means the estimate has an upper end that isn't feasible, there are things we can do to increase confidence. Proof of Concepts/Spikes are explicitly for the purpose of taken an unknown feature and getting a better understanding of their complexity, scope, and timeline. (http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/ http://www.construx.com/Thought_Leadership/Books/The_Cone_of...) So then the hard part is communicating to the business the current estimates and confidence level and that we can do some up front work to tighten down our estimate and the schedule. This is actually part of ACM's "Software Engineer Code of Ethics": "3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates." As for pharmaceuticals, I have no experience there. I doubt that they really just let scientists go off and do whatever they want with unlimited budgets, and just live with the results.

FollowSteph3 10y ago
So let me ask you a simple question, how much time do I have to give the initial estimate and how long do I get to increase confidence? Is it in the order or days, weeks, or months? I ask because a 25% confidence level on 4-8 weeks would most likely require some time to increase the confidence, more than you would be permitted. I agree with what you're saying and that's all great and awesome but in the real world it unfortunately doesn't work that way. In most cases you have a day to a week to come up with an estimate for a year long project. If you by great luck get a cognate to do a spike, you get maybe an extra day. Ok most cases actually you would've maybe gotten an hour to a day at best and there would be no spike, and if you did get a spike it would be maybe an hour. Again I agree with what you're saying but it just doesn't work this way for the vast majority of companies. Also is this real time or actual time? In other words does it include time for meetings, holidays, sick days, change in staff, etc.
- HeyLaughingBoy 10y ago
  Not to argue with you Steph, but that indicates a management problem. If I ask one of my guys for an estimate, I expect that it will take them time. If I need a SWAG, I'll say that. If I need an accurate estimate, I'll tell them that and ask how long it will take. Most (competent)management understands that everything has a cost. The problem that I've seen repeatedly is that devs toss off a quick guess without thinking about it very much and then act surprised when they're held to it. That said, I believe that a week is plenty of time to estimate a year-long project. However, you need experience estimating. Look, I'm no genius at this but when asked to estimate a task, this is what my manager would normally get: Time to Research fuzzy task C Find libraries for X, Y, and Z Assume cost of $A for libraries. Make sure we have this in the budget to avoid delays Repository setup time Tool configuration time (if different) Feature A Feature B ... Integration Test time for x, y, z I'm on vacation for a week Bug fix I need to interact with Susie in Manufacturing around this date and she says she will be having a baby and out for 6 months. You need to find me a replacement contact. Incorporate feedback from Manufacturing. Historically this adds about 2 weeks to any project. Add up all the times and provide an estimate along with any confidence intervals around each line item. This is how I have done it in the past before we implemented more rigorous processes and never gotten complaints. It gives management plenty to data to work with and talking points for them to ask questions about.

HeyLaughingBoy 10y ago

But that is exactly how I normally respond to estimate requests. "I have 70% confidence it will take between X and Y hours." That's a huge difference from saying "I have no fucking clue." If I say I think something can be done in 6 weeks and I'm 70% sure, Management now can weigh the risk that I'm wrong against the benefit. Most software projects in a given company really don't vary all that much, so it often is like installing a WP blog. Since most companies do only minor variations of the same thing, you have pretty good history of how long the last variation took. I can think of my last job for example. We built extremely complex medical devices, but yet we could say: software for this product will take us 4 years from concept to getting it on the market and we'd be accurate within a couple of months. It takes work and planning and sitting down and literally thinking of every major task along the way and trying to estimate how long it will take. Estimation of that sort is expensive and you have to have a good reason to take the time to do it. You also have to keep re-estimating as time goes on. Schedules aren't fixed in stone if they are to mean anything. Have to make a market window and you're running late? Well if your estimates mean anything, then features have to be removed or you ain't gonna make it! I do agree with the management comment. You need good management that understands what they're doing. Management that understands if they change features, there is a cost. But it's up to developers to continue to make this clear to them.

ScottBurson 10y ago
> Estimation of that sort is expensive and you have to have a good reason to take the time to do it. Just wanted to emphasize this sentence. Good estimates take time and cost money -- time and money that aren't necessarily worth spending. In many cases you're better off living with order-of-magnitude estimates and spending most of your time doing the actual work -- depending on the nature of the business, of course.