Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Developers, how do you estimate projects and write proposals?
228 points by PawelDecowski on Nov 12, 2018 | hide | past | favorite | 102 comments
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!



(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


> Trouble is, businesses/clients tend to see an estimate as a promise, or a target

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 like the idea and could see myself using this. After trying the tool a bit, I liked it and had some thoughts.

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.


Adding to the list of ideas:

* 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 ;-)


Thank you.

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.


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?


Thanks again for this. Now fixed.


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.


dur, yep - thank you for the catch. You are right: this is the worst kind of typo! Will fix


I used a similar software for quite a while: https://www.getguesstimate.com/

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.


I wrote a similar tool to estigator! It's bare-basic, but aims to solve the same problem: https://uncertain.io/


Excellent - thank you for sharing. I wanted to be able to allow custom probability distributions for the tasks/items in estigator.com - uncertain.io is a great way to capture them


Agreed on the Bob Martin book. For project estimates I have presented estimates this way and I find that executives understand it and it lets me present an estimate and a commitment separately in an understandable way. A summary of his explanation of estimates as probability distributions is here: https://codingjourneyman.com/2014/10/06/the-clean-coder-esti...


Nice tool!

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.


A CSV export of the graph data should be fine too.


The concept behind this is great, especially since this very closely matches how I usually estimate things — lower bound and highest expected bound, currently the user experience is pretty meh since you need to add a line and remove two lines to get additional "between N & M units" lines, but I can totally see myself using it once it matures. Would also recommend to others once it matures.

Do you have a newsletter or something similar to subscribe to for releases?


Totally agree with you about the need to click "+" and then remove two lines you don't want. I was planning a drop-down as you suggest.

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.


I like the idea and I am trying to use it. On MacOS and using Firefox nightly.. if I click into the first time estimate box and hit my delete key... the whole app disappears.


Great tool! One bug: As soon as I remove the last `div.item` the whole `div#root` becomes empty hiding the whole UI but the `nav.navbar` (Chrome 70)


I love bug reports with CSS selectors in them. Thank you! Now fixed


Thank you for creating this! And please finish this, this will be the most prized tool in my arsenal :)

This is exactly like I do things!


Hey, I like estigator! Congrats! I will use it.


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


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


The only right answer. If they cannot accept a diplomatic, reasoned and carefully explained "we can't know, but I'll finish as quickly as I can" answer, then they probably won't be very understandable when things turn out to take longer than expected. Or if they change their mind about what they want and expect you to nonetheless finish on the original schedule because it's just a small change. Politely and gently refusing to provide an estimate for the unknowable, is a good way to avoid working with clients who will be not worth working with anyway.

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 think you can usually say if something will take hours, days, weeks, months or years. Anything more detailed runs into problems.


I find estimating dishonest too. I tell clients that a project becomes late 'one day at a time' and that the higher clarity there is in the objective, the more creative we can be about trying to solve the problem. so there is less work to undertake to reach it.

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


This sounds great. How the hell do you get customers to buy into it though? I often wind up falling into this sort of situation with old customers once they're confident in my work and fairness. But for new customers, how do you tell them "don't worry about how much this will cost or how long it will take"? How do you build that in a contract?


I personally guarantee my work. If they don't like the work, I'll refund their deposit, revert the merge(s), and be on my way. I never bill for work that doesn't satisfy the client.


Don’t some still balk at an open ended contract though? They have budgets etc that limit what they can spend.


This is the best way, especially if you are freelance and might carry some of the risk or a drop dead deadline.

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


I don’t think this should be heretical. I’m pretty sure all the evidence is in favour of your view.


> 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


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.


I really mean done as in "creates any positive change for the customer". Obviously if a file has syntax errors you don't push that to production. I usually do CI/CD really aggressively. Deliver as soon as the PR is approved or equivalent, assuming you have enough assurance in the form of test or qa. I would consider daily to be a little slow for my tastes.


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.


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


Exactly. An estimate is only reliable if you expect to learn nothing during the course of the work. But if we release early and often, we are almost certain to learn things as we go which changes scope.


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.


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?


A lot to respond to, I'll try.

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


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.


As always: https://xkcd.com/1205/


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.


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.


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.


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.


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.


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.


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?


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.


I think upfront is better because you should be charging based on value. So what if something only takes you a few hours. If it generates enormous value for the client then you should capture a percentage of that value regardless of the cost to you. Likewise, if you underestimate then yes you eat the cost but you have a much happier client in the long-term. They don't feel cheated when you tell them it will take X more time, and you don't have to waste your time on time tracking and emails about why something takes 30 minutes.

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.


I disagree; hourly rates are an invitation to get bullied by the customer. I much prefer setting a project cost, and informing client we can negotiate _scope_ but not _cost_. (roughly parroting patio11 here).

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.


Do your clients accept that or is there push back? How do you bring them around to your (I think accurate) viewpoint?


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


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


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.


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.


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.


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.


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.


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


Don’t blame yourself. Estimation is extremely hard.


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?


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


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.


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


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


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


Do you use a tool that supports this methodology or do you calculate it manually?


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


our ai tool is how we do estimates and automate created a spec https://crane.ai/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: