How to Avoid Project Budget Blowouts

Georgina Laidlaw
Georgina Laidlaw

We all face times when a job looks like it’s about to go south, but there’s nothing like that creeping feeling that you’re going to blow the project budget.

Disaster can ensue — particularly if you don’t have a particularly close relationship with the client, or they, or their organizational culture, dictates that blame must be laid somewhere.

What do you do when you realize that the project you’ve worked so hard on is going to take more time than you estimated? Obviously your response will depend on how firm your estimate was, and how clear your project scope was.

But I think the secret is to treat the quoting and scoping tasks as the construction of an early warning system for your project and budget progress.

My Early Warning System

In responding to a project brief, I usually provide estimates of hours — with attached hourly prices — for each part of the project.

I typically break the project, and the estimate, into chunks so that the client and I know which portions of the job are expected to take more time, and which are expected to take less. I also build in some fat to help avoid blowing the budget. Each portion of the job gets its own portion of fat.

This approach usually allows me to detect early if something’s going awry. If I get to the end of a chunk of the project, and I’ve used up all the time I estimated for that chunk, I know that I’ve effectively gone over time: not only have I taken up all the time I expected to use, but I’ve used up the fat as well.

This causes me to look into the project a bit more closely, to try to identify why it took longer than expected. Recently, I had the feeling that the first stage in a project would take longer than similar, subsequent stages, because initially the client and I would spend time getting the tone of the content right. So when I used up all the allocated time for this first stage, I had a hunch that this was the reason why. It was: on investigation, I found that I’d spent more time than usual on revisions as we tried to nail down the personality of the content.

An Early Warning Response

My early warning system is just that: a warning system. All it does is allow me to identify when something’s taking more time than it should.

What I do with that warning information is crucial.

In almost all cases, I tell my client before I’ve reached the estimate limit on a piece of work within a project. Once I realize I’m eating into the fat that I built into the quote, I tell them, so that they know what further revisions or requests will mean to this portion of the job.

When I reached the limit of my estimate recently with the client I mentioned a moment ago, I told them so, and reiterated the reasons why we’d expected this first portion of the job to take longer than the rest. In this case, we were working closely together, and I was confident we wouldn’t exceed the fat I’d built into the estimate, but when I told them this, I explained that sticking on budget for this portion of the project would require team work — both they and I would be responsible for keeping things on track.

Of course, if your early warning system goes off in the first stage of the project, you might consider reviewing your estimates for the latter portions of the job. In my case, the client and I had expected that the first stage of the job would take longer than the others, so we left the estimates for the latter project stages as they were, and we ended up coming in under budget.

But some unforeseen issues may give you good reason to reevaluate those estimates. One common issue is signoffs. Often, clients tell me they’ll have a quick, easy signoff procedure, and will get any revisions back to me speedily. Then, when the time comes, every manager in the business wants to review the content, make amendments, and review — and possibly comment on — the implemented revisions.

If you discover these kinds of unavoidable hitches — or other client quirks — in stage one of the project, when they trigger your early warning system, that’s good cause to review the estimates you made for the rest of the project, and add a proportional buffer to each one. Discuss that with the client, and if they want to keep the estimate low — or even stay within budget — they may choose to streamline their signoff procedure for future project stages.

This is how I try to avoid budget blowouts — and so far, this approach has served me well. What basic processes do you have in place to plan — and react — to project budget blowouts?