3 ms·

I understand that sometimes a project 'takes as long as it takes', but how does one deal with extrinsic deadlines then? For example, software that needs to be '

I understand that sometimes a project 'takes as long as it takes', but how does one deal with extrinsic deadlines then? For example, software that needs to be 'on the shelves' by the next Black Friday, or the next tax reporting season. Estimates can't predict the future, of course, but good management will know that 'make the deadline, no matter how' is not the only option - changing scope is another popular option, for example.

cloverich 7y ago
> but how does one deal with extrinsic deadlines then? Deliver working software one chunk at a time, however you have to break it down to make it so.
- ralmeida 7y ago
  After you're set on the general product you are building, that's fine. But consider you're trying to decide whether to build product A or B for deadline X. Which one has the largest probablity of finishing on time? I'm not advocating having engineers estimate the completion date of their daily tasks, I'm just saying estimates aren't totally useless. For another viewpoint that's not just mine, consider point 6 of the Joel Test, or the methodology of Evidence-Based Scheduling, also by Joel Spolsky (https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...).
threwawasy1228 7y ago
I think that a lot of people who work on deadlines like this have learned how to incorporate this into their products overall structure. Think of games that have to be released on a proper timeline for a specific holiday season. Now instead of trying to meet those deadlines, game developers are putting out a minimum product and releasing updates, patches, and missing portions of the game in chunks after the official purchase/release date. Whether this is successful or not is up for question, but it seems to be one strategy for coping with amorphous deadlines.
- ralmeida 7y ago
  This sometimes works for games, but not for everything. Consider, for example: * Tax-reporting software * Adding a coupon system to your ecommerce software in time for Black Friday * etc
wpietri 7y ago
The solution is exactly as you say: being realistic about scope. If we absolutely have to have something by, say, Jan 1, then the first thing to do is figure out the absolute minimum for "something". The way I'll usually explain it: "Put yourself mentally on January first. If there is a feature whose absence would make you delay shipping despite the consequences, put it in the minimum set. If you'd ship without it, then leave it out." Then we start building, measuring completion toward goal as we go. If the project is in good shape, we pretty quickly should be able to say, "Yes, we'll hit that months ahead of time," or maybe, "The date is at risk, but here's what we can do." As a bonus, we will also quickly have something we can put in the hands of users. Maybe for validation, maybe for early feedback, maybe for revenue! Then as the date comes, we're just getting the nice-to-haves. We know we can ship any time, because we've been shipping frequently for a while now.
- ralmeida 7y ago
  That's absolutely fine and a good way to work. However, I do still believe that plain old estimation has its place. Consider that you are part of a bunch of executives deciding in January whether to build a product A, which would have to be done by Black Friday, or product B, which would have to be done by Christmas. Even after such a high-level decision is made, a broad scope estimate must also sometimes be made. For example: "would we have time to add a chatbot to this product?". If so, you could need to hire people with the relevant experience and have them ramp up. But if you have an estimate in the spirit of "well, must-haves A, B and C are probably going to take no less than X months, and the chatbot would take just as long if not more, so it's better to drop the chatbot idea and invest its budget elsewhere".
  - wpietri 7y ago
    I do agree that broad relative estimates for different paths can be useful once the project is underway, and in fact said so. But I just don't believe that the high-level decisions you describe can be effectively estimated in calendar terms. Even if you get the execs to cough up sufficient details for real estimates (which they won't), those decisions are being made at the point in the project lifecycle when people know the very least. Any user-focused team will learn a ton along the way that shapes the product, and presumably neither the competition nor the market is standing still. Better decisions driven by learning means scope volatility, which means there's a hard limit on the utility of estimates. I think the best one can do on day 0 is give reasonable sanity checks and the haziest of ballpark numbers. But that's fine, because execs are making ROI calculations, and there's no point to making your I more precise than your R. And we all know how much of a SWAG business value estimates are early on.

cloverich 7y ago

> but how does one deal with extrinsic deadlines then? Deliver working software one chunk at a time, however you have to break it down to make it so.

ralmeida 7y ago
After you're set on the general product you are building, that's fine. But consider you're trying to decide whether to build product A or B for deadline X. Which one has the largest probablity of finishing on time? I'm not advocating having engineers estimate the completion date of their daily tasks, I'm just saying estimates aren't totally useless. For another viewpoint that's not just mine, consider point 6 of the Joel Test, or the methodology of Evidence-Based Scheduling, also by Joel Spolsky (https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...).

threwawasy1228 7y ago

I think that a lot of people who work on deadlines like this have learned how to incorporate this into their products overall structure. Think of games that have to be released on a proper timeline for a specific holiday season. Now instead of trying to meet those deadlines, game developers are putting out a minimum product and releasing updates, patches, and missing portions of the game in chunks after the official purchase/release date. Whether this is successful or not is up for question, but it seems to be one strategy for coping with amorphous deadlines.

ralmeida 7y ago
This sometimes works for games, but not for everything. Consider, for example: * Tax-reporting software * Adding a coupon system to your ecommerce software in time for Black Friday * etc

wpietri 7y ago

The solution is exactly as you say: being realistic about scope. If we absolutely have to have something by, say, Jan 1, then the first thing to do is figure out the absolute minimum for "something". The way I'll usually explain it: "Put yourself mentally on January first. If there is a feature whose absence would make you delay shipping despite the consequences, put it in the minimum set. If you'd ship without it, then leave it out." Then we start building, measuring completion toward goal as we go. If the project is in good shape, we pretty quickly should be able to say, "Yes, we'll hit that months ahead of time," or maybe, "The date is at risk, but here's what we can do." As a bonus, we will also quickly have something we can put in the hands of users. Maybe for validation, maybe for early feedback, maybe for revenue! Then as the date comes, we're just getting the nice-to-haves. We know we can ship any time, because we've been shipping frequently for a while now.

ralmeida 7y ago
That's absolutely fine and a good way to work. However, I do still believe that plain old estimation has its place. Consider that you are part of a bunch of executives deciding in January whether to build a product A, which would have to be done by Black Friday, or product B, which would have to be done by Christmas. Even after such a high-level decision is made, a broad scope estimate must also sometimes be made. For example: "would we have time to add a chatbot to this product?". If so, you could need to hire people with the relevant experience and have them ramp up. But if you have an estimate in the spirit of "well, must-haves A, B and C are probably going to take no less than X months, and the chatbot would take just as long if not more, so it's better to drop the chatbot idea and invest its budget elsewhere".
- wpietri 7y ago
  I do agree that broad relative estimates for different paths can be useful once the project is underway, and in fact said so. But I just don't believe that the high-level decisions you describe can be effectively estimated in calendar terms. Even if you get the execs to cough up sufficient details for real estimates (which they won't), those decisions are being made at the point in the project lifecycle when people know the very least. Any user-focused team will learn a ton along the way that shapes the product, and presumably neither the competition nor the market is standing still. Better decisions driven by learning means scope volatility, which means there's a hard limit on the utility of estimates. I think the best one can do on day 0 is give reasonable sanity checks and the haziest of ballpark numbers. But that's fine, because execs are making ROI calculations, and there's no point to making your I more precise than your R. And we all know how much of a SWAG business value estimates are early on.