I have a confession to make. I'm absolutely terrible at making estimates. No matter how long I think something is going to take, it always takes longer. Even if I double, triple, or even quadruple my original guess.

And it's hurting my business. Why? Because I do everything I can to deliver what I promised. And I end up losing money, instead of making money. Instead of renegotiating with the client, I work nights, weekends, and pay my employees out of my own pocket to deliver. I go months without a paycheck, rarely get a day off. Does that sound like any way to run a business?

For years I thought it was something else--that we just weren't executing well enough, that I didn't have the right people, that I didn't know how to run a business. But I've exceled at every previous job I've had, have lots of happy customers, and hear regularly from peers and colleagues that my insights have saved them lots of money, or helped them figure out the key things they need to understand to make their project succeed. And now I realize that I've been going about it all wrong.

The problem is, lots of things outside our control affect the cost of delivering a solution. Microsoft releases a new browser, and it breaks a bunch of Javascript on a bunch of sites. Who pays to fix those sites? A client asks for a bunch of reports, with one more layer of summarization than our tools can currently provide. Is that part of the original project, even if we didn't know about that requirement at the beginning? A client who has never fully thought through a user login system changes that system three times--which represents a major change in the project--and then wonders why we went over the estimate. Or, harder from our point of view, a key module we thought we could rely on for particular functionality turns out to be half-baked and causes more problems than it solves, and we end up deep down a rabbit hole of debugging to find a simple solution that solves everything better and takes 1/2 hour to implement--after we've spun our wheels for 20.

It's not just us. It's the nature of creative work. And our clients haven't been paying the actual cost of that. We've been bending over backwards to deliver everything they asked for up front, without charging more than our budget, but with no flexibility in the scope. From our standpoint, all parts of a project are equally weighted--if the customer asks for it, we do it, even if it uses more of the budget than it should and leaves us short when we get to a critical part of the project. Our clients dictate the scope AND the budget, once we get started. That's the real problem.

Starting right now, we're changing that. As a client, you'll now get to choose one or the other: Scope of the work OR the budget.

If you want to control the scope, we're happy to deliver everything you want and send you regular bills as we go. We can't tell you what it's going to cost ahead of time, because we don't know the scope. Even if you tell us. Because almost certainly, you're wrong--there's something significant you've left out, and nobody knows it until it comes up.

If you have a limited budget, then I'm sorry, you can't control the scope. We want your project to be successful, and we'll partner with you to make the most of your budget, deliver the most value we can for your budget. But when we've run out of your budget, we're done, until you've got more.

I think this is going to lead to a lot more successful projects. Why? Because it makes us an active participant in the planning of your project. We not only can, but must apply our years of experience to prioritize which parts to implement first. When our clients control the scope, the focus tends to be on the look and feel. We spend far too long making minor changes to the front page of a site, without wiring together the things that actually make the site work. If we control the scope, we'll start by identifying and prioritizing each feature, and make sure the critical stuff gets done before you're out of budget. And make sure we're around to keep helping your site improve.

The other change we're making is setting it up so that the launch of a web site is the start of the project, not the end. If you're like most of our clients, your needs will change over time, and we want to keep helping you adapt your site to meet your needs. That's the real strength of our platform of choice, Drupal--it can continue to grow and change as you use it. Set a regular budget and we'll work with you over the long term to keep improving your site, give you ideas on how to make it do more for your business or organization, and implement the things we cut from the initial project when we ran out of budget.

So here's to a GREAT 2010... Happy New Year!

Share this article with your friends!

Comments (4)

Just thought I'd drop a quick note and as a former Freelock employee, and future solo consultant/contractor, I applaud this post. Very good insight on how to improve things in a business where it is very hard to predict projects.

04 Jan, 2010

Thanks for writing that post!

As a programmer with experience both working under contract and supervising contractors, I have seen the issues you present first-hand. Having been paid at times hourly wages, at times flat fees, and at times on salary, I agree that the definition of the budget is as important as the definition of the project.

I've seen very savvy contractors make huge margins on certain jobs with a set budget and set scope, knowing that they will surely incur losses on others. Navigating in that environment has often made the difference between businesses that succeed and businesses that fail.

I've tried very hard to develop skills to create good estimates - it's not easy! At first, I thought that good estimates are based on a thorough knowledge of how to perform a certain type of work and of how fast it can be performed. That's only part of the picture, though. I have found that a good estimate relies on an intimate understanding not only of the work to be performed as part of the solution, but even more importantly, of the problem to solve as it exists for the client. I found that I would make better estimates when I knew exactly, every detail, of what the client needed to accomplish a project and be satisfied with the solution. I often make mistakes in creating estimates! When I make the biggest mistakes, I find that I didn't understand the client's needs.

If a contractor doesn't understand all the parameters of the project, it's perfectly logical that they shouldn't make an estimate about it. For a set-scope project, the client will then make an estimate for their costs. For a set-budget project, the client will then make an estimate for the results they might see. In either case, someone is making an estimate.

Estimates are the backbone of the traditional struggle between the contractor and client for predictability in budget, in hours spent both working and spent supervising, and in results delivered. That struggle can often create imbalance if there is not effective communication. I believe that clear and effective communication can transform the struggle into teamwork.

Thanks for making the options for set-scope and set-budget projects with your company very clear. I'm glad to see that someone else is thinking about all these issues too. I hope the end of estimates brings success for you!

06 Jan, 2010

Thank you for sharing this information. I struggle too with delivering what I promise and often end up spending far more time and money than I estimated. I will keep the idea of either scope or budget in mind. Good luck, with implementing your new year's resolution!

14 Feb, 2010

Hi John,
Nice post. The other think to keep in mind is that you can NEVER give in on quality. Code quality is the platform that enables the product to grow and meet new requirements.
If quality is high and the requirements are delivered in business value priority order, then the customer can at least make informed decisions on what they are spending.
These are some of the fundamental principles of Scrum and Agile Development.

Rod Claar
Agile Practice Leader

13 Jul, 2010

Add new comment

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.