Project Estimates: A Modest Proposal

We are blessed to work with a fair number of creative agencies on projects where they will provide the strategy and artistic flair, while we handle the technical implementation and code. Many of these firms grew up as print agencies and have deep knowledge of their clients' markets and communications strategies. It makes sense that they are intimately involved in establishing these brands online.

When these agencies pitch new work to their clients, it is typical for them to produce proposals with fixed-bid estimates, and as partners on the project, we are asked to do the same. Now, developers who are reading this post, I know what you're thinking: Fixed budgets are for morons. How can you possibly know what complexity will enter into a project before you start? And have you seen proposals from creative agencies? Talk about a vague spec! You should do agile on every project!

Hey, we love agile methods as much as the next guy, and we warmly embrace them with clients who are ready to think that way. But many customers (especially those who come from a marketing and design mindset) quite reasonably want to know "How much is this going to cost?" If we want to be considered for the project, we have to come up with an estimate, often without knowing much of the complexity that may be uncovered during the project. Small projects with known requirements are easy to estimate. It's the big projects (the kinds the agencies love) that get you. No matter what the estimate, it always seems that there are hidden requirements, design changes, browser bugs, or legacy systems to rebuild that, for some reason, no one thought to mention. These "surprises" are only surprises to the extent that we don't know what they will be when we start the project, but we can certainly count on finding them along the way. These can add dramatically to the development time on a project.

Here's a template for a big development time overrun: Sign up for a big project with a sketchy scope description. Agree to a budget that seems large to the client (and maybe even large to you). Insert an agency between the developers and the client. Enjoy! Nine times out of ten, there are costly development tasks left over when the budget is expended. Maybe you suck it up and do a ton of extra work to make everybody happy. Been there. But you can only do this so many times before developers get frustrated or you decide you can't afford to serve the client any longer. 

So what's a development shop to do? Here's an approach that we are having some success with (when agile is not on the table):

We have observed that, most often, the first half of the budget is sufficient to complete 85% of the deliverables. It's the last 15% that kills you. That 15% contains the unfortunate elements of the project— all the stuff that seems like it should be easy but is very difficult. The client is a huge factor in how that last 15% plays out. Some keep tweaking and fine-tuning and re-thinking features— so much so that you wonder if the project will ever end, and yet everything they ask for falls in a gray area. Not really in scope, but not clearly out of scope. And the requests seem reasonable, especially from an end-user perspective. It's just that they add up to a mountain of time that you didn't anticipate in the estimate.

On these types of projects, our goal is to get the client to share ownership of the scope at the end of the project, and we need for there to be dollars attached to changes, new ideas and feature requests that come in during development.

The 50% Solution

Our strategy on large, complex (non agile) projects is to cut the budget in half. Seriously. Here's what I say:

The project you are describing is large and quite complex. There are many parts of this that are very clear and could be tackled right away, but there is a bunch more that we won't discover until after we start. But that's okay. We've done plenty of projects with this level of complexity, and here's what we know: The first half of the project budget can get you 85% of the distance to your goal. Our educated guess is that this might be a $40,000 project. I suggest that you approve half of the budget ($20,000) and have us go after that first 85% really aggressively. At that point, we pause and evaluate where we are at. You may find that the project is good enough to launch at that point. If so, fantastic. Save the second half of the budget for future needs. If, however, there is more work you want us to do, that's fine too. We will work collaboritively with you to go after your top priorities, reviewing a week at a time as we make improvements. We will bill for the actual development time incurred during this phase and can stop whenever you decide. This helps us all to focus on top priorities and ensures that your budget is invested wisely. 

By taking this approach, we join the client on the same side of the problem. If a project finishes under budget (or even at the 50% fixed budget), hallelujah! If a client wants to continue making improvements beyond the limits of the original estimate, that's fine too. But setting this expectation of the 50% estimate seems beneficial to clients who need to allocate budget dollars. I hope you find it helpful too!