
Dear Client: Stop Asking for a Ballpark Estimate - chris_hawk
http://www.christopherhawkins.com/2016/05/ballpark-estimate/
======
napoleond
Here's a secret for consultants: the attitude espoused in this blog post is
losing you sales.

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.

~~~
basseq
This.

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

~~~
redleggedfrog
>> Here's a secret for consultants: the attitude espoused in this blog post is
losing you sales. <<

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.

~~~
jrs235
Correct. And charging a "small" amount to gather requirements is a quick and
easy way for the consultant to determine if the potential customer is a good
fit. A customer that understand that spec work takes time and resources and is
willing to pay for the work is also a potential client that will, when they
make change requests or feature/scope creep, understand that they should/will
be paying for those on top of what the spec says. Everyone is correct that the
author is losing business by working the way he does... but he's okay with
that because he's cares more about client/customer fit (and quality) than work
volume.

------
CPLX
Stop complaining.

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.

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

------
chris_hawk
I love you guys so hard right now. Great comments, lots of good points that
are clearly informed by plenty of client-project experience, and even a couple
of things I didn't think to consider.

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!

------
hackbinary
Dear IT Consultancy Principle, you just do not get it. I am a business person,
and yes, I do need a ballpark estimate. I do not know what I am asking for is
10 minutes of work or 10 years. Please help me narrow down my expectations. Is
it 10 days, or 10 weeks, or 10 months? I really do not know. Your company has
done some good work for me and I trust your judgement. Please give me a very
estimate of what I am asking for is reasonably achievable. If yes, then
awesome, let us proceed to the next stage. If no, then please help whittle
down my request into something more simple, and easily achievable.

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

~~~
Mendenhall
I think this post has some very good concepts and points that were not touched
on much. I feel like I could do business with you lol

------
GFischer
I'll have to (mostly) disagree on this one (although I do think he raises a
VERY valid point at the end).

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](https://news.ycombinator.com/item?id=11741006)
) and napoleond (
[https://news.ycombinator.com/item?id=11740951](https://news.ycombinator.com/item?id=11740951)
)

~~~
jdmichal
I wonder if there's value in simply answering with an order of magnitude...

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

~~~
TeMPOraL
I think it's pretty valuable. After hearing such an estimate, the client may
think "oh, it might stress the budget a bit; I'll need to double-check with my
boss". Or, "what? I thought it will cost like $100!". Both are valuable
conclusions.

------
dasil003
The problem with this article is not any of the facts or reasoning which is
all very spot on. The problem is the tone. From the very opening of the title
"Dear Client" it's hard not to read this in a sneering, condescending tone. At
best, it preaches to the choir, and will never be discovered by the people who
need it most.

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.

~~~
hackbinary
Yes, this. As a "good" client, please help me get a sense of the spend that I
will need to budget for, and the time it will take. That is what I am asking
for by a "ballpark". This idea maybe totally simple, or able to do with some
effort, or very difficult with concerted effort. Please give me a 'rough'
estimate. From there we can formulate a more concrete action plan. Maybe that
is some consultancy time, or maybe I have to drop this idea. I get that a
$1000 or £1000 will help focus the clients mind on whether this is a worth
while venture, but please just keep it simple.

------
yardie
Thats not a ballpark figure thats an estimate. A ballpark figure should be
within magnitude. That way the client can decide if they want to pursue the
project at all. It's just a spread so someone that doesn't have any knowledge
has realistic figures to work with.

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.

~~~
lojack
The problem is, frequently even an order of magnitude isn't even enough. For
instance, a high profile 3 page site that has a large number of daily visitors
(or a product launch). Since the cost of getting something wrong on this may
be so high, you need to get things right. This involves numerous rounds of
usability testing, often multiple different comps, load testing, etc. It's
totally reasonable for the budget of a 3 page site to cost upwards of $50k.

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.

~~~
jasonlotito
> The problem is, frequently even an order of magnitude isn't even enough.

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

------
CamperBob2
Companies that refuse to publish or even respond to quick, direct questions
about pricing fail to understand something very important: whatever they are
selling is only a part of whatever I'm working on, and is almost certainly not
the linchpin of the project. I may have a dozen more vendors to talk to that
week, and I literally cannot afford to waste time schmoozing with sales
droids, waiting for calls or emails to be returned, or establishing a
"relationship." Making me jump through hoops just to understand the pricing
model is basically their way of telling me I'm not worth their time.

Which, of course, may be true.

For now.

~~~
aeorgnoieang
I think you're referring to very different products or services than custom
software development. Or would you be satisfied with "$200 per hour billed"?

For fixed, static products or existing and relatively simple services? I
absolutely agree that a clear pricing model is a reasonable expectation.

------
Mendenhall
It appears to me much of the problem written about in this article is the
client not knowing what they wanted from the start and explaining it.

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

------
logicallee
Completely disagree. Can't put it more plainly than as satire:

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

~~~
aeorgnoieang
I don't get your point. You're satirizing someone caring about the cost of a
project by comparing it to someone caring about the number of lines of code
written?

~~~
logicallee
Yes. I disagree with paying to find out the ballpark, and compare it to paying
to figure out the number of lines of code without writing them. It's not a
good way to do business. I don't think the author's idea is viable and I agree
with the other poster who said that the author was probably losing business as
a result.

------
kdamken
I enjoyed the article, and checked out your site:
[http://www.cogeian.com/](http://www.cogeian.com/)

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.

~~~
VrtualTrapezoid
So here's some constructive criticism for your constructive criticism. Your
heart is in the right place but unfortunately your criticism isn't that
constructive. Just saying "Your thing you think looks good actually looks bad.
Fix it." is really more of a soft-pitch put-down.

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

~~~
kdamken
Hey - thank you for posting all of this. While I have an eye for design, I'm
not a UX or web designer so I don't usually have a ton of specific feedback
other than knowing something doesn't look as good as other sites I work on.

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.

------
solaarphunk
I run budgeting for a reasonably large startup and ballparks are an easy way
to understand if the ballpark of a consultant or SAAS software's costs is
somewhat proportional to the pain point we are trying to solve.

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.

------
mattzito
I think this article, while correct, really misses the boat on why offering
ranges is so important. In a lot of cases, the wide-eyes dreamer client is the
person who needs the most guidance on what something will cost.

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

------
harrybr
The author has the tone of a consultant but gives the scenario of "If I charge
you $10,000 to build a web app". On a budget of 10k to design and implement an
entire webapp there is no money spare for a consultant.

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...](http://webcache.googleusercontent.com/search?q=cache:S23YKe1OWcgJ:www.christopherhawkins.com/2016/05/ballpark-
estimate/+&cd=1&hl=en&ct=clnk&gl=uk)

------
aclimatt
I've been running a consultancy for quite some time, and I see where the
author is coming from. We used to do things like that, and still insist on
paid discovery sessions before giving actual quotes.

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.

------
etchalon
What I usually do is reverse the question. Since it's often times, very, very
hard to ballpark things, I ask them what THEIR budget range is, and then let
them know if what they're asking for falls inside of it.

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?

~~~
paublyrne
If you're a good an scrupulous contractor, you'll also be able to be able to
tell them how much app you can build for them for the money they have
available, which is completely valid for a client who needs something but has
only a small budget. Often scope is negotiable, but your expertise will be
important in helping define the scope.

------
themgt
I really despise smarmy sales talk like this. Why am I not surprised this is
the consultant's website, apparently still written in ASP:
[http://www.cogeian.com/index.asp](http://www.cogeian.com/index.asp)

------
djrogers
FTA: "If I charge you $10,000 to build a web app that saves or generate
$50,000 of revenue, that project effectively cost you $0. But when you ask
about cost up front, any answer I give you will just boil down to whether or
not you feel like spending $10,000 today"

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.

------
hardwaresofton
The discovery session proposed seems to be just the thing to fill the gulf
between what clients want (a reasonable ballpark estimate) and what the
consultant is comfortable supplying...

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

~~~
basseq
Depending on your business and your services, $1,000 might be insanely low.
(That's like 4-5 hours at a reasonable consulting rate... can you build out
functional requirements in that time?)

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

------
auganov
It's part of the implicit negotiation to me. You get the other side to soft-
commit to a given price range. A perfectly valid strategy. Not to say it can't
backfire in a multitude of ways.

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.

------
jasonlotito
> and sharing coffee (which I will gladly spring for).

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.

