Enterprise Software

Robbing Peter to pay Paul: How to safely raid your project budget

Unplanned budget cuts and changes are more truth than fiction for most project managers. These tips on effectively managing your resource budget will help keep your project on the road to success.

For IT managers, the odds are high that the project budget you start with won't be the budget you finish with.

Budgets are often cut, rearranged or even increased, but those increases may not be adequate. When your major area of responsibility is efficient deployment of resources, personnel deployment and budgeting are the most critical controls you have. And while many managers acknowledge this reality, few factor it into project plans.

Padding can be problematic
It never ceases to amaze me that veteran managers know for certain that their resource allocation and tasking are going to change; probably fairly often, in the course of a development effort. Instead of planning for the change, many managers "address" the problem by padding every task by about 20 percent. Padding is the lazy way out. It is like being a general at war and throwing 20 percent more soldiers into every battle and defensive position, when you know ahead of time that some positions will be easily held and some battles will likely be pure carnage.

It’s a thoughtless and poorly prepared manager who doesn’t see the reality of rapid priority and resource shifts in a rapid-development environment. Worse yet, some managers plug in that extra 20 percent, get approval on that budget from above, and then expend that 20 percent fruitlessly. Bottom line, there are much better ways to handle the changes in your project than the old 20-percent “pad” rule.

Anticipating the unplanned
In this age of ERP, it is more certain than ever that priority changes will severely affect your project team. The whole point of ERP is to facilitate the evolution of business processes; it’s inevitable that some project objectives and tasks that seem crucial at the beginning will diminish in importance, while seemingly trivial items will become critical.

Moreover, the methodologies you’re applying today are significantly different than methods you used 10 years ago. Today, users are heavily involved, and you already know they aren’t the most reliable source. They will change their minds, express themselves incompletely, and “forget to mention” steps in processes that make all the difference to your system design personnel. As a result, little problems become big problems and you often find that the task you budgeted at a mere 60 man-hours is really going to cost you 300.

Survey your battlefields ahead of time
The first step in analyzing your resources is to review the situation long before any change hits. If this seems like crystal ball gazing, remember that the methodologies you now adhere to give you a secret weapon.

Contemporary thinking in development methodology says it’s better to deliver 100 percent of the most important 80 percent of your project than to deliver less than 100 percent of the whole thing. That is, you understand (and so does senior management) that you are going to deliver, complete, the most critical portions of the system you are developing, rather than to incompletely deliver everything you initially planned.

Knowing this ahead of time, you have a high-level map of all the terrain under your control. Sit down before the project begins and look at your objectives from the top down. Review what must be delivered, the area where you are likely to pump in extra man-hours, and an area you will mark off-limits for short-term raids. From this point, work your way down, and weigh the mission-critical consequences of incomplete delivery or complete failure, by objective first, then by task. Here, you’re asking, will the project be seriously hurt if we don’t deliver this item? Can we afford complete failure to achieve this portion of the plan? Can we afford to deliver a less-than-perfect result? The list of tasks that can fail without seriously damaging your mission-critical deliverables is your list of "raidable" resources.

Mixing and matching your resources
Anticipating that your front-end assessment of what is and isn’t critical will be revised as priorities change and new tasks are added, remember to do this assessment top-down—most of your priority shifts will occur at the task level, not the objective level. That is, Accounting must have certain functions made available; it’s the interface and downstream processes that will undergo extensive change. So you can’t do a perfect job of lining up your money buckets in order of their "raidability," but you can at least hit somewhere close.

The next major step in your front-end contingency planning is to match the mission-critical tasks (the areas into which you are most likely to pump extra resources) with resources that can be reassigned with the least negative impact.

The rule here is to work from the outside in. That is, write down ahead of time your highest mission-critical objectives and their associated tasks. Next to those items, write down the list of lowest-priority objectives and tasks—this is your list of contingency sources of man-hours that can be shifted. Continue to work this list in this way, with high-level objectives lessening in priority matched to low-level objectives increasing in priority. By the time you reach the middle, you’ve created a template of man-hour transfers that is probably deeper than you’ll actually need and you’ll have come up with a plan for budget raids that will be the most likely to ensure your completion of the most critical pieces of the project.

Delivery is everything
In the long run, your performance in bringing the project home will be more a question of its suitability for its business use than anything else. Consider that most projects run over schedule or budget or both, and that coming in on time and on budget buys you nothing if you deploy an inadequate system.

By planning your resource raids ahead of time, in top-down fashion, you bow to the inevitability of shifting tasks and constant change, but you do so in a way that preserves the integrity of your resource expenditure. Your project is much less likely to bleed to death from a thousand cuts if you realize that it may lose a finger or two. By learning to steal from yourself effectively, you can be more certain of pleasing users and senior managers alike.



Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

Editor's Picks

Free Newsletters, In your Inbox