Super Business - Project Management Articles


Sections
Syndication



Tracking Budgetary Expenses


Tracking Budgetary Expenses

It is very easy for expenses to spiral out of control. Imagine that you are buying a new server. You’re talking with your favorite vendor and he’s showing you that for a couple hundred dollars more you can have two processors instead of one. And you say, “Might as well.” Then the vendor shows how for a couple hundred more you can add 200GB more storage. And you say, “Might as well.” Then the vendor shows how for just a little more you can really up the RAM. Again you say, “Might as well.”

“Might as well” are some dangerous words when it comes to shopping, aren’t they? It’s so easy to tack on some bells and whistles for just a few dollars more. Before you know it, those few dollars more have stretched your budget so thin you’ll either have to ask for more funds or skimp on other areas of the project. And it’s just not shopping that can ruin your budget. It’s also manpower, human error, lack of planning, hidden costs, and general lack of research.

Not only do you need a detailed budget prior to any purchases, but you also need a detailed method to track expenses as they are incurred. This is called working toward your BAC. By documenting each purchase as it’s made, you can check the purchase price against your initial budget to confirm that what you planned for is what’s actually implemented.

Runaway Projects

A runaway project, as its name implies, is a project that starts out well, gains speed, momentum, and scope, and then causes runaways with your budget, man hours, and possibly your reputation or career. The biggest element of a runaway project is the budget. Project managers often try to throw money at a problem, rather than completing root cause analysis. Too often in project management, there is an attitude of solving problems by spending more money.

Runaway projects happen for several reasons:

  • Lack of planning Failure to plan for all aspects of the project. Projects fail in the beginning, not the end.

  • Lack of vision Failure to create a definite purpose for the project.

  • Scope creep Management and departments continue to add details and extras to an existing project scope. Recall that the project scope is all of the required work—and only the required work.

  • Lack of leadership Without leadership, the project is bound to wander aimlessly and incur additional expenses.

  • Lack of a Change Control System (CCS) A CCS is a formal process to evaluate, approve, or decline proposed changes and additions to the project scope.

You can prevent runaway projects by creating a definite, nearly unmovable plan for the project’s implementation, budget, and scope as depicted in Figure 4-7. Any additional attributes of the project that are not key to its success should be set aside regardless of the requestor. In all projects, however, there needs to be a process that will allow adamant changes to the project plan. Chapter 9 will discuss this change management in great detail.

Click To expand
Figure 4-7: Many factors can cause projects to run away from the original scope.

Here is an example of what appears to be a simple change to a project’s scope: You are managing a project that will create an application with hooks into a SQL or Oracle database. The application will allow salespeople to place an order, check that order against warehouse inventory, and predict a ship date for the customer based on inventory or production.

The original plan of the application called only for tight coupling of the application and the database. (Tight coupling means the application has to be connected to the database to run.) Now, several weeks into development, management asks that you change the application to allow loose coupling. (Loose coupling allows the application to run without being directly connected to the database.) Can you see the problem now? Several weeks of development have been centric to tight coupling; now what appears to be a simple change does not reflect the work hours invested in the original application.

In this scenario, management is suddenly adamant about the loose coupling because it enables the salespeople to take their laptops into the field, take orders and store them locally, and then, once they are connected to the network in the office, actually synchronize the orders with the warehouse. The project manager must first meet with management and discuss the change and explain to management how the request will increase the scope of the project. When the scope of the project increases, additional funds will be required, in most instances.

Next the project manager will have to meet with the developers and discuss the new application plans with them. The developers will, no doubt, curse management, slam their keyboards a few times, drink some sugar-rich soda, and then start working the new plan into their project. Because of lack of planning, the project scope has increased, time has been wasted, dollars have been spent, and morale has suffered.

Keeping Track of Expenses

Before the project actually begins, you’ll need to work within your organizational policies on how project expenses will be tracked and monitored. In some organizations, budgetary concerns are handled by management with some input from the project manager. In other organizations, the project manager is responsible for the day-to- day accounting of the project budget. There are multiple tools available to help you track the project expenses, but whichever one you use to keep track of your project expenditures, you’ll need to include some basic elements:

Here is an example of an Excel spreadsheet to keep track of budgetary expenses. This spreadsheet is for the first of three phases for a software upgrade. The actual Excel spreadsheet, named Budget, is available on the CD-ROM.

Each project will, of course, have different needs for computing the expenses committed to that project. This example shows work hours, hardware and software purchased, and any incidentals. The formulas reflect a running total of each week of the project and a total for the project’s expense at the phase the project is currently in. You will get a chance to practice creating a budget spreadsheet in an upcoming exercise.

Phase One

Budget for phase

$160,000.00

 

Amount spent to date

$159,897.89

   
     

Variance

$102.11

   
             

Work Hours

Hourly Rate

Week 1 Hours

Week 2 Hours

Week 3 Hours

Hours to Date

Cost to Date

Steve

$21.63

37.0

30.0

39.0

106.0

$2292.78

Sally

$30.53

27.0

25.0

26.0

78.0

$2381.34

Jane

$32.81

38.0

37.5

29.0

104.5

$3428.65

John

$32.31

29.0

40.0

37.0

106.0

$3424.86

Fred

$30.38

35.0

40.0

26.0

101.0

$3068.38

Totals

$147.66

166.0

172.5

157.0

495.5

$14,596.01

             

Purchases

Cost

Number of Units

Totals

     

Server 1

$7854

2

$15,708

     

Application

$89

950

$84,550

     

Licenses

$45

950

$42,750

     

Total

   

$143,008

     
             

Incidentals

Cost

Number of Units

Totals

     

Network card

$21

2

$42

     

Sound card

$45

4

$180

     

Mouse

$37

2

$74

     

Video card

$69

3

$207

     

RAM

$268

5

$1340

     

Team dinner

$150

3

$450

     

Total

   

$2293

     

As you can see, this project has ended phase 1 with a surplus of $102.11—an excellent reflection of planning and predicting by the project manager. While a surplus of this little amount is acceptable, a surplus of 10 percent or more of the predicted project phase budget is not a reason to celebrate.

Some IT project managers congratulate themselves for coming in under budget. However, there are several problems with large budget surpluses. The first problem is that it reflects poor planning on behalf of the IT project manager. An accurate plan will keep any surplus within 3 to 5 percent of the original budget, including the agreed upon range of variance for the project. The second problem with surpluses is that it creates an attitude of spending. Organizations with surpluses do not feel obligated to return the funds, but rather feel obligated to spend them to justify their original budget and to ensure that their budgets will be as fat on the next project. Poor planning is not a reason to celebrate.


1747 times read

Related news

» Post-Project Audit
by admin posted on Dec 15,2006
» Budget at Completion
by admin posted on Dec 15,2006
» Manufacturing company: customer management competency framework
by admin posted on Jul 20,2008
» Implementing Bottom-Up Cost Estimates
by admin posted on Dec 15,2006
» Budget Basics
by admin posted on Dec 15,2006
Did you enjoy this article?
Rating: 5.00Rating: 5.00Rating: 5.00Rating: 5.00Rating: 5.00 (total 2 votes)

comment Comments (0 posted) 
Please Comment On This Article