Here's a secret for consultants: the attitude espoused in this blog post is losing you sales.<p>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.<p>Having been on both sides of this exchange, I <i>really, truly</i> 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.
Stop complaining.<p>Figuring out how to artfully discuss price is <i>why you're qualified to run an agency</i> (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.<p>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.<p>It's not that I don't feel their pain. But that's what running a business means.<p>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.<p>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.
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.<p>Real quick:<p>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.<p>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 <i>shrug</i>. The cobbler's children have no shoes sometimes. ;)<p>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 <i>some</i> 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.<p>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.<p>5) "Dear Programmers: Stop Giving Me a Ballpark Lines of Code Estimate" is fucking hilarious and I love you for thinking of it. :)<p>OK, that's all I have time for, gotta run!
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.<p>--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.<p>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 <i>your</i> job as a consultant.
I'll have to (mostly) disagree on this one (although I do think he raises a VERY valid point at the end).<p>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.<p>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).<p>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).<p>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)<p>Edit: I agree with yardie ( <a href="https://news.ycombinator.com/item?id=11741006" rel="nofollow">https://news.ycombinator.com/item?id=11741006</a> ) and napoleond ( <a href="https://news.ycombinator.com/item?id=11740951" rel="nofollow">https://news.ycombinator.com/item?id=11740951</a> )
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.<p>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.<p>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.
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.<p>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.
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.<p>Which, of course, may be true.<p>For now.
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.<p>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.<p>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."<p>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.<p>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".
Completely disagree. Can't put it more plainly than as satire:<p>"Dear Programmers: Stop Giving Me a Ballpark Lines of Code Estimate<p>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.<p>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?"<p>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.<p>At the end of the day, you're the one writing it. Only you know what that number will be.<p>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.)<p>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?<p>Or is there some sense of scale that you can have some kind of understanding of?"<p>According to the author, there is not.
I enjoyed the article, and checked out your site: <a href="http://www.cogeian.com/" rel="nofollow">http://www.cogeian.com/</a><p>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.
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.<p>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.
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.<p>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 $$.<p>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?<p>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?"<p>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"<p>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:<p>"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.<p>But again, not giving ballparks is losing out on a great opportunity for you as a sales person to <i>control the deal progress</i>.
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.<p>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..."<p>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.<p>Cached version of article: <a href="http://webcache.googleusercontent.com/search?q=cache:S23YKe1OWcgJ:www.christopherhawkins.com/2016/05/ballpark-estimate/+&cd=1&hl=en&ct=clnk&gl=uk" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:S23YKe1...</a>
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.<p>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.<p>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.<p>You will thank yourself later that you didn't spend a month working with a disqualified client.
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.<p>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.<p>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.<p>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?
I really despise smarmy sales talk like this. Why am I not surprised this is the consultant's website, apparently still written in ASP: <a href="http://www.cogeian.com/index.asp" rel="nofollow">http://www.cogeian.com/index.asp</a>
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"<p>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.
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...<p>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
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.<p>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.<p>Actually I view articles like that as a part of a broader meta-negotiation.
> and sharing coffee (which I will gladly spring for).<p>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.