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

Completion estimates may be dishonest but that's how things are done almost everywhere, yes, even shops that use Agile, complete with burn-down charts, stand-ups and sprints. I've seen "Agile" teams that go through all the motions of a modern sw development team BUT STILL have to give the completion date of the whole project! Before the work starts!

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

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

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.

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.