Ask HN: Developers, how do you estimate projects and write proposals?

(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

Somewhat heretical, but I generally don't.

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".

I believe only a small niche of IT projects can qualify for "accurate" estimates, and that is tasks such as install Wordpress, swap image, etc, although even in these isolated cases there might still be factors that could easily throw you off with the estimate.

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.

I don't estimate, I work the other direction.

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.

In my experience, it all depends on the client and the project size.

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)

Start writing the brief/project charter with all the stakeholders to map out their expectations. Based on it, create the initial plan for the project by breaking it down into smaller tasks, grouped by task lists for better organization. What we do next is to analyze any similar projects we had in the past and how long it took to complete them, so we can estimate time budgets for new tasks.

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.

Lots of great answers here - but something I wanted to focus on is doing a risk analysis alongside the estimates. Places where I have worked have generated corporate estimates for clients (usually in a competitive bidding situation). One of the sign-off decision points business enforces on the bid teams is to check that they have considered risks to the project, possible impacts in terms of time and cost (usually related), and a risk budget (e.g. for extra days for rework) which depends on the magnitude and probability of the risks. Risks are usually expected to be higher if the work involves any sort of novelty. If risks don't manifest, the business makes more profit, but if they do the PM has a basic safety reserve. The need to keep estimates competitive generally creates pressure to force the risk budget down, but the fact that the process is subject to business scrutiny and independent internal review can lead to mature debate about the issues.

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.

Badly.

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.

Break it down with clients as much as possible, tell them how long everything will take (don't worry overestimate just to be safe), then I explain software is not only about writing code so we have to add 20-40% for QA/itterations on top of estimated value.

But the thing is, it's only to estimate, I will never bill based on these estimations, just help to plan the client.

In my experience, providing effective estimates with actual data requires:

- 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

I want to share some things that I noticed over the years of doing estimations for work related to my small side project.

- 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.

I generally believe that stating your hourly rate and providing frequent updates and milestones is a much better practice than giving an up-front project cost.

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.

You need to separate the R & D. The research is unknown and you can't estimate. The development is known, and if you can use prior experience to estimate.

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.

It depends?

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.

In my experience estimates are off more often than not (or I'm really bad at this).

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.

In general, I first try to find out what the solution is worth to the customer. This is not feasible in every case but often it's possible to arrive at a rough estimate as to how much additional revenue a solution could potentially generate (preferably) or how much money it would save the customer. It can also mean trying to find out what the customer's most urgent or painful problems are and what the result of alleviating these problems would be.

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.

We do work on estimate basis. We try to do them the best we can based on our expertise. Even for big projects. These estimates cover analysis, project mgt, testing, ...

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 this is the first time you estimate a set of work, you will not have the experience to provide an accurate value. You may guesstimate, but then you'll have to multiply that value 2-4x to make sure you don't under-bill. Now, that multiplier is key, it's your buffer.

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.

A lot depends on whether you're billing "time and materials" or whether there is going to be an agreed fixed price for the contract. For the second one, you have to have a pretty rigid specification in order to start - a list of all the screens and menus in an application as "wireframes", for example, with a brief description of what they do. Once you have that you can then assign some sort of average time cost to the features to produce a headline price.

This is my approximate proposal and estimation process:

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.

If you need to estimate then it's best to break work up in small parts and then estimate those. Because it's very tricky to estimate huge bulks of work.

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.

I'm a junior software engineer. My role in projects is usually optimizing pipelines for scalability, latency etc (though, I do occasionally implement new features too). I work in languages like python, SQL, C etc. So far in my career absolutely none of my estimations has been accurate. My underestimations/overestimations can vary a few days to a few WEEKS! Sometimes, I do some system analysis, find bottlenecks, develop heuristics to optimize those bottlenecks, implement the optimization but later find out now something else bottlenecks the system in a way it's almost as slow/unscalable or the optimization introduces a non-trivial bug. So it takes another round of analysis and optimization. I don't know if I'm just a trash engineer or estimation really is an extremely hard task.

It is very hard to know exactly what the client wants. Also it is possible the client will change its idea in the middle of the project. You basically use your experience to have an idea of how much will take you to develop the project and then add a safe margin. Where this safe margin usually is multiply per 2 or 3 of your initial estimation. You should also consider how big/complex is the company you are going to work for, the bigger the more difficult is to get what you need from them. So you multiply again per 2 or 3 if the company is big to account for the delays in getting what you need from them and other bureaucracy stuff.

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.

The most reliable estimate is for work you've already done and documented. Fifteen years ago I wrote my own timesheet system where entries can be directly linked to code changes. When I have to estimate I can interrogate this to get comparable (and sometimes identical) tasks from the past.

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.

Within my company, we list tasks and assign a duration and cost to them (could be fixed, hours or days). We use this to generate a quote. Our software of choice is the projects module of https://usebx.com/app (we built this, and it's a glorified to do list, but it really works for us, even on large complicated projects).

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.

The problem with questions about estimation is that often the answers to the question come from a providing estimates to external customers standpoint. Providing estimates to things when you are building for internal use is much more complex as you have to consider politics, competition (internally) and often you have to estimate based on support from other teams who may not have the same priorities as you. Often too you have incomplete information and even incorrect information, your requirements may be sketchy and potentially no one actually knows what is needed or where it will go. That's incredibly difficult to manage and a different problem than providing estimates to a customer.

I use ranged estimates with LiquidPlanner. I send a project plan showing the estimates and expected completion date. If the estimates are wide, I explain that I can make them narrower by spending more (billable) time doing research.

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.

Perhaps it’s a bit cynical, but I believe it’s all nonsense. Anyone put in charge of a software project is going to read some books on managing software if he’s not trash. There, he will learn the pitfalls of estimates and etc. and use them in a way that makes sense. Perhaps it’s again cynical, but my assumption is that if people want something within an overly short time-period, they want a piece of shit that meets the minimum interpretation of requirements, which may be possible in their time period.

Excel for entering all the estimates. I write down tasks, one-offs (eg license purchase) and subscription costs. For the tasks I add columns for different roles, because the rates differ. The fixed costs are also entered. Some tables are made based on this data, and added to a written word document.

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.

In my experience, whatever you think is honest and accurate, triple it. And whatever you think is a fair price, double or triple it.

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.

When I first started in programming over 28 years ago, a wise mentor gave me 2 pieces of advice about estimates:

- 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.

Related question: do you charge by the hour? If so, what's your hourly rate and what software do you use to track your time?

I can't talk about proposals, but for estimation, I recently started using three-point estimation method which I highly recommend: https://en.wikipedia.org/wiki/Three-point_estimation

Googling it comes up with a bunch of calculators to generate time and cost of project, but I don't know how much I'd trust them.. Honestly seems like it comes down mostly to trial and error, and understanding your own process when deciding how long a project might take / cost.

https://uncertain.io/ I wrote this tool for this exact purpose! A horizontal line means you know nothing. A near vertical line means you are damn certain. Theoretically your stance is somewhere in between.

Giving precise estimates is almost always impossible for any project of significance and really doesn't matter much. What value does a very precise estimate give? None, because 1) it's impossible, and 2) even if it wasn't, how do you know if it is accurate?

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 :)

I walk through the requirements document line by line and capture it all using Event Storming. Once I get it granular enough I can give a reality-based guestimate on the hours.

TL;DR: Lock down the scope before providing estimates. Always double your estimate because developers are damagingly optimistic about their ability to get things done.

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.

Poorly and never

purely by experience. been there done that.

you ask for something, I know about how long that will take, and then I double it.

Estimate * (1.25 n)

where n is the number of non-technical people in the room

Badly

badly

test comment sorry