4 ms·

>Treat the estimate as a best guess and then re-evaluate when you have better information. Any suggestions for how to effectively communicate a "best guess" an

>Treat the estimate as a best guess and then re-evaluate when you have better information. Any suggestions for how to effectively communicate a "best guess" and a "re-evaluation" to a business side that basically demands "hard deadlines" for projects?

brightball 8y ago
EDIT: My original answer is below but a much more concise and clear explanation is in one of the other articles that was linked in the comments. https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch... Check out his "4) Pile of wood blocks" My original answer though -> Forward along this article? The Software Estimation book mentioned in the article does a really good job of breaking it down. Hard deadlines come with a lot of questions, like why? Is there a trade show? An investor meeting? A marketing campaign? Is it really a hard deadline? Specifically, if the product isn't ready yet are you planning to launch no matter what because we have to? If not, then it's not a hard deadline and deadline needs to be reframed around goals. You'll never hear Apple announce a product until it's actually ready to ship. Usually hard deadlines come from announcing something that doesn't exist yet. The outcomes are usually buggy, rushed systems or missed deadlines that make companies look bad. If it's for a trade show, the question is closer to "what exactly do we need for this trade show?" because management will always say "everything!" I always tell the story of a particularly bad client that I had years ago who insisted that he had to have a project completed 3 weeks ahead of when we told him it would be ready. My partner and I killed ourselves, gave up weekends, worked crazy hours to hit his deadline for him. And we also monitored the parts of the application that he had us create. He didn't even look at them until 2 months later. After that we learned to create "Rush Rates" when requests like that come in, because if demanding something be done faster has no cost to the person asking for they are going to continue to ask for it. At a company with salaried employees, management has to understand that rushes and scope creep come with tech debt and quality issues in order to hit "the deadline". Understanding things like "tech debt is not just a task you do later, it actually makes everything you do worse" are critical in that regard. When you can get a manager to say "I don't care of quality suffers as long as we can show it on the floor at the show" then you know it's a deadline. Ideally, point them to that book to help them understand the difference between estimates, commitments and targets.
- Benjammer 8y ago
  I like the idea of digging more into real business requirements, but I'd question one thing. >You'll never hear Apple announce a product until it's actually ready to ship. Apple is a consumer tech, flagship-product-focused company. B2B timelines, contracts, and deliverables work somewhat differently. Apple can always "miss" a deadline and just choose not to debut the new product yet (worst case). Many B2B contracts hinge on explicit future product deliverables, because there is a TON more power on the buy side when dealing with business clients as opposed to individual consumers. Do you have experience with these estimation issues in a B2B context, any flavor you can add there?

brightball 8y ago

EDIT: My original answer is below but a much more concise and clear explanation is in one of the other articles that was linked in the comments. https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch... Check out his "4) Pile of wood blocks" My original answer though -> Forward along this article? The Software Estimation book mentioned in the article does a really good job of breaking it down. Hard deadlines come with a lot of questions, like why? Is there a trade show? An investor meeting? A marketing campaign? Is it really a hard deadline? Specifically, if the product isn't ready yet are you planning to launch no matter what because we have to? If not, then it's not a hard deadline and deadline needs to be reframed around goals. You'll never hear Apple announce a product until it's actually ready to ship. Usually hard deadlines come from announcing something that doesn't exist yet. The outcomes are usually buggy, rushed systems or missed deadlines that make companies look bad. If it's for a trade show, the question is closer to "what exactly do we need for this trade show?" because management will always say "everything!" I always tell the story of a particularly bad client that I had years ago who insisted that he had to have a project completed 3 weeks ahead of when we told him it would be ready. My partner and I killed ourselves, gave up weekends, worked crazy hours to hit his deadline for him. And we also monitored the parts of the application that he had us create. He didn't even look at them until 2 months later. After that we learned to create "Rush Rates" when requests like that come in, because if demanding something be done faster has no cost to the person asking for they are going to continue to ask for it. At a company with salaried employees, management has to understand that rushes and scope creep come with tech debt and quality issues in order to hit "the deadline". Understanding things like "tech debt is not just a task you do later, it actually makes everything you do worse" are critical in that regard. When you can get a manager to say "I don't care of quality suffers as long as we can show it on the floor at the show" then you know it's a deadline. Ideally, point them to that book to help them understand the difference between estimates, commitments and targets.

Benjammer 8y ago
I like the idea of digging more into real business requirements, but I'd question one thing. >You'll never hear Apple announce a product until it's actually ready to ship. Apple is a consumer tech, flagship-product-focused company. B2B timelines, contracts, and deliverables work somewhat differently. Apple can always "miss" a deadline and just choose not to debut the new product yet (worst case). Many B2B contracts hinge on explicit future product deliverables, because there is a TON more power on the buy side when dealing with business clients as opposed to individual consumers. Do you have experience with these estimation issues in a B2B context, any flavor you can add there?