Ever since I’ve gone into business for myself, software project estimation has been one of those skills that I feel as if I’m constantly refining.
Sure, I have a process for how I go about doing it now, and I have open conversations with potential customers as I try to understand their core business need before I go off to estimate the project, but the truth of the matter – and anyone who’s ever estimated a project knows this – is that estimating a project is also a function of how well the customer understands their current problem.
By that, I simply mean that if a customer has a felt need and they have a vision for how their process can be improved, it’s easier to come up with an estimation for a project than for a customer who has a felt need but a vague idea as to how it may be solved.
There’s a lot that can be written on this topic, but I’m primarily concerned with just one aspect of estimation in this post: should estimates be free or paid?
The Luxury (Or Lack Thereof) in Software Project Estimation
A Tale of Two Developers
Well, if developers were cities…
One of the luxuries of a salaried job is that when a project comes down the pipeline to the team, the odds that the project has been priced is relatively high.
This doesn’t necessarily mean the project has been scoped, but the company has already worked out a price for the project, the developers will likely scope the various milestones, and then will aim to deliver the solution on time.
This works differently depend on the context, though:
- Salaried jobs will often remove the burden in pricing projects, but a developer’s salary isn’t likely to change based on the project
- In self-employment, the time for pricing a project is absorbed by the contractor, the payment will vary, but the project may not be accepted
Don’t misread me: This isn’t a post about salaried jobs versus self-employment. Simply put: There’s a difference in how projects end up on each developer’s desk.
Should Estimates Be Free?
It’s Free…?!
And this is the crux of this post: If you’re self-employed or manage a small team of developers, should project estimates be free?
As I mentioned before, software project estimation is one process that I’m constantly refining with each project that arrives. Sure, the more projects you work, the more likely it is that you are to see similar projects, but the point remains the same.
The majority of the time, I’m happy to provide estimates and, honestly, I think estimates should be free. After all, if the shoe was on the other foot, I’d find myself hard pressed to want to pay for an estimate for a contractor or a team that with which I may not ultimately work.
But there is a dark side to software project estimation and that’s that potential customers can take advantage of the situation. For example, a customer may come with a lead on a project and then ask you to provide an estimate.
Their motivation could be simply to get:
- An idea as to how much something like this should cost
- An idea as to what all they’ll get while working with you
- Or they may be using you to keep someone else honest
After all, you never know who else is estimating the project (nor should you really worry about it).
All that to say, when you provide an estimate for a potential customer, there’s no guarantee that you’ll be offered the job, but there are also other motivations in place that could be simply taking advantage of your time which ultimately results in costing you money.
So my question to those of you who are more experienced in simply this: Should software project estimation be free or should it be paid? And depending on where you fall, why?
There are good arguments on both sides of this discussion. We have generally been in the “estimates are free” category, although we have refused to estimate large projects without a more detailed (and paid) “project planning” phase. This works well for larger ongoing projects, especially if they are in an agile environment.
I think it really depends on two things 1- what the competition is doing. It is a lot easier to charge for an estimate if you aren’t in a hotly contested bidding war. 2- if the scope is poorly defined. If they can’t clearly define what they need, you have to do it for them or else the project will never be a success. This requires your expertise, and should be billable.
Agreed. This is why I end up teetering back and forth on some of the points that I made above and why I ultimately decided to post about it.
I’m just curious as to how the rest of you guys manage this particular issue.
Yep. 100% behind this.
I also think you’re right in that it depend son what the competition is doing. The challenge in doing that is that you could be asked to do an estimate as a way to provide a benchmark to make sure other developers aren’t coming up with fuzzy numbers in which you’re basically just used for a customer to use someone less experienced for lower cash.
Sure, it’s their prerogative, but when you can detect that that’s happening, it kinda sucks.
Let me start by saying in MOST cases, estimates should be free, it helps build rapport, and as you mentioned it allows the client to understand what they are potentially getting. However, Garrett is mentioned a key piece of information. Clarity and Scope. If someone asks for a text change on their site or someone asks for a rewrite of a classic asp site migrated to java, estimates are vastly different. I have a general rule of thumb, if I know the task takes lest than a month, the estimate is free. If I THINK or DO NOT KNOW, how long the task will take, I let them know that I will need to bill for the investigation and analysis of the project to give the estimate. There is a third scenario, if the task takes less than an hour, I often do it for free in front of them so they can see how to do it themselves in the future, how willing I am to help, and generally will have repeat business because of it. Just my 2 cents (for free). :-)
Oh, definitely. Even then, it’s hard to explain exactly the amount of work entails unless the user customer is technically experienced.
I think this goes back to the rapport that you mention earlier in basically you’re being upfront and honest with them about the fact that you don’t know what you don’t know.
I know some people hate saying that, but I’ve typically found that if you can couple that statement with explaining why you need to spend longer (in plain English, not jargon), it helps build trust.
For your small mom and pop website it’s easy to give out those estimates and they should be free. Anything more complex than that I think there should be a paid project planning phase with deliverables that the client can use with any other agency should they choose.
So the way it would work is that the potential client asks for complex functionality then we get a signed estimate for the planning and we create a full sitemap, copy, wireframes, etc. Then after we understand everything that goes into the project we give them an estimate for the programming and design. Should they not like our second estimate they can go to any other web shop with all of the planning done.
I like this – I’ve actually done this with one customer this year and it ended up working out well enough.
The only thing that comes with this is making sure that customers know that the assets that their getting (wireframes, PSD’s, etc) are tangible things that they can take with them.
That’s one thing I’ve had to convey.
It will depend on who’s asking and how clear the scope is. If the scope isn’t clear (i.e. Hi – I’d like a new site – I’m not sure what I want but want to know how much will that cost? ) – I’ll do a few emails back and forth, but will bill for a consultation if a call is needed.
If an RFP is provided with clear specifications, I’ll put together a proposal with no fees.
The best case is to spec out the work on a fee basis – and if the project/fee is accepted, then the initial amount is applied as a deposit towards the project.
Wondering how others are doing this in practice as well – great question, Tom!
Thanks Jaki – it sounds like you and I are generally on the same page.
Basically:
If the user knows that they want, then I’ll do estimates for free
If there’s any amount of “discovery” that needs to happen, then I’ll usually have to charge for that.
I think it depends on what the client has. If they have a well defined scope then sure you can estimate it based on the features. If they just have an idea they want implemented then it’s much harder to scope, and really you’re doing it with your estimate. That should be billed.
The other thought is how you price in general. I’ve been thinking about going to weekly pricing. In that scenario we’d figure out a rough number of weeks a project would take and spend the first one doing scope. Client pays on friday for the upcoming week.
This is an interesting idea to me – something I’d be interested in trying with a smaller scale project in the future.
Actually, have you blogged about his has gone for you so far?
This is something that I’m particularly interested in because I think it remixes the current model, and it provides a little more consistent cashflow.
I’ve talked about it, but am not doing it yet. I haven’t resolved how to deal with long term clients that have ‘little’ projects like small plugins. If I’m booking a week on a big project do I make them pay for a week for a feature that is really only a couple hundred $$?
I’ve found that it can be extremely helpful to do a brief explanation of the Cone of Uncertainty and provide free estimates in terms of a low range and a high range with a clearly stated 50-75% certainty. If the client provides additional scope, requirements, or constraints (ie, you’ve moved further down the x-axis on the cone) by all means modify your estimate. Hopefully by the time work actually begins, you’re far enough into the cone that your estimates are more informed, the range is smaller, and the client has signed off on scoping documents / success conditions for the work.
And this is one of those things that people – especially budding freelancers – have to get used to pushing back against.
Scope creep is one of those things that will never ever die because just as as we get in the process of delivering neat stuff for the client, it inspires them for more ideas, which in turn adds to the scope.
Over the years, I’ve gotten relatively comfortable taking a hard line on “here’s what we agreed on, and I’d love to this – but let’s hold off until version two,” or something like that.
And it really is that I’d like to do those things, but we’re all under deadlines, schedules, estimates, and all of that fun stuff.
I’ve found that when I’m forced to give an estimate the client latches onto that estimate and holds on with all their might, even if the estimate turns out to vastly underestimate the scope. I’ve even recently had one client passively-agreesively get a project approved as a fixed-fee estimate when I told them we would only take the project by-the-hour.
OTOH, getting clients to pay for estimates is difficult too. Which basically means that doing some budget project work is a thankless job; no good deed goes unpunished. About the only way to make it work is to “estimate” cookie cutter solutions and then after the fact offer to do truly custom work after the fact.
Or quit doing contract work and build & sell a product. :)
Mike – that’s great advice – even for a long time freelancer and business owner like myself.
Jaki – Thanks. Although I kind of feel it’s not so much advice as it is resignation…
Hm. I know you claim this to be resignation but I agree that it’s good advice. Definitely has my wheels spinning on how to begin restructuring my estimates so there’s a “core” for things that I know like the back of my hand, and then “add-ons” or “nice-to-haves” or whatever you wanna call the for things that will require additional discover and a more tailored approach.
And that’s what we’ve done at 8BIT and what I’m in the process of doing with my own company. I’m just taking my sweet time :).
Ah that, yes. I guess that part was good advice. :)
It’s really about “productizing” consulting services. All the big consulting firms do it; McKinsey has the “7s Framework”, Boston has the “BCS Matrix”, Delloite has “As One” and so on. Basically you can never do world-class work if you have to start from scratch every time so look for similar client types and similar projects and developer a methodology/framework for what you usually deliver.
And if you can post prices for those things on your website you’ll find that if you do a good job of finding something clients care about at an appropriate price you’ll find they self-select and you won’t even have to give them “an estimate”; they will already know.
OTOH, this is easier said than done. ;-)
Have you ever watched 30rock? All of these matrices remind of of listening to Jack Donaghy talk about becoming a black belt in Six Sigma and all of his crazy pie charts.
Anyway, that’s not to say there isn’t merit in these matrices. If they are developed and used, there clearly are, but – like you said – it’s easier said than done.
It’s probably easier for me just to keep a list of common things and see if I notice similarities ;).
You focus on the trees and not the forest.
In the case of the big firms, I often doubt there is any merit to their frameworks, but it’s the fact that productization works from a sale perspective I was attempting to get you to focus on. How you do it is up to you.
And hopefully you’ll do in a manner that offers value for your clients and not just income for yourself unlike what many of these big firms do. ;-)
I should’ve denoted by last comment was in jest ;). I didn’t meant to imply that I wasn’t getting the “trees versus forrest.” The truth is, you’re absolutely right in that there is value in having those matrices and, in a sense, “productizing” your process; otherwise, people wouldn’t do it and these things wouldn’t exist.
Based on what you’ve said here, I’m assuming that you’re saying that it works from a sales perspective because it builds trust between the vendor / client, right? That is, the vendor has a “tried and true” process for problem-solving, and the client sees it as if they aren’t going into building the software blind.
Regardless and FWIW, I do try harder to provide value for people that hire me – I’m more concerned about building several relationships with small businesses and individuals than I aim making profit my number one goal.
This is already going off on a tangent, but that isn’t to say that making a profit is wrong – it’s the purpose of a company (though I know people argue this and I don’t know if I’m willing to go back and forth on this right now :)) – but that shouldn’t replace treating customers with the respect they deserve and solving the problems they have.
Great post and discussion. Much like the last comments, I am realizing the need for ‘productizing.’ (aka standards).
There is a steep learning curve to every new platform I work on (even other open-source PHP based platforms), and it is frustrating, difficult to estimate, and negatively impacts how competitive a bid might be.
Knowing exactly how to accomplish a task makes it much faster. Even within a framework like WordPress, considering if i/we (or someone who codes in a way that I understand) built any preexisting codebase goes a loooong way.
As such, I’m starting to view free estimates as a courtesy (possibly reserved for existing customers) on projects small enough that it is feasible.
Regardless of if it is initially without cost, those hours are included in the proposal/bill and as my business grows I am seeing the need to be much stricter with scope but also billing, I know of a development shop that requires 1/3 before starting, 1/3 at the halfway point and 1/3 upon completion. That is where I’m headed.
I was reading an interview with a high profile lawyer and he said he still gets lots of calls (presumably from previous or existing clients) from people who want to know ‘if he has a minute.’ He said he tells them he can give them 5 minutes.
That way, he’s not just saying ‘no’ or seeming like he starts billing the very second his phone rings but it conveys that he is busy and his time is finite and valuable–seems smart to me. Food for thought, perhaps.