Budgeting

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 work.

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 testing.

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.

Budget Range: 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.