Dear Client: Stop Asking for a Ballpark Estimate(christopherhawkins.com)
christopherhawkins.com
Dear Client: Stop Asking for a Ballpark Estimate
http://www.christopherhawkins.com/2016/05/ballpark-estimate/
22 comments
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?"
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?"
A good analogy might be one's expectations heading into a meeting with a lawyer. You'd want to know whether this will cost $3,000 or $30,000 and would rather not pay the $500 fee for the initial consultation to find out.
>> 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.
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.
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.
That conversation will hang you. Because now $x is the figure in their head, and being off by a factor of 2 will kill you. But a single unclear assumption can be an order of magnitude price difference.
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.
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.
A good idea here is to deliver some tangible value to the client (something more than simply a better view of cost) after the discovery session. A roadmap, prioritized use cases, conceptual designs, or whatever makes sense for any given situation. You can charge more for the session that way too.
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.
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.
From the article:
At the end of project discovery, you’ll find that 3 exciting things will happen:
1. Now you’re allowed to ask how much the project will cost! You thought I had forgotten about that, didn’t you? It’s OK – I know you’ve been dying to know when you can ask, and the answer is, “now”. And the best part is, I’ll be able to give you a real answer, not a ballpark estimate.
2. You’ll have a more in-depth understanding of your project. From pros & cons to potential profitability, you’ll have a newfound sense of x-ray vision for how your business is currently operating vs. how the new project will enable it to operate. You’ll have a rock-solid grasp of why you want to do this project and what you’ll get from it.
3. I will hand you a complete project plan. This project plan covers all the particulars we uncovered during discovery; this plan is yours, bought and paid for. If you want, you can use this plan to execute the project yourself, or even shop the plan to other consultants for an estimate.
At the end of project discovery, you’ll find that 3 exciting things will happen:
1. Now you’re allowed to ask how much the project will cost! You thought I had forgotten about that, didn’t you? It’s OK – I know you’ve been dying to know when you can ask, and the answer is, “now”. And the best part is, I’ll be able to give you a real answer, not a ballpark estimate.
2. You’ll have a more in-depth understanding of your project. From pros & cons to potential profitability, you’ll have a newfound sense of x-ray vision for how your business is currently operating vs. how the new project will enable it to operate. You’ll have a rock-solid grasp of why you want to do this project and what you’ll get from it.
3. I will hand you a complete project plan. This project plan covers all the particulars we uncovered during discovery; this plan is yours, bought and paid for. If you want, you can use this plan to execute the project yourself, or even shop the plan to other consultants for an estimate.
> similar clients have paid $x-(x+20%)
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 )
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 by the way, the slippery slope of this [warning: logical fallacy] is the argument, "I can't tell you what it's going to take until I've already done it. 100% accuracy!"
Definitely.
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.
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 only problem with ranges is anchoring, particularly with dollars and cents. If I tell you it will be $1-10M, you're going to anchor on $1M (and be pissed when I come in at $8M).
(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%).
(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%).
When I give ranges, I explain what each end of the range looks like.
$1m - we're only doing x, y and z, within these basic constraints, the scope does not slip without renegotiation.
$10m - you get m-through-z, we'll build in capacity for scope changes and discovery on the way
We should be lowest quartile ($1m-$3m) of that range if we can agree through a discovery phase what is in scope and basic constraints/assumptions.
$1m - we're only doing x, y and z, within these basic constraints, the scope does not slip without renegotiation.
$10m - you get m-through-z, we'll build in capacity for scope changes and discovery on the way
We should be lowest quartile ($1m-$3m) of that range if we can agree through a discovery phase what is in scope and basic constraints/assumptions.
Giving the top and middle estimates would be an easy solution. Never give out the lower estimate.
As someone looking for a ballpark estimate, be it money or time, I'm generally looking in factors of 10x. Is this 1k, 10k, 100k, 1mil, etc or on time, is this 1month, 6month, 1 year, 2year, etc.
I am looking for a logarithmic bucket to gauge if the approach is within my boundaries (time/money) as quickly as possible.
I am looking for a logarithmic bucket to gauge if the approach is within my boundaries (time/money) as quickly as possible.
This is what I have found quite usable approach. When the sales person has been explaining for some time how difficult it is to estimete the price, I simply ask how many zeroes he thinks the budget is going to have. This more often than not results to answer like "oh, I would think it is between 60k and 80k. It seems that most salespeople are not able to sense the difference between asking for indicative quote and trying to figure out orders of magnitudes in costs.
Yep. A common question I'll ask a mechanic is like: My car is making this funny noise when it frobulates. Is that likely hundreds or thousands?
Exactly. There's a reason it's called a ballpark and that's because people are expecting it to be unreliable.
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.
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.
In fact, just the other day I got a ball park estimate for a web dev project. We agreed on a discovery rate and a ballpark figure. And there is an asterisk next to it that later is explained to say that the price is subject to change based on the discovery work.
This is all very reasonable and we are happy.
Communicate, be reasonable, and people will generally understand.
This is all very reasonable and we are happy.
Communicate, be reasonable, and people will generally understand.
I agree on the attitude. Further in his article, he gets to the meat: the discovery process. (If you didn't get that far down in the text)
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.
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.
You can always iterate on the estimate. On first meeting, you can say, "it tends to cost anywhere between $10k and $10M, depending on things like X, Y and Z; after a discovery meeting we will be able to give you a more precise estimate for the costs in your case".
Exactly. Part of the cost of doing business is seeking out new business, and partially failing at securing that new business. As the professional, the onus is on you to guide the client through the process of figuring out how to begin, how to budget, how to move forward from the initial steps.
[deleted]
[deleted]
Came here to post this, well said (along with all the others so far). While the post does raise some valid points about ROI being a key consideration, that doesn't change that for most businesses initial capital expenditure is still a very significant consideration. As you say, the fundamental point of a ballpark basically is "so around how many zeros?" It's very easy for a client who honestly has minimal idea of underlying foundations behind every day services or tools to ask for something that genuinely seems simple to them on the surface but is insanely complex, even if they're not in starry-eyed dream mode (or inspired by a ludicrously overoptimistic simplified trade magazine article they read). An experienced contractor should be able to at least say "other clients similar to you have been in ranges from $N to $10xN". It's worth emphasizing that there can be significant ability to scale up or down by an order of magnitude in response to ROI, expected scaling requirements, etc.
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:
Edit: Tried to use typical asterisk as multiply symbol, forgot that added emphasis.
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.
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.
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.
> 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.
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.
Your third line of "I'm always amused.." has me questioning whether I truly want to relaunch my side consulting just because design is a skill set. Where I'd land instead is incubating CPG/D2C ideas. Although, that basically replaces "clients hard to please" with "consumers who don't always know what they want" -- isn't that why we do any of this? Business is a sport that requires higher risk capacity than most who just exist and we have obvious rewards of doing so.
That said, are there entrepreneurial fields you know of which mitigate the cycle described above resulting in less headache?
That said, are there entrepreneurial fields you know of which mitigate the cycle described above resulting in less headache?
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!
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!
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.
--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.
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
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 ) and napoleond ( https://news.ycombinator.com/item?id=11740951 )
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 )
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.)
"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.)
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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."
"$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."
With one bit of information ("I want to have an iOS app") you probably can't give a reasonable estimate. But you always have more information. Be it because the prospect already told you what kind of app they want, or just because they know what kind of apps you make - the very fact they're in your office provides additional information.
Those are all simple examples. If someone wants a CRUD app thats different than a ride sharing app which is different from a messaging app.
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.
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.
Well, there is a spectrum. If you're talking shitty, basic MVP, you could do that in $10K.
"How many zeroes are we talking here?"
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.
Which, of course, may be true.
For now.
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.
For fixed, static products or existing and relatively simple services? I absolutely agree that a clear pricing model is a reasonable expectation.
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".
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".
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.
"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 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?
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.
I enjoyed the article, and checked out your site: 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.
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.
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).
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).
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.
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.
Just wanted to say very good feedback. This is the exact type of post that makes me enjoy hacker news and helps me grow as someone who designs UI UX etc. I am not OP but always appreciate learning.
Not responsive, either. The irony being that very few people will be looking for a consultant on their phone, but your site is absolutely vital in conveying what you think about when making a site for a client.
The antiquated design is really inexcusable for a company that markets itself as "web development experts".
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.
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.
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.
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.
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...
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...
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.
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.
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?
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?
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.
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
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.
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...
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
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
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."
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."
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.
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.
> 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.
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.
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.