Project budgeting

the key to bringing business projects in on-time and on-budget

FROM FUNCTIONS TO PROJECTS

The recent deterioration of some of our largest corporate organizations and the unprecedented rise of small, lean entrepreneurships is due in large part to the inability of corporate management to make the adjustments necessary in both attitude and action to deal successfully with the distinctive challenges of today's rapidly changing world. This article attempts to demonstrate the depth of corporate policy adjustment that must be made to give our organizations the kind of flexibility they need to be effective in today's and tomorrow's fast-moving business communities. It focuses on the differences in budgeting concepts between hierarchical, functional organizations and cross-functional project organizations, and it uses the experience of the formal project world to explain the changes that must be made in our business budgeting practices. Note that the word “budget” is used to refer equally to time and money throughout this article.

If the American business community expects to succeed in a world that demands lightening-fast response to rapidly changing markets and economic conditions, we need to become project experts. As consumer markets undergo radical political and social change more frequently, more and more of the work we do is done in project mode. Since there are no signs of such trends slowing down, it seems obvious that project expertise is fast becoming a must for both public and private organizations.

Project management is the only tested, cohesive management approach we have that allows us to pull a team of experts together rapidly, focus them on a specific job, disband them when they've finished, and start all over again as soon as a new need is detected. An effective project management system enables project teams to deliver the highest quality products possible, in the shortest time, at the lowest cost.

A large number of the problems today's managers are facing, such as runaway costs, low-quality deliverables, and poorly motivated teams, can be traced directly to the use of inappropriate budgeting and management techniques on project efforts.

Unfortunately, most business organizations have little understanding of project management and lack the ability to make deep enough adjustments in their corporate policies and culture to properly support project efforts. In particular, the fact that the business community insists on using fictional budgeting concepts on project budgets renders the most sophisticated project management approach ineffective. In a section called, “Why Plans Fail,” Kezsbom, Schilling and Edward [1] list such items as:

  • Financial estimates are poor.
  • Not enough time is allowed for proper estimating.
  • Estimates are best guesses, not based on either standards or historical data gathered on similar projects.

A large number of the problems today's managers are facing, such as runaway costs, low-quality deliverables, and poorly motivated teams, can be traced directly to the use of inappropriate budgeting and management techniques on project efforts. When management is ignorant of appropriate project budgeting concepts they use erroneous figures as their cost targets and therefore show huge overruns when much of the problem was simply not dealing with real figures. When project time and resource budgets are insufficient, quality is often sacrificed. When project teams are expected to work overtime, weekends, etc., and still face project failure, morale dissipates rapidly. Successful projects require new thinking, new procedures, and an entirely new relationship between management and project personnel.

FORMAL PROJECT MANAGEMENT

Project management had been a successful methodology for the construction and engineering world for decades before the business world discovered it. Despite the occasional project that overruns its budget and delivers past its due date (and of course, those are the ones that are highly publicized), the overwhelming majority of formal projects are highly successful. That's thanks to the continuing development of effective project management techniques, much of which can be attributed to the military and government.

The Navy, the Department of Defense (DOD) and the Department of Energy (DOE) have, for years, been active contributors to the continuing improvement of project management tools and techniques. Their work did a great deal to further the cause of standard project behavior in the formal project world, not only in the United States, but throughout the world, wherever formal projects are executed. The success of formal project management methodology supported the healthy growth of entire industries like aerospace, shipbuilding, construction, defense, and so forth, both in the commercial arena and in government. Though current economic and political situations have caused some of these industries to pull back, they were for a long time among the most flourishing segments of American enterprise.

The business community, however, adopted project management without fully understanding how it operates. PC software was so easy to use that many business managers never bothered to investigate formal project management or become familiar with its underlying concepts. As a consequence, most management expectations of project work are somewhat unrealistic. Executive management, having only the behavior of the functional organization to compare to, neither recognizes nor appreciates the accomplishments of their project teams. In fact, the way project management operates in most businesses is so inappropriate it actually increases project costs and provokes the creation of poor-quality deliverables.

The business community would benefit greatly by understanding how the formal project world manages to be so successful. We must especially examine the ways in which project budgets differ from functional budgets since the way we manage projects is so strongly impacted by the way we budget them.

BUDGETING DIFFERENCES

Project budgeting differs from functional budgeting in four fundamental ways, repetitiveness, basis, risk, and type of budget. Each of these is discussed below, along with comparisons of the implications in practice.

Repetitiveness

Functional budgets deal with familiar repetitive work; project budgets deal with non-repetitive, unique work efforts.

Differences. Functional budgets are calculated from a base of work experience. We've done the work for years, over and over, and we know it thoroughly. We use that knowledge, coupled with any expected change in work volume to calculate resource requirements for the coming period.

In contrast, at the point most business project managers are asked to estimate their project budgets, they have only the vaguest idea of the work that needs to be done. They rarely have a detailed description of what the client wants or a detailed, approved design specification before budget projections are required. Writing about computer software development, David King says, “often, if not always …, the system never becomes fully satisfactory to the user because the user never fully defines what the specifications are.” And in his list of what he calls preventable reasons for project failure, number one is “Lack of clear, understandable specifications. “ [2] The project team works with only a sketchy description of requirements, which from the point of view of the business manager may be understandable. Especially when the client is one of the functional managers. The costs of identifying client requirements are considerable and creating the design specification can certainly be considered part of the project work. I can almost hear some executive manager ask, “How can we determine whether we should make the analysis and design investment until we know how much the project is going to cost?” Good question. Almost as good as: “How can we determine what it's going to cost until we know precisely what the client wants and how we are going to go about it?” A veritable quandary.

Figure 1. The Business Project Budgeting Process

img

Unfortunately instead of explaining the impossibility of forecasting the cost of unspecified work, project workers who have no “formal” project experience, forge ahead as if such demands are perfectly reasonable. Partly because they need their jobs, but also partly because management presents their requests with such authority, many of them secretly believe they are lacking in some basic talent. After all, if management thinks they ought to be able to make such a prediction, they should clearly be able to do so. It's bad enough that the project team is expected to come up with budget projections before they have a definite idea of the problem (see Figure 1); what is really ridiculous is that they are then challenged to turn their highly questionable predictions into reality. Hardly the way to produce the highest quality deliverables in the shortest time for the least cost.

Making comparisons. How are these issues addressed in the formal project world? In a much more pragmatic way, I can assure you.

No formal project is ever budgeted in detail before requirements are specified. In the formal project world, most project work is carried out by contractors. And since each phase of the development life cycle requires a different kind of work, there is usually a different contractor for each of those phases; people who specialize in the feasibility study, the environmental impact study, the requirements definition, the design, and the construction or development (see Figure 2).

Each phase of the life cycle is treated as a separate project and budgeted independently. To be sure, there is a total project budget calculated at project inception, but as each stage is completed, the total budget is revisited and revised if necessary. The construction phase of the project—the work most impacted by project management techniques—is budgeted from an extremely detailed set of specifications. When the Department of Defense designed their system of 35 project management criteria known as C/SCSC, one entire section of five criteria was devoted to “Organization,” to allow for the detailed identification of all work efforts, and the specific persons responsible for performance [3].

The habit of the business community of expecting project teams to come up with accurate cost and schedule estimates before either requirements or specifications have been produced is self-defeating:

  • In cases where estimates are unnecessarily high in an attempt to be safe, teams are placed in the position of nevertheless using up all available resources rather than looking foolish by underrunning their own estimates. Some teams have even had the unfortunate experience of being honest with an unsympathetic management. In a rash attack of loyalty, they report that they overestimated the work and are therefore able to finish in less than budgeted time. From then on, they find their credibility questioned and subsequent estimates reduced as a matter of course. This approach escalates cost, ensuring that all projects cost as much as workers can convince management to pay for them, forcing workers and management into adversarial rather than supportive relationships.
  • In cases where estimates are not sufficient, either because the work was underestimated or because management reduced the estimates, teams will either cut quality surreptitiously or work unrecorded extra time in order to live up to management expectations. The system that forces workers to continuously compromise project quality, which we know happens all the time, is seriously flawed and should be considered for careful examination. Allowing (or forcing) people to work unrecorded extra time, on the other hand, hides the real cost of the work and sabotages all future efforts to budget accurately.

Basis

Functional budgets rely on performance history; project budgets rely on estimates.

Differences. Functional budgets are normally arrived at by examining past performance records, projecting changes in business volume (up or down) and calculating budget requirements for the coming period (see Figure 3).

Clearly, actual performance records are a key element in the calculation of the functional budget. Project budgets are arrived at by examining new requirements, estimating the required workload, projecting a risk factor, and calculating budget requirements (see Figure 4).

While the functional budget process uses hard data as the basis of its projections, almost every item in the project budget is either lacking in definition or information. Attempts to estimate the project workload are often both incomplete and inaccurate:

  • They are incomplete because work requirements are not yet detailed.
  • They are inaccurate because they are not based on tested performance history Few businesses have taken the trouble to collect project performance data in enough detail to use as the basis of project budget estimates.

Figure 2. The Formal Project Budgeting Process

img

Figure 3. The Functional Budgeting Process

img

They are guesses. Which wouldn't be too bad if the system allowed project management to track actual performance and use performance data to improve such guesses in the future, but that's not the way it works. Project teams are required to make their estimates. So right off the bat they do everything they can to protect themselves; which invalidates any attempt to collect bona fide performance data.

Figure 4. The Business Project Budgeting Process

img

Figure 5. The PERT Estimating System

img

Making comparisons. In the formal project world, budgets are calculated in one of two ways: either they use tested performance data, which is an accepted standard, or they use the estimating approach used in the PERT system. There is an abundance of performance data available for a number of formal project industries, since many industries have tracked performance for years. As a consequence formal projects are able to draw upon accepted performance standards at the task level for almost any type of effort by specific industry. In some cases, performance standards are even specific to geographic location. The system we know as CPM, Critical Path Method, was conceived to determine the most effective time/activity relationship. It relies heavily on tested performance data.

Tom DeMarco notes, “The idea of predicting costs from historical data and observed statistical relationships is known as empirical cost projection. In most mature technical fields, empirical projection is the prevalent technique for predicting future results. In some fields (extrusion, transmission repair, masonry, and others), empirical projection methods are so refined that they form the basis of a hard quotation system and overruns are rare enough that the quoter can usually afford to swallow them.” [4] However, when the Polaris missile project came along in 1957, containing a large number of technical tasks for which no historic data was then available, the PERT system was developed.

PERT or Project Evaluation and Review Technique, is a project tracking and management system specifically designed to more accurately control large, complex projects. Since it focuses on handling large amounts of integrated data, PERT incorporates a mathematical system designed to identify, track, and accommodate risk and uncertainty. It uses a specific estimating approach created to provide for a range of possibilities. It uses three time estimates to convey the range of durations that the activity may require for completion, i.e., the uncertainty. The original PERT based the probability calculation only on the critical path activities. These deficiencies are overcome by the use of Monte Carlo simulation, which considers all activities in the network in calculating probabilities.

In addition, there area variety of ways to estimate the variations in durations. one of these, “Range Estimating,” has proven effective in a variety of settings. The process begins by identifying a range of probable costs, extending from most optimistic to the most pessimistic estimate, for each work package. This is done in a brainstorming session by a group of experts who understand the work but will not be responsible for doing it. They examine each task and agree on the range estimates. The most likely cost of the work is arrived at by applying mathematical probabilities to the estimates (see Figure 5).

It is important to note, however, that even such “scientific” estimating techniques are only stopgap measures. The business world needs to begin keeping detailed performance history, like the formal project world, so that we may someday graduate from the “guessing” game to a well-tested system that calculates probable cost accurately within stable and acceptable limits.

Risk

Functional budgets are low risk; project budgets are high risk.

Differences. The fictional budgeting world does not deal easily with risk and uncertainty. It never had to. For years, functional work was relatively stable; at least until the introduction of computers. Functional budgets, therefore, are prepared yearly, and while they are reviewed periodically during the year, they are not normally increased or decreased in seesaw fashion to accommodate changing workloads. Once approved, the functional budget is a total constraint. As a matter of fact, managers who fail to request enough budget, are often “forced” to hire consultants rather than increase staff because of the difficulty of adjusting the budget midstream. Even those who anticipate a risk factor have no way of including “possible but not definite” items in their budgets.

In the past decade, some corporations have implemented a process called “revised forecasting,” where budgets are revisited quarterly and revised if necessary. While this is certainly an improvement, it is, first of all, not done frequently enough and, secondly, is usually an attempt to reduce expenditures rather than expand or contract to accommodate shifting market conditions.

Projects, by their nature, are relatively high-risk efforts. Even when we have detailed requirements and specifications, the probability of discovering hidden complexity or of needing to accommodate scope and definition changes is very high. As compared to most functional department budgets, project budgets need to be able to expand and contract like balloons to reflect the workload in the current phase of the project.

Making comparisons. How does the formal project world deal with the risk and uncertainty they most certainly face? They design specific planning and control mechanisms around the situation, known as top-down, bottom-up, rolling-wave budgeting.

Top-down budgets are those broad, loosely supported financial projections used by senior management to set the financial goals of the organization. According to Quentin Fleming in Cost/Schedule Control Systems Criteria [3], “… top-down budgets should be subsequently reinforced by more detailed bottom-up financial estimates, which would serve to verify that the gross plans of management can be met.” Top-down budgeting approaches can be used successfully to form ballpark estimates of the entire development process, which gives management solid information for strategic decisions. That is, as long as such estimates are not cast in concrete. And top-down budgets can even act as limitations, such as “this is the most we are willing to spend on this project.” In those cases, the bottom-up estimate must fit comfortably—well within the limits of the top-down budget.

Figure 6. Rolling Wave Estimating

img

Bottom-up budgets are the results of a detailed work breakdown and are the sum of the individual cost accounts required at every level of the breakdown structure. Not infrequently, the bottomup detailed budgets bring into focus the shortcomings of the top-down approach, which are “often overly ambitious and sometimes unattainable,” Fleming says [3]. The top-down figure is likely to be understated because it tries to represent too large a segment of future behavior. The bottom-up approach, on the other hand, is only useful on small pieces of the total effort since it depends on complete and accurate details (refer again to Figure 2). Neither top-down nor bottom-up budgeting by itself is reliable enough to guide most total development efforts. For this reason, the rolling-wave approach is used.

The rolling-wave approach imposes short-term review periods on long-term projects (see Figure 6).

This approach allows project budgets to expand or shrink as necessary. For example, in a project of more than one year's duration, while the entire project is supported by atop-down estimate, only the most immediate few months (fourto-six is common) is fit into a detailed bottom-up cost estimate. As each milestone is achieved, the window of detailed budgeting is extended. This approach not only continually identifies the details for the nearest months, it also allows for continuous correction to the total project budget as more information is available.

Figure 7. Appropriate Project Planning

img

Business managers familiar with functional budgeting methods will find rolling-wave project budgeting far more disruptive than they are used to because it requires almost continuous budget adjustments. But that's exactly the point. Project budgets must be examined carefully and frequently so that they can be expanded or reduced as necessary.

Type of Budget

Functional budgets are limitations; project budgets need to be targets within limitations.

Differences. Current budgeting processes do not allow for setting targets within limitations, which is exactly what the project budget needs to be. When we do our project planning we ought to have targets that stretch our capabilities, those which, while entirely possible, still make us hustle a bit. Continuous improvement is a solid concept and should certainly be incorporated into our project budgeting system, but as long as project teams are penalized for not coming in on budget, we'll never know what true performance is. Continuous improvement is impossible in an environment where workers are afraid to report the truth.

Functional budgets are generally treated as limitations, as in “this is the most you have to spend,” and while the functional manager tries not to overspend this limit, he or she also works very hard not to come in too far below it. The functional industrial mode is one that developed over many years. It evolved in a setting that encountered only minor changes in either the product itself or the methods of producing it. In those more predictable times, when businesses seemed always to improve over last year, the “use it or loose it” budget structure made some sense, but recently its applicability is being questioned, even for functional budgeting. It was never appropriate to the project world.

As long as project budgets are considered limitations, instead of trying to identify the true cost of project work, we in the business world try to ensure successthat is, we calculate a number that gives us a near 100 percent chance of getting finished on time and within budget. It is this attitude that interferes with our ability to budget correctly for project work since it forces us to try to make our prediction come true. We ought to be trying to identify a figure that will more nearly predict “actual” performance while at the same time setting aside sufficient resources to cover uncertainty and risk (see Figure 7).

Project budgets, which should be treated as targets, as in “this is what we will aim for,” are too often treated as predictions, as in “this is what we will hit.” Big mistake. Even when management suspects that project budgets have a high probability of being insufficient, they still consider it a failure when the team fails to deliver as promised. Yes, project teams should be challenged by targets that make them stretch, but they should also be able to complete the project successfully, even if they overspend the target budget—as long as they come within acceptable range. Responsible management needs to fashion a budgeting system that allows for range estimating and creates a “success environment” for project work. This can be accomplished by publishing project budgets which name both the limit of resources that will be spent on a given effort as well as the target we wish the project team to shoot for.

Having dealt with fictional budgets for so long, the average business manager truly believes the project team ought to be able to predict project schedule and budget with at least a 90-95 percent reliability 100 percent of the time. A highly unreasonable expectation. In the software development world, there are several computer programs developed specifically to estimate project budgets. Barry Boehm, author of one of the more successful systems says, “A software cost estimation model is doing well if it can estimate software development costs within 20 percent of the actual costs, 70 percent of the time, and on its own home turf (that is, within the class of projects to which it is calibrated) [5]. On the other hand, Harold Kerzner claims that there is “The definitive estimate (which) is prepared from well-defined engineering data including (as a minimum) vendor quotes, fairly complete plans, specification, unit prices, and estimate to complete. The definitive estimate, also referred to as detailed estimating, has an accuracy of plus or minus 5 percent” [6]. It should be noted that definitive estimates have only been tracked in those industries which have an abundance of tested performance data.

The fact that most business budgeting systems do not provide contingency funds, which can be returned to the corporation without penalty if they are not used, is a strong deterrent to effective project budgeting. Instead of penalizing or embarrassing teams that fail to make their targets, we need to reward teams that produce high-quality project deliverables. The more the project organization supports the gathering of reliable performance data, the sooner our chances of setting truly useful targets.

At best, project budgeting is a risky business. When it is approached as if we were budgeting for a stable business function, it is doomed to failure. The sooner we accept the fact that project budgets need to be range estimates, the faster we will be able to design budgeting systems that help our project teams succeed instead of asking them to work within inappropriate systems that remotivate them and force them to work against the corporation's interest. Project budgets have to be achievable targets within reasonable limits.

Making comparisons. How does the formal project world deal with the issue of targets within limitations? In the first place, not every phase of the project is contracted on a fixed-price basis. The first several phases are usually budgeted on a time-and-material or cost-plus basis, depending on the specificity of the job. It is the construction phase that has a “fixed” price, but again, I wish to emphasize that the construction phase is entered with a very detailed set of specifications, so the contractor knows exactly what work needs to be done.

The construction contractor estimates the project budget by calculating the cost of each line item in the Request For Proposal (the detailed specification of project deliverables). These costs are based on standards developed for the industry and are readily accepted as valid by both the client and the project manager. In addition, the contractor does not work with a single figure that serves as both the target and-the limit. Formal project budgets usually consist of:

  • The work budget (also known as the allocated budget), which is an accumulation of all expected costs. Every item in the work budget is allocated to a specific cost account.
  • The contingency budget (also known as the unallocated budget), which is generally calculated at 10-15 percent of the project budget. Contingency budgets are normally approved but not allocated to specific cost accounts and are used at the project manager's discretion. It is not unusual for bonus payments to be provided from unused contingency funds.
  • Management reserve is another 10-15 percent of the project budget that is available but not yet approved for use by the project manager. The project manager has access to management reserve only by justifying requests for more budget to management's satisfaction.

The Performance Measurement Baseline identified by the Department of Defense (DOD) includes both the work budget and the contingency budget [3]. It is the baseline against which project performance is measured to ensure contract accomplishment. Most project managers, however, use the original work budget as their target and consider themselves successful indeed when they are able to come in on or under budget. That's when their profit is greatest. However, they don't start losing money until both the contingency budget and the management reserve are used up.

CONCLUSION

The differences between project and fictional budgeting named here are only the most obvious. They are not the whole story. Nor will an appropriate budget system cure all the ills currently plaguing the business project world. Project success depends on a number of other issues in addition to the budgeting approach, such as quality standards, teamwork, managing expectations, and understanding the tools and techniques of project management tracking systems. But if all the other factors were perfectly understood and incorporated, success would still not be attainable so long as the budgeting system, the way we allocate time and money, is inappropriate.

However, we are headed in the right direction. Many companies are currently moving to a new functional cost management system called Activity-Based Costing. ABC, as it is known in financial circles, is a new system of costing all corporate expenditures. Instead of collecting costs by categories such as labor, materials, or equipment, costs are collected by activities-similar to project cost accounting. This gives executive management more useful information for decision-making and supports a financial tracking system called life cycle costing. ABC was closely followed by ABB, Activity-Based Budgeting. Together with zero-based budgeting, these three form the basis of what has become known as ABM, Activity-Based Management. ABM adjusts the familiar functional organization so that it is more compatible with project efforts and the financial data reported from the project management effort. However, even if your organization currently seems inexorably tied to a Chart of Accounts system, there are steps you can take to improve project performance.

CREATING A SUCCESS ENVIRONMENT FOR PROJECT WORK

How do we begin changing decades of behavior? Slowly. The change begins with understanding, and even though behavior must follow, the majority of setbacks in any directed evolution are caused by not understanding the basics. Don't expect to solve all project budgeting problems immediately, but here are some suggestions that will help you get on the right track.

1. Institute a top-down, bottom-up, rolling-wave budget system for the project function as well as for individual projects.

2. Create a project budgeting system that includes contingency budgets as well as work budgets; that is, targets within limitations.

3. Rewrite the agreement between the project function and the corporation to allow the project function to return unused budget (if any) at the end of the year and be rewarded for doing so.

4. Use a development life cycle to separate the phases of your projects and treat each phase as a separate “unit with its own targets and limitations.

5. Create a generic Work Breakdown Structure, or other means, to facilitate collecting performance data for standard tasks.

6. Create a project performance database and begin collecting actual hours expended via a non-threatening collection system.

7. Separate the estimating from the doing. Have task estimates performed by estimating professionals using adjusted performance data. This will allow for more objective estimates.

8. Make estimators responsible for continuously fine-tuned estimates.

9. Create a realistic reward system designed to deal honestly with the risk and uncertainty of project work.

10. Institute and enforce a standard project “post mortem” analysis to identify problems with the system and allow for continuous improvement.

Most of all, successful project management depends on a supportive partnership between management, clients, and project teams.

REFERENCES

1. Kezsbom, Deborah S., Donald L. Schilling and Katherine A. Edward. 1989. Dynamic Project Management: A Practical Guide for Managers and Engineers. New York: John Wiley &Sons.

2. King, David. 1992. Pr-eject Management Made Simple. Englewood Cliffs, NJ: Yourdon Press.

3. Fleming, Quentin W. 1988. Cost/Schedule Control Systems Criteria: The Management Guide to C/SCSC. Chicago, IL: Probus Publishing Co.

4. DeMarco, Tom. 1982. Controlling Software Projects. Englewood Cliffs, NJ: Prentice-Hall.

5. Boehm, Barry W. 1981. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall.

6. Kerzner, Harold. 1989. Project Management: A Systems Approach to Planning, Scheduling, and Controlling. New York: Van Nostrand Reinhold.

img

Mane Scotto has been a trainer and management consultant for 14 years. She is a frequent come leader for the American Management Association, Columbia University, Frost and Sullivan – Western Europe, and Penton Learning Systems.

She recently co-authored a new seminar for the American Management Association titled “Achieving Excellence in MIS Through Total Quality Management,” and is the author of “Budgeting and Cost Management Techniques for Project Managers,” another new addition to AMA's curriculum.

A member of the Association for Systems Management, Quality Management Association, and PMI, Ms. Scotto is highly involved in developing the New York PMI Chapter into a vital, energetic association of project-involved professionals.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

Volume XXV March 1994 Number 1

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.