CXO

Managing your budget: Staying the course

Once your project has started, keeping your budget on track can take a lot of effort. This article highlights three potential problem areas and explains how to keep them confined.


Even if you outline every possible contingency, something always comes up that has the potential to stretch your project beyond its assigned budget. Sometimes, hidden expenses sneak in where you’d never think to look for them, and they damage not only your bottom line but your timeline as well.

The previous article in this series, “Creating your project budget: Where to begin?,” talked about basic philosophies for defining your budget and outlined major pitfalls to look out for. We also discussed assigning risk calculations to your project to help create an accurate depiction of your final costs. This time, we’ll present three ways that budgets get inflated—omissions, scope creep, and developer independence—and how to avoid or control them so you stay on track.

A rock and a hard place
In every project, something is initially overlooked. You don’t have nearly enough planning time for most projects, so leaving something out seems to be a natural part of software design and development. Such omissions can be hard to deal with—they’re embarrassing and often lead to emergency meetings in the “Hall of Finger Pointing and Blame.” Let’s examine some ways to lessen the damage and keep it from affecting your budget.

We all know the adage about an ounce of prevention; when we discussed defining your budget in the last article, we talked about assigning risk. Over the course of a project, it is easy to make allowances for things that would normally expand your budget, under the pretense that these items would be covered under your total risk calculation. Unless the offending occurrence in question is itemized in your risk statement, such allowances are a big no-no, because they can leave you in a serious crunch toward the end of your project without any alternative but budget expansion. So include a certain amount of risk for errors and omissions (lawyers do it, why not you?). The less time you have to plan, the greater the chance you’ll need this category.

That’s all fine and good, but suppose it’s too late for prevention, and what you really need is a pound of cure. If you’re up against a wall, it will take some serious diplomacy efforts to resolve matters. Here’s what I suggest:
  • Don’t take it personally—every project has omissions, and reacting in a defensive posture will only make things worse.
  • If you can take care of the issue without raising the alarm, do so! Wheel-spinning costs lots of money and can worsen the effect on your budget.
  • Don’t go to the project driver with problems until you have some solution recommendations to accompany them. That means you have to do some analysis and find a way to either work around the omission or compromise less critical items to save your bottom line.
  • If the omission is noncritical, do without or put it at the top of a wish list. The next time your team comes in ahead of schedule or you’re able to trim costs in some other way, schedule inclusion of the omitted item.

Handling omissions like a pro will help you save face and reduce their impact on your bottom line.

How have you kept your budget in check?
Join the discussion below or send us an e-mail and let us know!

Functional spandex
Scope creep (also called feature creep) can find its way into a project with little difficulty, and it comes from a variety of sources. To handle requests for additional functionality, you need two things:
  • A safety valve to control the influx of new features, such as a design document and a change order process
  • A strong backbone

Once your budget has been defined, you’ll realize that every feature you specified requires all the time allotted. Because your budget is closely based on the amount of time developers must spend to realize functionality, you’ve got a finite amount of raw materials to work with. You should have a good idea of what the most critical parts of your project are and which pieces are superfluous. To prevent budget expansion, the trick is to cram all of the critical parts, and most of the less-critical ones, into that finite time-is-money frame.

If you really want to keep your budget on track, learn to say no. Of course, as a professional, you have to sugarcoat this answer a little. That’s where your wish list comes back into the picture. Treat this list of desired functionality as an “if we have time” priority list. When new functionality is requested, tell the requesting party, “Sure, no problem. What do you want to cut? I’ll just add it to our second tier of functionality,” or something like that. You’ll quickly discover how important the requested add-on really is.

If the new functionality truly is that important, and there isn’t anything that you’re able to bump from the release, go back to your first tool—the change order form—and work on getting approval to expand the budget. You may be able to rearrange your Gantt chart to squeeze a few more hours into your plan, but try not to rely on that too much or you may start to loose productivity due to developer burn out, another silent budget killer.

Off the beaten path
Getting off target on your objectives can wreak havoc on your budget. Even if you’ve spent plenty of time planning and designing your solution’s architecture and making sure the entire team understands what your goals are, your project may begin to move away from center.

Generally, this happens because someone on the team knows a supposedly “better way” to the solution than the one in the plan and strays from the architecture guidelines. When this deviation isn’t conveyed to the rest of the team, as it would be were it part of the plan, everyone else has to compensate, taking expensive hours away from your primary path. This drift isn’t usually intentional, which is one reason project managers can be valuable to a project—if everyone has to protect the big picture, no one is left to keep an eye on the details. Trying to do both takes too much time and energy away from your project’s forward momentum.

When you plan your project, be sure to include time for code walk-throughs. Have regular developer meetings, where everyone can share their progress and review your budget and timeline status. Make sure everyone on the team knows what the next two steps are. Not only will this keep everyone moving and looking forward, it will create a sense of urgency and help prevent developer independence when it is unwanted.

Ultimately, to keep things on track, stay involved. Perform management by walking around, and of course, keep an eye on the budget yourself. Nothing lets a project run away from you more than lack of awareness.

Summary
In this article, we looked at ways that your budget can get away from you, and we offered suggestions on how to prevent and counteract these digressions. Omissions, scope creep, and developer independence are all risky areas that frequently overrun project plans. They can be controlled through attentiveness, diplomacy, and dedication to your project’s success.

Editor's Picks

Free Newsletters, In your Inbox