| (about estimating - I don't tend to write proposals) You could have a look at https://www.estigator.com (NB it's a half-finished side project right now) I'm no longer a contractor, although I have been, and I'm frequently asked by my new employers to provide estimates for dev tasks. Trouble is, businesses/clients tend to see an estimate as a promise, or a target. From the developer's point of view it is hard to do anything other than guessing (at smaller and smaller granularities). Book recommendation: "The Clean Coder" by Robert C. Martin - esp. Chapter 10) I started building https://www.estigator.com to see if I could learn React, and come up with something to help me illustrate just exactly who's taking a risk when we say something like "it'll probably take about 3.5 days" I wasn't quite ready to "Show HN" with this one, but your question made me think of it straight away. Would love to know what people think |
Even worse, they tend to treat the date/cost line as a promise, but the scope as infinitely flexible.
One other thing that makes me crazy is that a lot of places determine the date by a process that yields the first non-impossible date. (E.g., "Can this be done by Thanksgiving?" Developer yelps and says, "Well, maybe if everything goes right it could be done by Christmas." The PM responds, "Great! Christmas it is! I'll tell the CEO.") But if non-impossible means, say, 5% chance of success, then the developers look like goats 95% of the time.
These days, except with highly trusted partners, I basically refuse to estimate anything over 3 days without formal estimation and a self-calibrating process where any date is a function of product manager choices. (E.g., points, velocity, burndown.) But I find that less and less valuable, as interesting projects typically have requirements volatility too high to make dates actually predictable. Instead I prefer a release-early, release-often approach, hitting any non-artificial deadlines by being ready well in advance and iterating.