Any decent client understands that you can't give them a fully spec'd estimate before you've even begun the engagement. But they want to understand what the process will be, and yes--that includes what the ticket price might look like.
Having been on both sides of this exchange, I really, truly understand why ballpark estimates are hard. But I also understand that approximately nobody is going to approve an expense without having any idea of how large or small it might be.
The point of a ballpark estimate is to answer the question, "Is this in the ballpark?" Namely, can I afford it? Is it even worth paying you $1,000 for a discovery session if the implementation is going to cost me 10x my budget in any case? Is it worth taking the next meeting with you?
The author is right about anchoring to value, and the author is right that it's impossible to fully-scope a project in a minimal amount of time.
But you're the expert! So the right answer is: "We'd look to get a lot more accurate on cost, and a Discovery Session might be a good way to get you an accurate estimate on the cheap. But to get you a sense of magnitude, similar clients have paid $x-(x+20%) and have seen 10x returns. How does that fit into both your budget and the business case you had in mind?"
That's correct. This makes me sound bitter, but here's how it really works:
They ask for a ballpark estimate, and you quickly throw out a number that's believable but not too high so as to scare them off. This is usually done by a sales person who IM'd a free developer and gave a two or three line summary of what the client is suggesting.
Then there is some back and forth, where they customer adds or removes requirements, and the number changes somewhat accordingly, but really, in the context of sales, not technical challenge. "Oh we wrote X for some other client a while back, we'll throw that in for free."
Then it might get complicated, and you get nervous, and you suggest having the client pay to do a detailed analysis. The customer says no, cause, you know, those ballparks are awesome and free.
You agree on an approximate number and contracts are written up. Because really, the ballpark is the actual estimate. We were fools to think otherwise. But of course there is lots of wiggle room and vagueness written into the contract because you nor the client didn't really want to spend much time fleshing it out.
Customer signs. Contrary to what you might think, you just won! You hooked 'em!
Now, you work on the project, and maybe you hit the ballpark, and maybe you don't. If you don't you go back to the client and say, "Well, you know it was just a ballpark estimate, we had lots of new things come up, and you added this and that, and now it's going to cost more money."
Customer can't argue too much, because they didn't want to pay for a detailed analysis, and they did ask for a ballpark. And now they're already in it for some money, and to bail now would mean losing that investment. So they spend more.
Lather, rinse, repeat until the project is done or the customer is out of money.
Now don't think I don't find this system awful - I do. But that's how it works. You'll never get it to change because it will always involve ignorant sales people and ignorant business owners, and they are playing a social game, not detailing a technical endeavor.
For a real example from ad tech, "We need access to a DMP (Data Management Platform) to learn more about our visitors." "That will be about $5k/month for a license." "That's fine."
Oops, you expected to be able to get what the DMP thinks about each individual customer and do the analytics on your side? That license only lets you take a pool of people, and get back aggregate statistics. Not collect per person data...
You have to communicate orders of magnitude, and keep stressing that you'll work with them to figure out the cheapest thing that makes sense, but costs can jump very, very quickly.
Otherwise I completely agree with your 'right answer' and how you framed it: "You're the expert". An estimate by comparison is no bad thing, and demonstrates experience.
That's key. A small business like his is probably not all over the place, they must be hired for a limited categories of problems. After 12+ years doing it, the author should be able to ballpark something within a set of assumptions that will be confirmed during the discovery phase.
I have seen companies with vastly different price point. There is a huge difference hiring a company that charge $2000/manday vs one that charge $200. ( not to say that you don't get your money worth with the $2000 guys but you don't need the Apple vs Samsung lawyers to represent you against the plumber that fucked up your office kitchen tiles when fixing the sink )
And being both sides of that table at some point, it is always possible to give an estimate.
The difference is that the estimate should be a range.
How tall is the Eiffel Tower? If you didn't know and gave an estimate you might say, 172m is quite high, maybe that's high enough to be the answer without over-shooting.
You could give a range as the answer: Between 100m and 500m tall. It's definitely more than 100m high, for why else would there be lifts, such a wide base, etc, etc... and it's definitely less than 500m, because it certainly doesn't rise half a KM into the sky.
That first estimate... wrong. Wildly wrong, but because it is a fixed and precise number it gives the illusion of accuracy and knowledge on my part where none was applied in coming to the number. As an estimate, the client will be upset.
That second estimate... well now I've Googled and the answer is 300m and so it turns out the estimate was correct.
That's all a client wants... the best and worst case, and when there is a huge variance between the two, what is the basis for that variance? How much of it comes back to the clients as requirements that could be made simpler? How much is the tech choice? The features?
Always give an estimate, just make it a range.
(The reverse is true for, say, salaries. If you tell me you pay $100-$200k/yr for a job, I'm already thinking about how to spend that $200k.)
So your ranges should be within your negotiating contingency (say, 20%).
I am looking for a logarithmic bucket to gauge if the approach is within my boundaries (time/money) as quickly as possible.
The question that a ballpark answers is simply this: can I afford to work with these people?
When I finally took a sales class the most insightful thing that I picked up was to ask the question "is that a lot or a little" because it truly reflects what ballpark estimates are about. There are some people who will be totally at their limit with $1,000 budget and others who won't take you seriously if you say $50,000 because it will be too low.
That's what a ballpark does and it's beneficial for both sides because it essentially allows you both to fail fast and not waste each others time. If you say $10,000 and a client balks at the cost, no amount of invested sales time is going to win you that client and it's not going to be worth it to you anyway. They either can't afford what they want or they need an off the shelf solution.
If you say $10,000-$20,000 and the conversation continues then you're good to continue.
This is all very reasonable and we are happy.
Communicate, be reasonable, and people will generally understand.
Large projects need the discovery/consultation process to help arrive at the estimate so that at least there are defined parameters and resources committed to each one.
But this isn't asking about fundamental physics or the development of a new operating system or something. There are unknowns and more importantly there is tailoring to the clients needs and budget, but the unknown unknowns should be minimal, that's why they're interested in hiring you. There is a big difference between the author's "well $10k vs $50k and what about ROI" versus "What you just asked for sounds like what $MEGACORP started two years ago with an initial budget of $12 million and last I heard it is now up to $30 million". Most development jobs do have a range of budgets they can be tailored to but that range isn't infinite; some requests are just clearly going to be flat out impossible for a given business and they shouldn't have to spend any capital, economic or human, chasing a total dead end.
I also think the author very much overstates software being some inherently different, special thing. He wrote:
"you’re asking me to figure out what it will cost to build something that, by definition, has never existed before."
Edit: Tried to use typical asterisk as multiply symbol, forgot that added emphasis.
If someone asks for a basic 3-page site I can ballpark it to $500. Most likely it will be less, sometimes it will be higher. If they ask for an iOS app I can ballpark and say $5000. If it's $1000 we're in the ballpark. $10000 and we're still in the park.
On the flip side, an order of magnitude may be too much. Your example ballpark for an iOS app, to me at least is easily already off by an order of magnitude. The _minimum_ I could reasonable expect an iOS app to cost would be $50k, and if we're shooting for an order of magnitude, I'd have to say $500k, which could be $50k on the low end or $5m on the high end. That's a pretty huge range of prices. Almost not even worth giving a ballpark at that point.
"$500 if it's just a 3-page site, but if you expect a large number of visitors, it can easily jump to $10,000 to $50,000 when all is said and done. Sounds like you have an interesting project with lots of variables. Let's talk more."
I think we can all agree the floor to make an app is fairly low. Most are simple webviews that point to a single URL.
Here's some free, hopefully constructive advice. Your site does not look professional. It looks like something I'd expect a welding company to have in the early 2000's. I'd highly recommend redoing it with a more modern design, especially if you're trying to get potential clients through it.
Constructive criticism points out what's good about something and how it can be improved. It's specific and provides actionable guidance.
1) The site would benefit by leading the eye in a more controlled manner. Right now there are at least two groups of three or more columns so it's hard to know where to look. Take a look at brick wall designs such as Twitter Bootstrap. Lead from general at the top to more specific, detailed information as you go down the page. Imaging the page as a tree diagram.
2) Make the site "say more" by reducing content. Right now there are at least two places on the page that talk about what you do, who you are, and what you're about. Combine those to be more succinct.
3) The color scheme is changing to match the client you're highlighting and that's kind of cool. It's also kind of cool how you show a different client each page visit. But I think a slider would do a better job there. Do you expect more than one visit to evaluate your business? Probably not. Plus a slider that has controls to move back and forth makes the page interactive, fun, and space-efficient.
4) It's okay that all the content is "above the fold" but do you think links to case studies are the best use of that space? Why not use it instead to guide clients immediately through your specific development process in simple terms, show them how easy it is to work with you, and show how you're different from competitors? Then you can give them a link to case studies to show that you practice as you preach.
5) "Cogeian Systems is a small team of custom software and web design experts." I'd be careful about your grammar. You're a small team of custom software? Oh wait, and web design experts. You could change that around a bit to be more clear and active, "Cogeian Systems' experts create custom software and web designs that meet your needs, affordably and on-time." Now your verbs are active, you're saying you have a team of experts, you say what kind of experts they are, and you share what the benefits are of having experts do the work (ie you save time and money).
I was hoping this would at least raise the question in his mind that maybe his site doesn't look that modern or professional. I've met a lot of business owners who are great at their business but not knowledgeable about web sites, and end up paying for a subpar product and not knowing it's low quality.
The author is very vague on how the conversation with the "business owner" goes, and I agree that giving an anchor point is very, very dangerous, but as someone who has been on both sides of the table, you CAN and SHOULD give an order-of-magnitude estimate with several very clear caveats.
And I disagree that asking for a ballpark estimate translates to "So, can you guess exactly what’s required... (etc.)". It's the opposite of that, it's can you ROUGHLY (not "exactly") guess (yes, you do have to guess, that's what estimates are, guesses).
I agree that only the people actually building can give a "real estimate".. but you can give a "ballpark estimate" (which I translate to order-of-magnitude estimate).
The one valuable point from the article is "You’re focused on the wrong thing.". Yes, you should help the business owner focus on the ROI. But you can tell him whether it's a job for a $ 1.000 static website, a $ 10.000 web app, a $ 100.000 system with web, mobile and whatever, or a $1.000.000 ERP or whatever. (or outline to him the options)
Edit: I agree with yardie ( https://news.ycombinator.com/item?id=11741006 ) and napoleond ( https://news.ycombinator.com/item?id=11740951 )
"Based on our discussions so far, a basic web application would fit your requirements. We typically build those with a budget of tens-of-thousands."
(OK, maybe with less awkward delivery, but you get the point.)
OTOH, the business owner probably already has a (possibly inaccurate, and that may need correcting) idea of the value they expect to receive -- otherwise they wouldn't be talking to you at all. When they are asking for an estimate of the cost to realize that value, they are filling in the bit they need to have a picture of the ROI.
Figuring out how to artfully discuss price is why you're qualified to run an agency (including the world's smallest agency) in the first place. If you can't do it without getting annoyed at the client go work hourly or for a salary. That's an option too.
I'm always amused by people who think running a service based business would be easy, if it wasn't for all the damm paperwork, dealing with taxes, employees/partners who flake out or need babysitting, clients who are hard to please, and collections issues.
It's not that I don't feel their pain. But that's what running a business means.
His main insight here is insisting on a paid estimate. Sure, that's an option if your reputation is strong enough to be able to stay busy in spite of it, but it's hardly a novel idea.
Ask any auto diagnostics mechanic. Who, by the way, will still be able to give you some kind of best/worst case scenario and ballpark range verbally. It's not actually that hard.
One of the author's points, and one with which I agree, is that it's significantly harder to estimate software projects than, e.g. repairing an automobile.
That said, are there entrepreneurial fields you know of which mitigate the cycle described above resulting in less headache?
"Dear Programmers: Stop Giving Me a Ballpark Lines of Code Estimate
Once a programmer and I are past finalizing requirements and have selected a stack (or they are contributing to an existing project) I need to know exactly how many lines of code they will be writing for the functionality. I need this for my accounting requirements.
Stop giving me ballpark estimates like "a few hundred" or "thousands" or "well, it depends on whether I can use an external module, can I get back to you?"
That is unacceptable. Once we have agreed on requirements, I will be paying for your "discovery session" where you must sit down and discover exactly how many lines of code you will be writing.
At the end of the day, you're the one writing it. Only you know what that number will be.
I require an exact number of lines of code that I will be paying for. 7,428 lines of code is not the same as 9,416 lines of code. The difference between 7,428 and 9,416 is the same as the difference 3 and 1988. Likewise, the difference between 76 and 7,428 or between 7,428 and 14780, or between 458,583 and 465,935 LOC are exactly the same. (in each case it's a difference of 7352.)
If you expect me to pay you to discover my requirements, do you expect me to be able to pay you to discover your requirements?
Or is there some sense of scale that you can have some kind of understanding of?"
According to the author, there is not.
--I am an internal IT and Development Manager. I work with internal clients everyday who do not know what they are asking for is a simple content change, or a major architectural rethink. My internal clients need some help with the /business analysis/ of what they are asking for is a sensible thing. They do not know if a series of pages only accessible to their external client is something simple for us to achieve, or something that will take a decade. They really don't. Their job is to drive things forward for their clients, and my job is to look at what all their requests look like across our company and push forward the things that will help everyone.
Your job as a consultancy is to help us clients determine what is low hanging fruit and what is not. You might have something easy to ship as a client data access system, and it would take you 10 days or 10 weeks. Or it might take you 10 months. Or it might take you 10 years. The company I work for for could probably do A, B, or C, but definitely not D. If it is D, then how can we simplify the requirement? That is your job as a consultant.
A necessary component of a good client-consultant relationship is mutual trust and respect. If the client is well-intentioned but ignorant, then there is a much nicer way of educating them, on the other hand if the client is stubborn and arrogant then you don't want to work with them anyway. On the flip side, you should respect your client's expertise, not pretend like running a consultancy is the same as running other types of business.
I understand the emotional appeal of writing a screed like this, I've worked with my fair sure of clueless and bull-headed clients (eg. many realtors during 2006-2007 bubble), but if you are as good as you think you are you can't let yourself get dragged into this embittered attitude as it will turn off potentially good clients as well.
Which, of course, may be true.
For now.
For fixed, static products or existing and relatively simple services? I absolutely agree that a clear pricing model is a reasonable expectation.
If it doesn't, I offer up ways to make the project fall inside of it, or what parts of the project are so risky that, while in theory they might fall within, they might also blow up the budget.
Clients want ballparks because they need to know if pursuing a given project is worth their time. No one wants to spend hours putting together a project summary and working on detailed specs only to find is 2X or 3X more money than they have.
And the same is true for the agency. Why am I going to waste productive hours spec'ing something there's no way I'm going to actually book as work?
While $1000 might be a little high, I think charging for that period of time where requirements are really chiseled out is the fix here... Then you can return after one of those meetings after doing some investigation with a hopefully somewhat reasonable estimate
The point is to give your client more data and an off-ramp, and works well for frank discussions (and ghosting your competitors):
"As you know, websites can be $1k or $1M. Based on this, I think you're in the $100k range. But until we get down into the details of exactly what you want to do, it's hard to say for sure, right? So I could do what a lot of firms do and bid $100k: if I'm high, I keep the difference. If I'm low, I surprise you with a change order. That's not how I do business. So if we're in the same range, let's start slow, figure out exactly what you want to do, not lock you into some giant contract with me, and give you better data to move forward with confidence."
Real quick:
1) Bear in mind that nowhere in the article do I _refuse_ to give ballpark estimates; I'm simply pointing out the downsides and offering a potential solution.
2) I know my site is horrible, and I knew that YOU would know my site is horrible! The new one is under development and should ship in another week or two, but shrug. The cobbler's children have no shoes sometimes. ;)
3) You folks who are suggesting order-of-magnitude estimates are _spot-on_, and this is more-or-less what I've learned to do over the years when giving some kind of an answer is critical to maintaining the life of a potential deal. _Sometimes_ the order-of-magnitude thing can backfire, though, particularly when the client is thinking in "cost" mode rather than "return on investment" mode.
4) Pointing out the downside of a thing and offering a better alternative does not constitute "complaining" insofar as I understand the term; rather, I think of it as problem-solving.
5) "Dear Programmers: Stop Giving Me a Ballpark Lines of Code Estimate" is fucking hilarious and I love you for thinking of it. :)
OK, that's all I have time for, gotta run!
If a client simply says, "how much to build cool stuff?" I cant answer because I have no idea what they mean by "cool stuff". In order to help them they have to give me more details of what they want. Which in some ways is a warning sign to me about the client, if they don't really know what they want it already makes me question if I even want them as a client. Them knowing what they want directly relates to my ability to tell if I can make them happy.
My approach is "well before we get to ballpark let me know some more information about what you are looking for so I can make sure I get this as close as possible."
I call this hand holding, you hold their hand and you walk em through it if you think they are worth it, or you cut em off early and don't waste your time. I learned a long time ago some clients are not worth it.
Also I wouldn't make a post with this sort of tone and tie it directly to yourself, I know exactly what you mean but to others it may come off in a "negative" light. A potential customer can read this and think well I like ballparks and don't want to get lectured about it so forget this guy. I would take more of the positive approach and frame it as "Dear client let me help you get a better ballpark figure".
If you are too shy to share how much you generally charge for your service, it means its going to be a big number, and there are fat sales margins in what you are selling. I'll pass.
My typical way of doing this is the same way I also give estimates of time or effort in software development: IF X is true, and IF y is constrained by z, then typically a project like this will be between $and $$.
Think of it as a qualification gate - before you're going to go through the time to scope out a project fully, does this person have the ability to make something at that price point happen?
Even more to the point, after you give them the ballpark, you should say, "if this project comes in somewhere in that general range, do you have the authority to sign off on this amount of money?"
Now you've not only potentially saved yourself some time, you've learned whether you're dealing with the decision maker here, or as some refer to it the "economic buyer"
Now, it's true, someone might say, "I want to build a social network for Journey fans that includes a live concert recording site", and yeah, that's too vague to scope something. But in those cases you scope it out as much as possible: "do you need chat? Is it mostly for sharing pictures? Is there a buy/sell aspect?", and then you put a floor on it:
"Well, we really need to spend a lot more time on this, but I would say something like this starts at X and goes up from there", where X is a large dollar value that you feel is 50% more than it would take to do the basic version of what they want.
But again, not giving ballparks is losing out on a great opportunity for you as a sales person to control the deal progress.
Besides, anyone can easily work out a ball park figure: "I charge X per day. This project sounds like it is in the scale of multiple days/weeks/months. Therefore it will be in this rough range..."
This is pretty much how I respond to all business enquiries (I'm a freelance UX consultant). It cuts out a lot of time wasting.
Cached version of article: http://webcache.googleusercontent.com/search?q=cache:S23YKe1...
Here's the thing though. If you've been doing this for long enough, you already know how much your business WANTS it to cost. Are you the kind of contractor who typically does $100k deals? Then you're not going to take a $2k project. And your client should know that.
All they need to know is, will it cost $5k, $50k, or $500k? And be honest, you know what kind of budgets you need to build products if you've been doing this for long enough. If your projects range from "$50k to $300k", just say that, and it will move the conversation right along.
You will thank yourself later that you didn't spend a month working with a disqualified client.
You are under the mistaken impression that as a software developer you are the only one in a this conversation that knows how much money a a particular task is worth automating. Here's a hint - not only do I know what it's worth to my business, but you probably don't. If you can't tell me if a job is in (a fairly wide) range of viability, then you're not likely to be a good partner for my business.
As a consultant you sometimes want them to do it too. For any sufficiently complex project the contractee doesn't have perfect knowledge of what they want either.
Actually I view articles like that as a part of a broader meta-negotiation.
No. If the discovery session is $1000, I'm paying for that coffee. That cheeky attitude is why you are having issues with this and felt the need to blog about it.