Three ways to minimize your project budget exposure

Date: November 19th, 2010
Author: Brad Egeland

Keeping the project budget in line is one of the most difficult things that a project manager does — and yet it's a huge factor in determining the overall success of the project when the engagement winds down. The goal is to keep the budget in line throughout the project and avoid falling into emergency mode at any point with a huge overrun.

The three processes I'll talk about here are extremely helpful to me as I try to keep my project budgets in check. Developing good processes and habits will help you significantly reduce the likelihood that your project budget will turn into a catastrophe. Let's review each of the three ways that will help you minimize your project budget exposure.
Review and revise the project budget at least weekly

The first thing you can do to protect your project budget is probably the easiest thing you can do, and it's definitely the least invasive thing you can do. Get weekly information from Accounting concerning the charges to your project and revise your information diligently every week. This may seem simple, even mundane. But it always amazes me how many project managers get lazy and let this slide for a week or two and then, eventually, longer. "Hey, it wasn't a problem three weeks ago and nothing significant has happened on the project, so why should my budget be in jeopardy now?"

Well, little things build up — and they can build up fast. Stay on top of the budget; don't let a week go by without comparing forecasts to actuals and reforecasting, if necessary. It's much easier to fix a 10% budget overrun now before it gets out of control than it is to fix a 40% budget overrun a month from now after it's already out of control. And which one is management going to be more pleased about hearing? Which one will the customer be more understanding of and more flexible about?
Make your project budget high profile

This is also a fairly easy process and has worked well for me. If your organization is a matrix organization with everyone working on multiple projects at once, it works even better. Here's the scenario:

You are a project manager running five projects at once. On average, each of your technical team members are on three different projects at the same time. In all honesty, 80%-90% of all employees calculate their project charges for the week at the last minute, usually on Friday. Very few accurately document their time during or at the end of each workday.

We all remember most of what we did in a particular week, but there are always those four or five hours of activity that we really can't pinpoint. We know we worked 50 hours that week, but can accurately account for only 45 of them. Those hours have to go somewhere, but where? They go to the project where they'll be least noticed–the project that we know is not being monitored closely.

So don't let that be your project. Make sure your team members know you're watching your project budget — and the hours that they charge to it — like a hawk. Discuss the budget with them at every weekly internal team meeting and give them a status update on how the project budget is standing up to the original forecast. Share your concerns with them. Periodically question them on charges just to keep them on their toes. Don't be accusing, just ask them questions about the charges and the work that was being performed. If they know you're that aware, it's highly unlikely that any of your projects will be recipients of the "gray" hours at the end of each work week.
Manage scope closely

This is probably the hardest one to do and can have the most devastating affect on the project budget. The problem here can be two-fold. You have the issue of managing the project scope from your project manager perspective and negotiating changes and change orders with the customer. But you also have the task of managing your project team members closely as they work with the customer.

On at least a third of my projects I've run across potential scope issues through discussions I've had with my project team members who were in close communication with the customer. Those team members develop a relationship with the customer, which results in their agreeing to any small request the customer makes. This "small" request ends up costing your developer a few hours (which can mean a few thousand dollars) of your precious project budget.

Inform your team members, warn them of these kinds of situations, and then, when you meet with them every week, ask them about any customer requests that may have been made in the interim.