Ask HN: Developers, how do you estimate projects and write proposals? 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! |
Here's an example for a small project with a new potential client I met with for about 20 minutes: https://gist.github.com/bc2f83544b210f81715c4f4175fca985
Estimates are fairly wide because I haven't seen any of their code, just a brief screenshare and a description of the work they would like completed.
It might seem old school, but a lot can differ based on project basis (e.g cooperation with other companies, 1 month vs 2 year projects). Word and excel are just flexible and easy enough for me.
A proposal doesn't need to be done in a special tool. It's a simple document that outlines what will be done. I've personally used notepad.exe at times. Always send the proposal, estimates and payment terms before even starting any work. If it is a larger project, you can charge for the proposal itself.
- It takes 4 hours to change a single line of COBOL, once you take compilation, testing, documentation, etc. into account.
- The best way to estimate is to gather as much information as you can, estimate each piece and sum them. Then take that number and multiply it by two. Then take that sum and double it.
Both turned out to be pretty good advice.
I charge regular clients (the ones that I do some work for every month) by the hour.
I use a spreadsheet to track my time.
Less regular clients, I estimate the project and bill them a fixed amount.
Shameless plug: For estimating projects I use a web app I built (https://estipad.com). It lets me break projects down into tasks and subtasks and estimate those instead of the whole project. It also generates a PDF that can go straight to the client.
If you use a 99.9% confidence interval and miss the high estimate, then you're probably over-confident. (And your estimate was probably too wide to be meaningful.)
My process looks like this:
1) Decide how big of a project it is. Is it a small script or app that does some simple data manipulation? If so that's a week project. Is it larger? Maybe it is a 3 month project. Complete software solution? 1+ years (usually).
2) Go back to the client with this information, but don't spend days on getting something precise. Have the discussion with them: "from what I understand, this is going to take some time to get together for you. Are you prepared to work on the project scope with me some more?" for a larger project, the 1+ year project, they have to be prepared to spend days, even weeks, working with the team to get them a product. The time is roughly proportionate: they (the business) have to spend 1/4 to 1/2 of a work day for each week of development. 2 to 4 1-hour "talks" or reviews (on their time).
3) OK they are prepared. Talk to them some more, have the first 1 or 2 hour meeting and work on the scope, using your notes from #1 and #2. You bill them for this time. Might take 4 hours or might take even close to a week (with a demo to prove you can solve the core problem) to get them a scope of work.
Again, very important: you bill them for #3.
I always stress to the client that if they don't like the work done of course I have a satisfaction guarantee, but if the SOW is solid (and I do stand by my work, so I will make sure it is so) then they have to pay for it. If they like the SOW it is theirs once they pay: it is reasonable for me to expect them to outsource this scope to another team. I make that very clear.
Also, after #3 you'll have an idea of how big the project is. I give them an estimate for the way-high end, then add a bit to it. So if I completed a recent project like this one in 1 month, I say to myself "this took me about a month of work, focusing on just this project. This is worth some $N to me. But, you know, it might take longer - I'm going to estimate to the client it takes 2.5 months, to be safe, and tell them ($N * 2.5)."
I always do this, because often you'll end up under-billing the client and then they're super happy and will probably end up spending that extra $$$ with you anyway.
And if you don't under-bill (I almost always do using this system, unless massive pieces are left out) then well, the client is none the wiser (I hate putting it like this, but it is true) and you are being responsible to them and your own business.
The alternative is either telling them you have to charge them more $$ or you're going out of business, or eating thousands of dollars in cost b/c you're underbidding on projects. Neither on sustainable, unless you're like Uber I guess? I don't know - my business is small and I don't have any outside investors :)
Slightly longer version: If the scope isn't locked down at a granular enough level, one where each unit of work would take no more than one day, then you can not trust the estimate.
If you as a developer provide or agree to an estimate before the scope is locked down, then you're doing this at your own peril. That estimate will be used against you at every opportunity. It will be used to pressure you into working for free (overtime isn't usually compensated for in full-time positions). Your personal relationships or chances of getting into one will suffer. You'll begin to hate the people you work with. You'll get fat and / or ugly. Remember Milton? Never forget Milton!
Being asked to provide an estimate prior to scope is more of a negotiation tactic than a serious attempt at accomplishing valuable work. If you thought you were making $x for y hours of work per week, well guess what?! Because of your premature estimate, you're now making $dx where d is less than one and hopefully above zero.
Okay, so lets say that you were able to lock get the scope locked down. What now? Now you can provide an estimate by adding up the estimates for all the granules of work you'll be doing and then you'll want to double that number. Why double? Because most developers are incredibly optimistic about their ability to deliver quality code. You're probably not adequately including time for QA and changes anyway. The last 20% of any project often takes 80% of the time, so double those estimates.
you ask for something, I know about how long that will take, and then I double it.
where n is the number of non-technical people in the room
(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!
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".
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.
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.
But the thing is, it's only to estimate, I will never bill based on these estimations, just help to plan the client.
- know enough about what you are doing to estimate at all
- screening for clients who will make it possible to work effectively, and knowing how to do that
-setting realistic expectations about what can actually be accomplished
- the client has the resources to pay for the project, including multiple iterations of dealing with the unexpected
- you the resources to make efficient use of the clients resources
- you don't promise to deliver something that you quoted at a higher price when the client talks you down to a lower price
- Discuss business problem that client is trying to solve. Often you can convince him to change requirements to make it cheaper for him, easier for you and better from technical point of view.
- Know your client's expectations and attention to detail. Some clients want to solve some business problem as cheap as possible. They don't really care about aesthetics and technical nuances of the solution. Others want very specific UI or technical design and won't compromise on any little detail.
- Listen to your gut. Sometimes I feel like something is complicated, but I can't really justify why and end up giving lower estimate. Almost always it was a mistake.
- Always add some buffer for unexpected complications. Bigger the project - bigger the buffer (even in percentage terms).
- I would also recommend to add some buffer for change requests. Almost always client would want to change some small things. It's easier to give bigger estimate upfront than try to charge for every small change later on. Client is never happy with additional charges, even if he knows that he hasn't asked it at the beginning of the project.
- This last one might not be possible in every situation, but I personally always ask for full payment upfront. For really big projects - 50/50. It's not a part of estimation, but this requirement goes along with the estimate. Another option, if the project is big, is to estimate and implement features one by one.
Software dev is a very difficult task to estimate. Giving an up-front project cost is either pushing uncompensated risk onto the developer, or overcharging the customer for hours of work that may not occur, depending on how tough the project turns out to be once down to the nitty gritty.
I also try not to give estimates to clients. Rather I ask when their deadline is. If they have none, then I say I will give weekly updates.
This is in many ways _harder_, though. Hard to estimate time required (supply-side), hard to estimate value to customer (demand-side).
As a service provider, "overcharging the customer for hours of work that may not occur" is effectively sidestepped by project-based billing. You're providing a product of value to them, not a number of hours of labor. Hourly rates are best left as an internal estimator of cost-to-supply-the-thing, and nothing else.
Give estimates in DURATION never as a date. Treat it as a stop watch, anytime interruption happens, the stop watch stops. So 2 weeks can actually take 6 actual weeks. If there's no research and interruption, then you should be able to give a +/- 10% estimate.
Do you have any experience/advice for R&D estimates? This is something I struggle with alot. We try to bill per _project_ rather than per _hour_, but I'm thinking R&D perhaps necessitates hourly billing, which sucks.
If there are new features that are a must have, assuming they are well known problems with solutions. You must state that the complete date is now undetermined till these are sized. You must charge for these features, you must communicate this verbal and in writing. You must be like a lawyer. Imagine how a GPS always re-calibrates any time you diverge from a trip, this is how vocal you must be.
As for research, don't do it. Do only what you know, unless you are being made crazy amount of money and you can't lose. Replace the unknowns/research with knowns.
Someone wants an ML system but you don't know it? Well, maybe you will figure it out in 2 weeks or maybe you won't. Replace it with a expert system if you know that. Perhaps you don't know that, replace it with simple SQL queries and rules if that's the best you can do.
They want a cassandra store? But you have no experience? replace it with MongoDB. They want kafka but you have no experience, and you know RabbitMQ? Use rabbit. Being optimistic almost always comes back to bite you, be paranoid. Abstract away the unknowns with clean interfaces so when the first version is done and the research is done, the new components can hopefully be plugged in with less friction.
For high-caliber projects (ie: some kind of engineering, regulated, or mission-critical software) I'll go with the ISO standard processes for software requirements gathering and estimation.
For SME-level businesses it depends on whether it's a new project or changing requirements to an existing one.
In the first case I'll do some light-weight analysis using event storming to map out the problem/process the users are facing/using. This will give me an idea of the scope of the problem domain (ie: how big is the problem?). This gives me enough information to make a Scientific Wild Ass Guess. I can only estimate at the granularity of weeks/months at this point.
Typically project estimates will be refined as the project moves along in increments.
In the latter case I have more information at the start. I can give estimates in three intervals: optimal, realistic, pessimistic. I include a confidence ratio in those interval estimates. The intervals reflect my understanding of the scope of the change and how much work it may end up being. The ratio represents my understanding of what I know to be true: if there are a lot of unknowns then my confidence in my estimate isn't high.
This lets my stakeholders estimate what they think the likely outcome will be and determine what they'd be comfortable with.
And I always make sure, regardless of which approach is used, that no estimate is a binding promise or commitment. It's a forecast of a possible outcome. My teams and I are still able to take on release deadlines and ship dates but I work those out separately from the estimate: how to ship releases and schedule them is team and industry dependent... but that's how I estimate things in general.
What I do is this:
- Split the project up in phases and split each phase into work chunks
- Conservatively estimate the time each chunk will take
- Estimate and add all project overhead (project management, meetings,...)
- Add time/budget for all known unknowns (design iterations, testing, bugfixes, deployment,...)
- Multiply the sum with a factor for unexpected things (things taking longer than expected, technical issues, anything unforseen). Depending on the absolute amount of hours budgeted and on what you know about the project and client this factor could be anywhere between 1.1 (everything should be straight forward) to 2 or even more.
- Multiply the total sum with your hourly/daily rate
- "Round" up the total number, depending on the client (smaller or larger company). This could mean to change 16.789$ to 20.000$ or 6.407$ to 7.000$
This helped me getting away from a pure hourly rate to flat-rate prices, whereas the estimation error should always be heavily on your side.
There are different ways of eliciting this kind of information. Learning to ask the right questions and then listen intently to what the customer has to say is key. There are more methodical approaches such as the Socratic method, which basically is a questioning technique that prompts the person you're talking to consider a matter from different perspectives in order to independently arrive at a conclusion.
Knowing about the benefit of a solution is tremendously useful because it allows you to anchor your price tag to customer value.
While this does not directly provide you with an easy way to estimate the cost of a project it achieves something far more important: Turning software from a cost centre into a profit centre and measuring projects in terms of something the customer actually cares about rather than your time.
As for estimating the actual cost for creating the proposed solution there unfortunately probably is no other way than by experience. However, the risk of giving an overall estimate that's way off can be mitigated by splitting a project into smaller components and deliverables if applicable.
Another approach that's particularly useful for projects of a more exploratory / agile (in the true sense of the word rather than the bromide it's become in many contexts) nature is setting a weekly or monthly budget. Rather than saying "You'll have X by this date." although neither you nor your customer know what X exactly is at that point this frames a project in terms of insights and incremental improvements generated along the way.
And then we put a gross 20% contingency. If you work well and you are good, then good for your wallet. If you suck, the customer does not have to pay for that.
As contingency is hard to admit by a customer, I wrote an article on that: https://medium.com/@gwelr/contingency-explained-to-our-custo... (shameless plug here)
Comments welcome !
If you don't have a multiplier, expect to work overtime or divide your revenue.
As you get more comfortable with your estimates and your tools, you can reduce the value of that multiple. I've been able to get it down to 1.5x but the scope of the work was limited and our team was very familiar with the code.
As for the proposal document, there may be templates online. Some agencies create an exact list of features, and wireframes so that there is no scope creep. I recommend you do the same if you have time (some agencies with a good reputation bill for this work). Also, allow your client only two small changes to the design. Anything more, and it's extra money.
Your main problem with quoting will always be properly estimating the amount of work it takes to complete a project. The same project, with two different clients, may go from profitable to a loss. It's very important to pad the work and to gain a lot of experience in a small number of tools so that you may get better at estimating. Specialization is key.
You'll hear some people say that they bill iteratively. It's possible but not every client wants to hear that their project has an undefined cost. You'll still have to cap it at some value in which you can deliver the work.
1). This is a new and unproven client, and if so, I go with the gut feel estimate e.g. 3 months, 2 weeks, 6 months to see if they understand how expensive software development (or any custom professional services) could be.
2). Understand if a rough or precise estimate is required. Are they looking for a fixed-price bid? Convince them that fixed-price is not in their interest. If the client insists on the fixed bid and the project is large and undefined, bow out. If the client is looking for a rough estimate, or the project is smallish (< 2 months), continue.
3). The client relationship is existing or the client and I are on the same page with the rough costing. If the project is large, explain that the estimation task is large and time-consuming, and ask to be compensated for the task. If the project is small (<2 months), eat the estimation cost.
4). a). Gather understanding and very rough requirements over several meetings, and create a document capturing this information. b). Procrastinate and then break down larger system areas into "epics" c). Create a set of releases that each deliver value to the customer d). Estimate each "epic" and assign reasonably buffered estimate to each release. 5). Walk the customer over the document, timelines, budget estimates.
There is however a lot of work you cannot estimate. If you still need to estimate the work you sometimes can set a max. For example you estimate that a API integration will cost you 16 hours but there are a lot of uncertainties. Then you can tell the client that you bill by the hour with a max of 32 hours.
Estimates in general are hard - I've had clients break everything down into micro chunks and estimate to the hour, and come up with a total ~100 hours. When I try to gently remind them that the last similar project took three months, there's generally push back. But if nothing changes in the approach, it generally takes about the same time.
The other option is to charge per hour with a range of hours you will work on the project. And if they want to make changes or add things you just charge more hours.
I do have to create proposals for new clients moving into my platform but, again, I have data from previous onboarding exercises. And all estimates have the clear and repeated caveat that they're based on the stated requirements; if the requirements change, the cost and dates change too.
When I was leading a development team through the estimation process for large and complex projects, I used the Wideband Delphi process, which is essentially a process of iterative decomposition; I recommend it.
We make it clear to the client that the quote is indicative, and may go up if their requirements/operating environment turns out to be more complex than originally described.
If they try and pin us to a fixed cost, we generally refuse the project, just because people are very bad at keeping track of what they originally asked for, even when it's in writing.
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.
It's not open source yet - but I'd like to release it one day I think.
More probability distributions (maybe event custom ones) were something I was thinking of for the future. Maybe a paid one.
I had a question for you too. You said you used this side project as an opportunity to learn React. I've been considering learning React and was wondering what tools/resources you used to get up to speed? I've found many different options online, but always appreciate hearing from people besides the authors.