I’m interested to know how fellow software developers (freelancers, small businesses) estimate projects for clients.
Do you use any tools to come up with a quote? Do you send a proposal document to clients? If so, do you use a tool to generate one, or do you just use a template in a word processor? What are your main pain points when quoting for work?
Cheers!
(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.
I think your landing page communicates well, it was pretty clear what it was going to do. The only thing I wasn't sure about is if the tool is also meant for teams larger than one. Then I would need to be able to enter different costs based on different roles, but I'm not sure if that's the target audience.
You said the project is half finished, so I assume you have tons of small UI improvement ideas already... But I would really prefer a different method of adding new lines/tasks over just adding every type on add :), for example a dropdown with an add button.
* A flat probability distribution for "will take between X and Y" is probably wrong, a bell curve would be more accurate (where X and Y are the 95% percentile).
Another question: is it open-source? I'm sure a few people around here would be glad to hack into the code ;-)
I'm seeing this message:
>>> Total is expected to be about 22.3 days.
>>> * likely to be greater than 15 days (p = 95%)
>>> * has a 50% chance of exceeding 20 days
>>> * unlikely to be less than 33 days (p = 95%)
Is the last bullet point correct? Shouldn't it be __likely__ to be less than 33 days?
It's a spreadsheet where each cell is a probability distribution, quite well done and easy to use.
Note: I'm not related to this service in any ways.
It would be really nice to be able to save the estimate to send to clients. Don't necessarily need backend for that - we can store data in the querystring for a fast & easy hack.
Do you have a newsletter or something similar to subscribe to for releases?
Then I got a full-time job and have stopped working Estigator for now.
It's really nice and encouraging to hear the feedback and read the bug reports on HN. I think the most likely next step for Estigator is for it to become an open source hobby project. Still mulling things over.
So - no newsletter sign up (privacy policies, GDPR, bler) - but I will certainly announce at https://www.rmorrison.net (my personal homepage) if I ever move things along.
This is exactly like I do things!
Dead Comment
Dead Comment
I usually explain that development is an iterative process, and that I generally deliver work as soon as it's done.
We talk about the knobs that are available to tune the work to the goal, and how to measure goals. We talk about containing costs, and working together to deliver good value.
I find that in general, estimates are rarely, if ever, accurate to any significant degree, and thus are usually dishonest when presented as a way to assuage client anxiety over "when will it get done" or "how much will it cost".
FWIW, it's not as bad as it sounds, it just means that the PM's see red in their charts and end up bugging people with "urgency attacks". Slippage is common and that's OK.
The vast majority of the time, an estimate is just an estimate. Passing a deadline isn't fatal, nor is it failure (regardless of whatever it says in the Project Management Book of Knowledge).
Hard as this is up front, it's harder to explain afterwards why your estimate didn't work out, and it's harder to eat the cost difference yourself. Be gentle and polite, and accept that they may or may not be willing to work with you on trust that you will do your best to finish as quickly as you can.
I don't think a developer's salary is high enough to justify taking on any moral risk on the basis of estimation of any project.
In Australia, even the highest budget software projects have major cost and time blow-outs, often in years and often in 100s of millions of dollars. If this were a solved problem then this would not be the case.
I think the best thing you can do is retrospective analysis of work completed for a given individual and a team, and use that to project, but I am yet to find a client who is vaguely interested in such a thing, e.g. Joel on Software's Monte Carlo estimation solution [0].
I'm cynical because it's early!
[0] https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
If you do this, some people will work with you,
some people will not.
If you work with those people, this will not work.
Sadly
You're kinda arguing against yourself. I agree that dev is an iterative process and that estimating is a lost cause, but "deliver work as soon as it's done"? The whole point is that a "done" project doesn't exist. Deliver all the time (every day, every week at worst), iterate and stop the project when the client is happy with what they have
It's easy to write stories that are "do the UI for X", and then "do the back end for X". But often the UI (at least the first cut) is easy to code and comes out quickly, giving the customer the impression that everything will be quick. Then you work on the back end and it goes a lot more slowly, leading to mistrust. Alternatively, working on really complicated things up front (while generally a good idea) can give the customer the impression that the project is stalled and that it's never going to finish.
When you are doing iterative development, I think the real art is in choosing your stories. It's difficult, but when done well it removes most of the political friction in development.
For real software development, where you develop a solution to a business problem, estimates are worthless. The thing is, solutions to business problems are very specific, which means you need to think it through from scratch starting with the idea, and ending with the implementation which is a large terrain where many things can go wrong.
If you're still required to make an estimate for the sake of having one, I recommend going with a range. Think of pessimistic and optimistic scenarios. Make sure to add a generous buffer to both ends, to account for the unknown issues that are guaranteed to appear. Also, add in the disclaimer that this is a rough estimate and that the final time requirements might differ. This kind of works for hourly/open contracts.
For fixed price contracts I'd say think of an amount that YOU feel comfortable with. Better to exaggerate than feel sorry. Remember, you have the solution, the client has the money.
I go by these rules, and I'm quite happy.
Dead Comment
How much is it worth to fix? That's a much easier value to discover.
From there work backwards to determine how much to spend and where to prioritize.
Eg: a bug generates 3 email and 3 phone support issues per day, at a cost of 1h or $33/day - $12k/yr. Easy to justify spending one dev-week on the issue ($6k).
Or missing feature that lost a sale of $50k easily justify $5k to make some progress.
Even in your example, are those phone calls the substantial costs, or is it customer confidence in your product being lost the main motivation you should do something with the bug? If so, what's the dollar value of this confidence? Also, do you have monitoring good enough in place to see how many customers are hitting the problem every day without telling you? Do you think these customers are less or more frustrated than the one they are calling you?
Can you attribute lost customer to a particular feature not present, to a particular bug the customer experienced just before they refused to deal with your software anymore?
I'm measuring stuff that is actually happening, whatever it is (phone, email, error log, metrics, etc) and have to assign a cost. I find that easier than guessing how long to discover the right answer to a (maybe) complex problem.
For phone and email support it's easy, directly measurable cost. One would decide for them selves how to factor those intangibles (ie: confidence).
Currently I do things like this-ish: - Phone and email at direct cost; but if the issue is a duplicate double cost. - Lost deal factor at 15% first year value - Logged errors at $10/first, $2/dupe - make values that match your company revenue/expense.
We try to exit interview clients but generally have a good feel for it - ours is a pretty high touch relationship
If something took up one hour of my day and I could spend a week one-off to reduce that to 0 hours a day, that's a no brainer.
The larger the project, the more documentation, planning and budgeting. And no tools really help with this in general. But if it's big enough, I will do mockups, everything else is just a well formatted document.
For my regular clients I've worked with for years, a simple email/phone call > deliver product > invoice is enough of a work flow if the project is small.
A few large projects I've spent a few months documenting, planning and having client meetings before any work started. I suppose, some online collaboration tool could have been useful there.
But also I have large ongoing projects with long term clients where monthly work is done, and monthly meetings are held. But since most of my clients aren't technical, there's no need to involve them in anything other than front-end review, testing and publishing. So we get most of this done at a monthly face-to-face and a few emails.
I do have a nice formatted LibreOffice document template with header, footer, logo, etc... I tend to use this for new clients. (PDFs only though)
Our clients use https://paymoapp.com, where we add the initial plan as a temporary project. Once all time budgets and costs are set up, we convert the project into an estimate and share it with the client.
The client then reviews the estimate and either accepts or rejects it. If accepted, we go into production.
You don't use the time-tracking capabilities for software development though, do you? While I could see myself loving to use the tool on my own, being on a team that's required to account for every minute of time (assisted by friendly tracking software no less!) sounds horrible.
The key to this process working is to have a tech assurance function that is independent of the bid team and their management, and that the overall company accepts the process. The assurer can say to the business "I think you are pricing this too low for the risks involved" but it is specifically not the reviewer's call as to whether the bid is submitted or not, so management can still submit the estimate if they want to. But, if things subsequently go south, the blame isn't immediately passed to the bid team or the delivery team.
Alternatively, generate an estimate, round it up to the next order of magnitude, and double it.
It is not a joke comment. I could go into a lot of detail about methods that I've used, but it's the most important and valuable piece of knowledge that I've gotten out of this experience: we're bad at this. No matter how we do it, that's the thing that we should never forget.
Almost every project runs into an unforeseen roadblock. The less experience you have with a sort of project, the more true this becomes. You can't account for things you don't see coming, so the usual answer is to arbitrarily pad estimates, and of course arbitrary padding is usually wrong.
A project plan is more useful for finding bottlenecks than predicting an end date. So unfortunately, the best tip I can offer is to make sure people are aware of the uncertainty involved, and beware of people who expect it to be straightforward.