In this section, we look at the details of the process of estimating costs and some dangers of arbitrary cuts in the project budget. We also describe and illustrate the difference between activity budgeting and program budgeting.
1. Work Element Costing
The task of building a budget is relatively straightforward but tedious. Each work element is evaluated for its resource requirements, and its costs are then determined. For example, suppose a certain task is expected to require 16 hours of labor at $10 per hour, and the required materials cost $235. In addition, the organization charges overhead for the use of utilities, indirect labor, and so forth at a rate of 50 percent of direct labor. Then, the total task cost will be
$235 + [(16 hrx $10/hr) x 1.5] = $475
In some organizations, the PM adds the overhead charges to the budget. In others, the labor time and materials are just sent to the accounting department and they run the numbers, add the appropriate overhead, and total the costs. Although overhead was charged here against direct labor, more recent accounting practices such as activity-based costing may charge portions of the overhead against other cost drivers such as machine time, weight of raw materials, or total time to project completion.
Direct resource costs such as for materials and machinery needed solely for a particular project are usually charged to the project without an overhead add-on. If machinery from elsewhere in the organization is used, this may be charged to the project at a certain rate (e.g., $/hr) that will include depreciation charges, and then will be credited to the budget of the department owning and paying for the machine. On top of this, there is often a charge for GS&A (general, sales, and administrative) costs that includes upper management, staff functions, sales and marketing, plus any other costs not included in the overhead charge. GS&A may be charged as a percentage of direct costs, all direct and indirect costs, or on other bases including total time to completion.
Thus, the fully costed task will include direct costs for labor, machinery, and resources such as materials, plus overhead charges, and finally, GS&A charges. The full cost budget is then used by accounting to estimate the benefits (e.g., cost savings, profits) to be earned by the project. The wise PM, however, will also construct a budget of direct costs for his or her own use. This budget provides the information required to manage the project without being confounded with costs over which he or she has no control.
Note that the overhead and GS&A effect can result in a severe penalty when a project runs late, adding significant additional and possibly unexpected costs to the project. Again, we stress the importance of the PM thoroughly understanding the organization’s accounting system, and especially how overhead and other such costs are charged to the project.
Of course, this process can also be reversed to the benefit of the PM by minimizing the use of drivers of high cost. Sometimes clients will even put clauses in contracts to foster such behavior. For example, when the state of Pennsylvania contracted for the construction of the Limerick nuclear power generating facility in the late 1980s, they included such an incentive fee provision in the contract. This provision stated that any savings that resulted from finishing the project early would be split between the state and the contractor. As a result, the contractor went to extra expense and trouble to make sure the project was completed early. The project came in 8 months ahead of its 49-month due date and the state and the contractor split the $400 million savings out of the total $3.2 billion budget.
2. The Impact of Budget Cuts
In the previous chapter on planning, we described a process in which the PM plans Level 1 activities, setting a tentative budget and duration for each. Subordinates (and this term refers to anyone working on the project even though such individuals may not officially report to the PM and may be “above” the PM on the firm’s organizational chart) then take responsibility for specifying the Level 2 activities required to produce the Level 1 task. As a part of the Level 2 specifications, tentative budgets and durations are noted for each Level 2 activity. The PM’s initial budget and duration estimates are examples of top-down budgeting. The subordinate’s estimates of the Level 2 task budgets and durations are bottom-up budgeting. As we promised, we now deal with combining the two budgets.
We will label the Level 1 task estimate of duration of the ith task as t, and the respective cost estimate as r , the t standing for “time” and the r for “resources.” In the meantime, the subordinate has estimated task costs and durations for each of the Level 2 tasks that comprise Level 1 task i. We label the aggregate cost and duration of these Level 2 activities as r’ and t’, respectively. It would be nice if r equaled r’ but the reality is rarely that neat. In general, r ^ r’. (The same is true of the time estimates, tt and t’.) There are three reasons why this happens. First, jobs always look easier, faster, and cheaper to the boss than to the person who has to do them (Gagnon and Mantel, 1987). Second, bosses are usually optimistic and never admit that details have been forgotten or that anything can or will go wrong. Third, subordinates are naturally pessimistic and want to build in protection for everything that might possibly go wrong.
It is important that we make an assumption for the following discussion. We assume that both boss and subordinate are reasonably honest. What follows is a win-win negotiation, and it will fail if either party is dishonest. (We feel it is critically important to remind readers that it is never smart to view the other party in a negotiation as either stupid or ignorant. Almost without fail, such thoughts are obvious to the other party and the possibility of a win-win solution is dead.) The first step in reducing the difference between the superior’s and subordinate’s estimates occurs when the worker explains the reality of the task to the boss, and r. rises. Encouraged by the fact that the boss seems to understand some of the problems, the subordinate responds to the boss’s request to remove some of the protective padding. The result is that r’ falls.
The conversation now shifts to the technology involved in the subordinate’s work and the two parties search for efficiencies in the Level 2 work plan. If they find some, the two estimates get closer still, or, possibly, the need for resources may even drop below either party’s estimate.
To complete our discussion, let’s assume that after all improvements have been made, r’ is still somewhat higher than r. Should the boss accept the subordinate’s cost estimate or insist that the subordinate accept the boss’s estimate? To answer this question, we must recall the discussion of project life cycles from Chapter 1. We discussed two different common forms of life cycles, and these are illustrated again, for convenience, in Figure 4-1. One curve is S-shaped, and the other is J-shaped. As it happens, the shapes of these curves hold the key to our decision.
If the project life cycle is S-shaped, then with a somewhat reduced level of resources, a smaller than proportional cut will be made in the project’s objectives or performance, likely not a big problem. If the project’s life cycle is J-shaped, the impact of inadequate resources will be serious, a larger than proportional cut will be made in the project’s performance. The same effect occurs during an “economy drive” when a senior manager decrees an across-the-board budget cut for all projects of, say, 5 or 10 percent. For a project with a J-shaped life cycle, the result is disaster. It is not necessary to know the actual shape of a project’s life cycle with any precision. One needs merely to know the probable curvature (concave or convex to the baseline) of the last stage of the cycle for the project being considered.
The message here is that for projects with S-shaped life cycles, the top-down budgeting process is probably acceptable. For J-shaped life-cycle projects, it is dangerous for upper management not to accept the bottom-up budget estimates. At the very least, management should pay attention when the PM complains that the budget is insufficient to complete the project. An example of this problem is NASA’s Space Shuttle Program, projected by NASA to cost $10-13 billion but cut by Congress to $5.2 billion. Fearing a cancellation of the entire program if they pointed out the overwhelming developmental problems they faced, NASA acquiesced to the inadequate budget. As a result, portions of the program fell 3 years behind schedule and had cost overruns of 60 percent. As the program moved into the operational flight stage, problems stemming from the inadequate budget surfaced in multiple areas, culminating in the Challenger explosion in January 1986.
Finally, in these days of increasing budget cuts and great stress on delivering project value, cuts to the organization’s project portfolio must be made with care. Wheatley (2009) warns against the danger of focusing solely on ROI when making decisions about which projects will be kept and which will be terminated. We will have considerably more to say about this subject in Chapter 8.
3. An Aside
Here and elsewhere, we have preached the importance of managers and workers who are willing to communicate with one another frequently and honestly when developing budgets and schedules for projects. Such communication is the exception, not the rule. The fact that only a small fraction of software development projects are completed even approximately on time and on budget is so well known as to be legend, as is the record of any number of high technology industries. Sometimes the cause is scope creep, but top- down budgeting and scheduling are also prime causes. Rather than deliver another sermon on the subject, we simply reprint Rule #25 from an excellent book by Jim McCarthy, Dynamics of Software Development (1995).
Don’t Accept Dictation
I am amazed at the extent to which the software development community accepts bogus dictates, especially when it comes to scheduling. This astonishing passivity is emblematic of Old World behavior applied to New World problems. Given that it’s extremely difficult (probably impossible) for a team of committed professionals to create a schedule that even approximates the rate at which the product ultimately materializes, it’s utter madness that in many organizations the dates, the features, and the resources—the holy triangle—of a software development project are dictated by people unfamiliar with developing software. Too often people like “Upper Management” or “Marketing” or some other bogeymen conjure up the date. What’s worse, by some malignant and pervasive twist of illogic, otherwise competent development managers accept this sort of folly as standard operating procedure.
I have polled dozens of groups of development managers, and my informal data gathering suggests that somewhere in the neighborhood of 30 to 40 percent of all development efforts suffer from dictated features, resources, and schedules. It should be a fundamental dogma that the person who has to do the work should predict the amount of time it will take. Of course, if accuracy isn’t a goal, anybody can make foolish predictions.
In some ways, the root of all scheduling evil is that software developers and their managers abdicate their responsibility to determine the probable effort required to achieve a given set of results. The ultimate act of disempowerment is to take away the responsibility for the schedule from those who must live by it. To accept this treatment under any circumstances is no less heinous an act than imposing a bogus scheduling imperative on a team to begin with.
It’s easy to sympathize with the urge for control and predictability that this phenomenon manifests, but why on earth should such organizational goofiness persist in the face of what always follows, repeated software calamity?
Often people and organizations have a hard time learning from their mistakes. We tend to be a bit thick sometimes. Our diagnosis of what went wrong the last time can be utterly erroneous, and so we gear up to do it all again—without ever even beginning to experience the core insights required for successful software development.
This blindness is especially likely after a disastrously late software project. Many team members want desperately never to repeat such a death march, so they leave the group. As evidenced by their urge to survive, these people are often the most vital members of the team. The remnant is left lurching about in a fog of blame. Like the Angel of Death, Guilt visits every cubicle. The managers are choking on their own failure, so their ability to lead is smothered. The marketing people have been made to look foolish, their promises just so much gas, and cynicism creeps into their messages. The executives are bewildered, embarrassed, and angry. The customers have been betrayed yet another time.
Slowly the fog dissipates, and a modicum of hope materializes. New team members re-inject a measure of the lost vitality into the team, and new (or forgetful) managers take the helm. The technological siren seduces the group once again. The executives, chastened but unlearning, plunk down enough dough and tell the team when the new project must be done. The cycle repeats.
How is a person to cope with such folly? If you find yourself in such an organizational situation, how should you respond? Keep in mind that in an asylum, the sane are crazy. And in an organization in which irrationality prevails, the irrationality tends to concentrate the further up you go. Your situation might be hopeless because the extent to which you are viewed as crazy will tend to intensify in direct proportion to the power of the observer. You might be able to cope with irrational and self-destructive organizational values, but you’re unlikely to prosper in such a setting. A situation this gravely out of whack must be resolved, however. So you steel yourself and inform your dictators that, much as you would like to accept their dictates, you are unable to do so because reality requires otherwise. You remind them (tactfully) that their power is not magic, that their wishes don’t make software. You help them envision a future in which people are striving to meet their own goals, things they’ve proposed to do over a certain interval and things that have a chance of being done even sooner than anticipated.
You need to build schedules meticulously from the bottom up. Each person who has a task to do must own the design and execution of that task and must be held accountable for its timely achievement. Accountability is the twin of empowerment. The two together can create a reasonable software development plan.
Reprinted with the kind permission of Jim McCarthy, copyright holder, from Dynamics of Software Development by Jim McCarthy, Microsoft Press, Redmond, WA, 1995, pp. 88-89.
4. Activity versus Program Budgeting
Traditional organizational budgets are typically activity oriented and based on historical data accumulated through an activity-based accounting system. Individual expenses are classified and assigned to basic budget lines such as phone, materials, fixed personnel types (salaried, exempt, etc.), or to production centers or processes. These lines are then aggregated and reported by organizational units such as departments or divisions.
Project budgets can also be presented as activity budgets, such as in Table 4-3 where one page of a six-page monthly budget report for a real estate management project is illustrated. When multiple projects draw resources from several different organizational units, the budget may be divided between these multiple units in some arbitrary fashion, thereby losing the ability to control project resources as well as the reporting of individual project expenditures against the budget.
This difficulty gave rise to program budgeting, illustrated in Table 4-4. Here the program- oriented project budget is divided by task and expected time of expenditure, thereby allowing aggregation across projects. Budget reports are shown both aggregated and disaggregated by “regular operations,” and each of the projects has its own budget. For example, Table 4-3 would have a set of columns for regular operations as well as for each project.
Source: Meredith Jack R., Mantel Jr. Samuel J., Shafer Scott M., Sutton Margaret M. (2017), Project Management in Practice, John Wiley & Sons, Inc. 3th Edition.
I enjoy the efforts you have put in this, appreciate it for all the great posts.