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.
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:
-
Work hours Time is one of the most
expensive elements in any project, so you should have a plan for team members to
report their hours working on a given project. If you are working with vendors
or consultants who will be billing by the hour, create a method for them to
report their hours as well. You may need to create a formula to reflect overtime
and weekend pay if that is applicable to your organization. Functional managers
of your project team members will also want some accountability of their
employees’ time on your project.
-
Procured goods Keep track of all hardware,
tools, software, cables, and any other item that is purchased directly for your
project. Your accounting software should have a method for entering any of these
items. Also include petty cash items such as pizza, dinner, and miscellaneous
items your team needs.
-
Software licensing If your IT project
includes software-licensing fees, be sure to document them. In some
organizations, the IT department may pay for the initial licensing of the
software, but as the software is released throughout the company, other
departments have to pay to use the software from their budget. An IT project
manager should know how these fees are handled and from whose budgets these
funds will flow.
-
Workstations and servers If your IT
project includes workstations and servers as part of the plan, document the
purchase price and installation date of the computers. Obviously, in some plans
the implementation of the workstations or servers may in itself be the project.
The reason to document the actual expense of the computers is so that if they
are recycled into other servers or workstations for future projects, you can
reflect the original paid price of the PCs and then diminish the value of the
computers in the new project. You likely won’t have to get into the details of
single-line deductions versus dual-declining deductions for tax purposes, but
your company’s accounting department may query your decisions and choice to
recycle hardware. Often an older workstation can be used as a terminal for
Citrix or Windows Terminal Services. Rather than purchasing new PCs, you can
incorporate the value of the older but usable PC.
-
Actual variances Throughout your project,
you may have small variances from what was estimated and the actual cost of the
deliverable. For example, you may order supplies for the project at $440 and the
actual invoice is $480. While it’s only a $40 variance, it’s still a variance
that’s going to add up and count against your budget at completion.
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.
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.