Managing the Budget on IT Projects
Budgets should be managed no differently on IT projects than
on any other project. The reason that budget management is so challenging for
project managers on these projects is that, typically the project manager of the project is
not accountable for the budget and frequently does not even have insight into
how that budget is assigned or tracked. Money is typically assigned from
operational budgets to perform the project and responsibility for the money and
tracking of expenditures is done at the operational level. The result of this
disconnect between financial oversight and the project manager is that
budgeting for project activities and measuring the project's performance to budget
are not done in any formal way, and frequently are not done at all.
This does not excuse the managers of IT projects from taking
responsibility for the budget and utilizing all the best practices established
for cost management set forth in the PMI's PMBOK, it simply makes their job
more difficult. Here are a few tips on how to overcome some of the challenges
typically faced on IT projects.
Budget Accountability and Responsibility
The project sponsor is the person who is accountable for the
results of the project. Before I go any further, let me take some of the mystery out of the
terms: responsibility and accountability. The difference between accountability
and responsibility is simply the degree of suffering the owner will have if
things go wrong. The person who is accountable is answerable for the results,
or even liable for the results. Liability has a legal context so the person who
bears the legal liability for the results of a project would have to be an
officer of the company. Responsibility has a broader context and does not
entail being liable, but means answerable for the results. Getting back to the
project, an officer of the company may be the one who is accountable for the
project budget. Often the project is not large enough or expensive enough to
warrant oversight by an officer of the company in which case the accountability
for the project will be handed down to someone in a management position whose level
of authority would allow them to have oversight over the project.
The project sponsor delegates the responsibility for the
budget to you, the project manager. In the world of IT the relationship can be
more complex. Frequently projects in this area have 2 sponsors: the business
sponsor and the IT sponsor. Their relationship is one of customer and vendor.
The business sponsor is accountable for the money spent on the project and the
IT sponsor is responsible to the business sponsor in the same way they would be
if the business sponsor were to represent a company entirely external to the IT
organization. The business sponsor still bears the overall responsibility for
the project and they delegate that responsibility to the IT sponsor in the same
way they would if they were to hire an external organization to perform the
The sponsor (either business or IT), delegates the
responsibility for the project to the project manager. The delegation won't be
documented but it takes place as soon as you accept the task of managing the
project. They place their faith in the project manager's ability to deliver the
business value for the project using just the amount of money budgeted for the
project. They do this through the IT sponsor in the case where one is
identified. In either case, you are not the one that will feel the wrath of the
corporation should the project overspend, or fail to deliver on the business
value, the business sponsor is. You may feel the pain indirectly. You might not
get that bonus, or you might even be fired, but no-one is likely to pursue you
for the amount the project is over budget. You owe a duty of care to the
sponsor which includes ensuring that the project delivers its promised benefits
for the budget agreed upon, or to alert them as early as possible to problems
that would prevent that from happening.
Planning the Budget
There are two types of approach to budget estimation: top
down or bottom up. In practice, the right approach is often a blend of these 2.
Top down is chosen when there is a strict budgeted amount allotted for the
project. Bottom up is chosen when the project is essential to the business, or
is mandated by legislation. The first step the project manager should take is to
inform themselves of any budget limits, either a specific amount, or a range.
Keep in mind that being provided with a range for a budget does not necessarily
mean that bringing the project in for the upper end of the range is acceptable.
Your business sponsor, or IT sponsor should be able to
provide you with the budget amount or range for the project, where one exists.
Your first sit down meeting with the sponsor should include an exchange of this
information. Your approach to planning the project will depend on whether you
are given a hard cap to work with, a range, or no cap at all. Let's tackle the
case where you're given a hard cap first.
Hard Cap: A
hard cap requires that you scope the project to fall under the cap. In many IT
projects a good deal of the budget must be spent on labour so knowing the cost
of labour is vital to this exercise. Your accounting group should be able to
supply you with the loaded labour rate used by your company to cost labour.
Knowing the loaded labour rate and the number of work hours required for the
task or deliverable under consideration allows you to estimate the cost.
Estimates for other expenses such as hardware and software licenses should be
available from your procurement group, the vendors, or the internet. Keep in
mind that no-one can give you an accurate cost estimate without specifics,
which you don't have at this point. You will be able to ball park an estimate
for the deliverable, or task, under consideration and tell whether that
estimate is likely to fit within the budget.
There are all kinds of methods for estimating the cost of
software development, based on the hours of effort required to build the
system. Since you don't have all the requirements at this point, forget about
Function Point Analysis (FPA), or any other bottom up method. An analogous
estimate from a similar project in scope and complexity makes a good benchmark.
You can also use the Wide Band Delphi process which requires a panel of experts
to break the work down and estimate the cost of each task. If none of these
solutions are available to you, it's up to you to break the work down and
estimate the costs of each activity. Don't attempt to complete the WBS, break
the work down into the components you can foresee. You might want to solicit
the help of a business analyst in this exercise. Your estimate will only be as
reliable as the amount of information used to derive the estimate, don't forget
to add this disclaimer to any estimates you provide to the sponsor.
Don't forget to include the cost of QA when estimating
software development costs. There is actually no set rule of thumb to estimate
QA costs. One approach is to set your QA cost estimate as a percentage of your
development cost estimate. A good median to choose is 35%, or roughly 1/3 of
the estimate for development. Adjust this ratio upwards where the testing is
all manual and the application is a "mission critical" one. Adjust it
downwards where the application is not "mission critical" or your QA
group has automated testing tools.
Development environments, test environments, and a
production environment must be considered when costing IT projects. You may
have all of these already in place so they won't add to your costs. If not,
make certain that you identify all the environments that must be provided to
deliver the project. QA environments should be separate from the development
environment. One of the environments must support integration testing. Other
environments to consider are: the QA environment, a staging environment, and
the production environment. QA environments are typically used for testing
functionality, not performance or stress. If your system is "mission
critical", you should consider a platform for performance and stress
Delivering a project's goals and objectives within a budget
cap will involve trial and error. The first pass likely will not yield a plan
that fits within the budget, or if it does the budget may be too big or you
missed something. As you whittle the budget down and approach the cap, you must
ask yourself if the project is still capable of delivering the stated goals and
objectives despite the reduction in scope. Risks are something else to be
considered. Unless you took a wild guess at the right approach at the outset,
any reduction of scope you made to reduce costs will be accompanied by an
increased element of risk to the project's goals and objectives. To be
feasible, a cheaper alternative must have risk responses identified to handle
the new risks. Your project budget must include a budget for managing the risks
to your project, so make sure you estimate the costs of the risk responses.
The process of estimating the costs of high level
deliverables and activities will yield one of 2 results: either your project
can fit within the established budget, or it can't. If you are unable to
deliver the goals and objectives of the project within the budget cap, you will
need to alert your sponsor immediately. Don't wait for the end of planning
phase/beginning of implementation phase Gate Review to spring it on them.
Almost the same steps as you used to deal with the hard cap. Use the lower end
of the range to put your estimates into context and as you approach mid range,
begin to look for areas where scope can be reduced. The approach to reducing
scope needs to include the identification of risks and estimates for the risk responses. A budget
range provides you with more options when scoping the project. When you have
thrown out the "Cadillac" solution because you assumed it would
exceed the project budget, you may want to revisit that decision if your
estimate is close to the lower bound.
Your budgeting exercise is almost certain to require the
same type of reconciliation required for the hard cap so approach it in the
same way. Compare the requirement or feature or function under consideration to
the project goals and objectives. Does it directly support a goal or objective?
Is there a cheaper, more cost effective way to deliver the same functionality?
Don't forget to include an estimate for risk responses in the total budget.
No Cap: No
budget cap makes the chore of budgeting for the project much simpler. Beware
the project with no budget cap however, as organizations can rarely operate
this way. If you are not given a budget cap it may be because you are expected
to tell your sponsor how much the project is likely to cost and then let them
make the decision on whether to proceed or not. If the project is in response
to legislation, or there are other compelling reasons for performing the
project, you will probably still have some guidelines to follow which will
limit your spending. Do your best to have your sponsor state any expectations
they have at all about the ultimate cost of the project.
The project scope or schedule will be the top priorities
where there is no budget cap for the project. Planning spending for this
project will require you to reconcile budget and scope/schedule in a different
fashion than for projects with a hard spending limit. The system features and
functionality should be more clearly defined in the case where scope is the top
priority. They should also be more clearly defined where time to market is the
top priority. The difference between these two scenarios is that in the case
where features and functionality are the priority, delivering the full set will
require the project to take however long it takes to build these. The feature
set may have to be pared down where time to market is the driver.
You should have a Rough Order of Magnitude (ROM) estimate of
the cost of the project at this point. This estimate should either fit under
the stated cap, or within the range you were given for the project. The next
step is to continue the breakdown of the work and assign a portion of the
budget to each deliverable or task in the WBS. We'll talk about that in the
next article in the series.