Estimating a web design project is difficult. I say this with confidence, having spent more than 15 years developing and designing websites. In fact, sometimes I still break a sweat when it comes time to estimate how much time and money a job might take. Working from the project requirements is challenging enough. Then throw in a touch of inherent uncertainty and a sprinkle of combustible creativity, technology and opinion, and the result often looks quite different than the oh-so-well-calculated estimate.
But don’t feel discouraged.
Drafting a new estimate for web design and development is an opportunity to hone your skills as a small business owner. I’ve made the Big Three Estimation Mistakes and I’m a better entrepreneur for having learned from making them.
As a fellow web pro and small business owner, I’m sharing my tips on writing a proposal so you can benefit without experiencing these pitfalls yourself. Once you know more about the top 3 mistakes designers make and how to avoid estimation blunders, your bottom line just might get a bit sweeter.
Mistake No. 1: You believe your clients know better than you.
You don’t really believe this, right? Then why go along with what they say is the “appropriate” cost for a job they know nothing about? They might know their budget, but that doesn’t mean they know what a web design job should cost. You do. So name your price with confidence and fairness.
Budget might come up in the initial conversation, and naturally, you limit the proposal to that amount. BIG mistake. Most likely, your clients base the cost of a project on something they read, heard, or expected. It’s safe to assume that they don't know what you know, so it’s up to the web pro to educate the novice on just what “appropriate” means.
As far as bidding competitions go — especially those with a maximum budget listed in the RFP — it’s tempting to low-ball your proposal. Don’t. I refuse to play that game for two reasons:
- It’s impossible to be the best and the cheapest at the same time.
- Winning a project that won’t compensate you for what your time is worth is not winning.
Mistake No. 2: You and your client are only taking the actual web development work into account.
But what about the time to communicate, get clarification on requests, research alternatives, test options, fine tune, confirm on multiple devices, and send status reports? You must make clients aware that the work doesn’t get done if these tasks don't happen. Therefore, factor everything into your estimate.
Mistake No. 3: You base your web design estimate on a best-case scenario.
After all, you’ve done this once or twice or a hundred times before. And it’s not as if a client ever changes direction. Or technology misbehaves. Or another client has a high-priority crisis to resolve. Or real life intrudes and your day is hijacked.
Sure, sometimes things go exactly as planned, to the minute and to the penny. But try as I might, I can’t remember the last time that happened to me. Better to factor in time for surprises and hiccups than be left in a labor-intensive lurch.
Recipe for web project estimation success
Now that you’ve got down what to avoid, start baking in the following ingredients to your recipe for web design project success. Keep your estimating activities in check and measure project-related success by constantly thinking of the bigger picture. Here’s what works for me:
Never give an estimate without doing the pre-work. Never.
I won’t provide a preliminary estimate — not even a ballpark figure. If the client can’t wait for me to do the pre-work and write an accurate proposal based on evaluating requirements, tasks, and alternatives, then I’m not interested in doing the project.
Plus, if I mention a number in an early conversation, and then later revise it based on pre-work discoveries, the client will only remember the first number mentioned. Guaranteed.
Estimate a range, not a single number.
All of my proposals include a range of time and cost, which clearly communicates that even with pre-work, it’s nearly impossible to pin down an exact time or cost. I also hope that by providing a range, clients won’t fixate on a single number as the be-all, end-all target.
Include enlightening verbiage in the proposal.
Although proposals focus on deliverables, time, and cost, I also include a paragraph in the summary highlighting that the time estimate covers “supporting tasks to design and implement the site, including research, prototyping, iteration on feedback, status reporting, and testing across browsers and devices.”
Review previous results and behaviors.
I track time zealously. My invoices include a line-item list of exactly what happened when, as supporting documentation to justify my fees. Fortunately, having the data available to compare task estimates to actual time is really helpful for later estimates.
And I take behavior into account. For a new client, I rely on initial conversations, their current website, and whatever else I can learn about them — including Yelp reviews. If I suspect extra handholding, training, patience, or communication time is in the cards, I’ll take that into account.
For existing clients, I also factor in their previous level of responsiveness, their tendency to change specs mid-project and whether they require Remind-O-Grams to pay overdue invoices. I might as well get compensated for the time required to chase them for information or payment. If you ask me, that’s part of the project too.
Build in time for all of the other stuff
Along with the items mentioned in MIstake No. 2 above, I try to anticipate additional technology interrupts, such as installation of software updates, or major changes in the Internet world (think Mobilegeddon).
And then build in some more time.
I like to bump up estimates to account for whatever I can’t predict. I’d rather estimate high and come in under budget, than eat the overrun.
My usual plan is to figure out the estimate and then pad by a fixed percentage — anywhere from 10 to 30 percent. For a small project, I don’t have a lot of extra time to work with, so I might need to pad by a larger percentage overall. For a large project, if one small piece is underestimated, there’s a decent chance that some other segment will come in under the estimate and I can make up the time. Whatever the approach, building in extra time “just because” is a smart move, and one that has saved me, time and time again.
What’s the payoff for the time invested in estimating a web project?
Landing the gig, of course!
And the more you write, the tighter this process gets. Impress the client with your attention to detail and thoughtful approach early on, and you’ll boost their level of confidence in you, right from the beginning of your business partnership. Plus, starting off with an accurate estimate maximizes your ability to be fairly compensated for the excellent product you’re going to deliver.
What has worked for you? Share your recipes for success (or even your phenomenal fails!) with the community. The more we all know, the more our work can sizzle.
