D
The depreciation function associated with a valuation irrespective of an explicit deadline will eventually decay past a point that it ceases to be worthwhile to continue, thus creating an implicit deadline.
Other
What about a hard, exogenous deadline?
F
Fermi estimate
Also known as
Fermi problem
See Also
I
If you charge an absurd amount of money, you may be able to buy your way out of an unforeseen crunch and keep your reputation in return for slightly less profit.
Other
Charge an absurd amount of money.
"Exhaustively" implies this process will be characteristically labour-intensive and time-consuming. A linear padding factor is likely to not be enough, since the error accumulation is superlinear (i.e., exponential). A stakeholder may be evaluating many different competing investments and is looking for the best return before they commit. A stakeholder may have upstream commitments. A stakeholder may require a result by a certain date, or the value of the result is compromised. Accurate effort estimates are contingent on eliminating all sources of surprise, and software development is particularly, if not uniquely full of surprises. Accurate software effort estimates aren't impossible, but it can take as much time to do the estimate as it does to write the code. Accurately estimating the effort it takes to deliver a unit of software is notoriously difficult. Begin by modeling the final handoff of the deliverable from the point of view of the client, and work backward to the present. Break the deliverable down into parts. Charge an absurd amount of money. Clients generally want a return on their investment, and (by the time they're talking to you about it), they tend to have an idea (irrespective of accuracy) around what it's worth. Compute a dependency graph from the topologically-decomposed parts. Concomitantly, the risk/value-based methodology has not been able to be fully deployed without the infrastructure to manage it. Create a Monte Carlo model that simulates the product recovering value. Use it to derive a probability distribution for the valuation. Didn't Ole Peters say expected value was bad? Discount the valuation to zero (or whatever compromised value you want to discount it to) after the deadline elapses. Establishing the value of the outcome should be part of the discovery process. Estimate the effort it will take to deliver a unit of work product before committing to a budget and/or schedule. Even relatively modest software deliverables can exhibit considerable complexity. Exhaustively work out the behaviour the software must and must not exhibit. Expectations around the capabilities and/or behaviour of the software are inadequately articulated, and often even inadequately researched. Fermi estimate Get the value of the outcome out into the open. How do you estimate the effort for the individual parts? How does one valuate an outcome that hasn't happened yet? How long is the estimate itself going to take? Who is willing to wait for it? Do you need to do an estimate for the estimate (for the estimate…)? If the client doesn't want to speak frankly about the value of what they want you to do for them, that is a huge red flag. If you charge an absurd amount of money, you may be able to buy your way out of an unforeseen crunch and keep your reputation in return for slightly less profit. If you have a clear idea of at least the contours of what the projected outcome is worth, it's much, much easier to realistically scope the project. If you relegate your bread-and-butter work to stable and conservative deliverables, you will actually be able to use any empirical data you record. If you're padding your estimates by the square of the baseline value (or even if you're doubling or tripling them), are you even really estimating anymore? Inventory all the mechanisms by which the outcome creates marginal value (e.g. causes one sale, prevents one churn, eliminates some cost…). Isn't that what user research and interaction design are supposed to do? It is much, much easier (and thus much quicker) to estimate the value of a completed project than the cost of completing it. It may indeed turn out that the partitioning scheme that divides the software development work itself into parts, is incorrect. It may turn out that the parts the software product invariably comprises, need to be created in a sequence other than the one anticipated. Just pad your estimates. Double, even triple them. Knowing what the outcome is worth will inform the price you can charge for it. Most software just glues together other people's software, and other people's software has bugs and limitations, and often doesn't work as advertised in its documentation. New (and existing latent) information is continually being discovered over the course of any project. Only commit to doing well-rehearsed work with plenty of data about how much effort it takes. Padding only makes sense for exogenous factors; most of the problems that arise in software development are endogenous. Past a certain level of complexity, the time (and thus money) it takes to produce an effort estimate that is accurate enough to rely on, tends to be generally unacceptable. People do succeed at beating deadlines derived from their effort estimates, so how do they pull it off? Respond to these questions instead with "if you can tell me the gross value, I can give you a curve that represents the size of the return at different probabilities." Stupid question, but WHY do stakeholders need to know how long it will take and how much it will cost? Subdivide the project topologically by way of minimum cut. Do not subdivide by prescribed category. The PM ontology has been contemplated/tinkered with for nearly two decades, but hasn't been tested prior to having Intertwingler/Sense Atlas available to test it. The depreciation function associated with a valuation irrespective of an explicit deadline will eventually decay past a point that it ceases to be worthwhile to continue, thus creating an implicit deadline. The estimate may not model all the work needed to deliver the result in a manner that the client is willing to accept. The general strategy of adding estimates up from zero means you will always underestimate, and that deficit will grow with the size of the thing you are estimating. The information-gathering process should suffuse the project, run its entire length, and effectively serve as its backbone. The information-gathering process typically associated with scoping and effort estimation is too expensive be done on spec; it has to be compensated, and thus integrated into the project. There may be pathologies at the system level that are not evident until the system is assembled and running as a whole. Thoroughly test all third-party functionalities before making any commitments that depend on them. Two inevitable questions of key stakeholders on prospective projects are "How long will it take?" and "How much will it cost?" Up-front testing of all, or even most third-party software is cripplingly burdensome on its own. Use data from timesheets for comparable components. Use risk-weighted net present value that divides the NPV by the expected value. Use the discounted cash flow method to get the appropriately discounted net present value of the work product. Use the mode (it will almost certainly be asymmetric) or agree on a sensible percentile for the distribution, as well as a sensible time horizon. What about a hard, exogenous deadline? What about depreciation over the time it takes to complete the project? What about the risk of benefit shortfall, or total failure to deliver? What if the client doesn't want to be forthcoming about the value of the outcome? What if the client insists on a number rather than a probability distribution? What if the timesheets aren't sufficiently granular? What if the value of the outcome is genuinely unknown? What if you don't have timesheets? What if your timesheets don't contain anything sufficiently similar to the thing you're currently trying to estimate? What kinds of surprises are endemic to the software development process? Who is going to pay for the work of performing the estimate? Why is software development so difficult to estimate? Worth noting that the risk profile of a piece of software changes dramatically once it is delivered. You can use the Kelly fraction instead of expected value if you want. You should establish the value of the outcome for yourself irrespective of the client's disposition to it.