
Ask HN: Developers, how do you estimate projects and write proposals? - PawelDecowski
I’m interested to know how fellow software developers (freelancers, small businesses) estimate projects for clients.<p>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?<p>Cheers!
======
mozz100
(about estimating - I don't tend to write proposals) You could have a look at
[https://www.estigator.com](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](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

~~~
ThirdFoundation
Just a heads up, I think there's an error in the description next to the graph
estimating work time.

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?

~~~
mozz100
Thanks again for this. Now fixed.

~~~
ThirdFoundation
No problem, happy to have helped.

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.

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

~~~
williamdclt
> development is an iterative process, and that I generally deliver work as
> soon as it's done

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

~~~
mikekchar
I think the key is that showing progress early and often lets the customer
start to get a feel for how long the entire process is going to take. This is
one of the reasons for XP's idea of trying to do "vertical" but narrow slices
of the application. Each story you work on should work through as many layers
of the application as you can manage.

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.

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

~~~
nostrademons
Rule of thumb: if the estimate is >= 2 weeks, the estimate is worthless.

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

~~~
lukasLansky
Funny, I find measuring opportunity costs much much harder than measuring
engineering effort.

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?

~~~
jwdunne
I think in the first example it's easier to calculate based on the time spent
vs the salary + overheads of the employee(s) dealing with the issue.

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.

~~~
edoceo
As always: [https://xkcd.com/1205/](https://xkcd.com/1205/)

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

------
senseitit
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](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.

~~~
brianpgordon
Paymo looks amazing, and the price point is crazy low. I can't believe I
haven't heard of this before.

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

~~~
senseitit
In fact we do, but more as a diagnosis tool to see how much it took us to
complete a task and how to prioritize it in the future. We're not expected to
account for every minute, that wouldn't be human (and productive) at all.

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

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

~~~
mrfredward
I second this. I have made tons of mistakes estimating, but the fact is that
for all the foolish mistakes I've made--forgetting things, not asking the
right questions, and jumping the gun on making a prediction--I've probably
never had enough information to make a good estimate.

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.

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

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

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

~~~
thijsvandien
How do you take the full payment upfront if you don't know yet how long it
will take? Fixed price? Estimated cost with a settlement afterwards?

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

~~~
melicerte
none of my customers would accept that. They have a budget and your price has
to fit the budget period.

~~~
nathanyukai
Have a hourly rate makes it easier to decide wether to take more project or
not. Especially if the company getting big.

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

~~~
claytonjy
Love the "treat it as a stopwatch" idea; do you do anything specific to convey
that to the customer? Even if you avoid and "end date", I assume they'll infer
it from the start time and duration, and consider that internally.

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.

~~~
segmondy
You have to put a cost to the interruptions. If they can interrupt you for
free then they will. So let's say you agree to a one hour meeting per week,
any extra time must cost extra. At the beginning of every meeting, you
announce that the time will be adjusted due to the meeting.

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.

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

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

~~~
theriddlr
Similar to mine. We vote on the complexity of a task and have a discussion if
people's estimates vary wildly. And a 20% 'extra features not accounted' for
time.

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

------
melicerte
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...](https://medium.com/@gwelr/contingency-explained-to-our-
customers-148f984696d3) (shameless plug here)

Comments welcome !

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

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

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

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

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

~~~
ianmcgowan
It's really hard. And strangely it can be easier to estimate a new project
(that's similar to something you've done before) than optimization or bug fix
projects. Known unknowns vs. unknown unknowns and all that.

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.

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

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

------
osrec
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](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.

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

------
xn
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](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.

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

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

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

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

------
hackathonguy
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?

~~~
PawelDecowski
A mix of both.

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

~~~
ianmcgowan
I found spreadsheets broke down once I started working on multiple projects at
different rates (sometimes with the same client). Freshbooks has been awesome
for me, and saved a whole bunch of headaches around tracking time and
invoices. Totally worth it.

------
wintorez
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](https://en.wikipedia.org/wiki/Three-point_estimation)

~~~
LifeQuestioner
Although, I guess if you hit the 'worst case' scenario, you look stupid?

~~~
xn
If you use a confidence-interval estimates, you can choose how wide to make
the confidence interval. I use 80% confidence intervals because that's what
supported by the project management tool I use. 10% of the time, the project
should take more than the high estimate (and 10%, less than the low estimate).

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

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

------
markhalonen
[https://uncertain.io/](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.

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

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

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

------
salmonfamine
Poorly and never

------
legohead
purely by experience. been there done that.

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

------
overkalix
Estimate * (1.25 __n)

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

------
trainingaccount
Badly

------
lol_jono
badly

~~~
wonderofworld
our ai tool is how we do estimates and automate created a spec
[https://crane.ai/](https://crane.ai/)

