Activity-Based Budgeting Aims for the Right Target

At a conference of IT financial managers recently, I spent an hour with Doug, a self-proclaimed authority on activity-based budgeting (ABB). He patiently explained ABB to me, in simple terms that even I could understand.

First, all costs are assigned to “activities”—things people do. Then, these activities are assembled into the products and services that the organization delivers to clients outside the organization, e.g., the products/services IT sells to the business units.

BENEATH THE BUZZ

You can read more columns by N. Dean Meyer on CIO.com.

Costs, like staffing and infrastructure, may be associated with a single activity, or apportioned among activities. And activities become cost pools that are apportioned among the external products and services.

I got it.

The Destination

The destination, or goal—associating all costs with an organization’s products and services—is right on. In ITIL (IT Infrastructure Library), it’s called service-based costing. In the federal government, it’s called program-based budgeting. In the real world, it’s simply called common sense.

Submitting the traditional budget for expenses (compensation, travel, training) just begs for micromanagement. “Hey, you don’t need all that training!” Note that the executive committee doesn’t really know how much training you need to run your business. But what else have you given them to talk about!?

Worse, it doesn’t permit the company’s executives to make sensible resource allocation decisions. Budgets should be allocated based on the investment opportunities at hand. But you can’t calculate the ROI of compensation, travel and training; you can only measure the ROI of investments in products and services.

Lacking an understanding of what the business will get for its money, executives are forced to make budget decisions that are arbitrary, such as last year’s budget plus/minus a few percent, or budgets based on current headcount rather than the demands of the business. This is no way to maximize strategic alignment or shareholder value!

Perhaps most insidious, traditional budgets provide no basis for demand management (such as a client-driven portfolio management process). Clients are apt to say, “You got all that money. So why can’t you do everything I want for free!?” And you have no way to explain what is, and is not, funded by your budget.

Clearly, the right answer is a budget that describes the cost of your products and services. Then, when budgets are tight, the business must decide what it will and won’t “buy” from your organization. Purchase decisions are based on business strategies and economics. Clients’ expectations will then match your available resources. And you don’t have to cut corners, back off on training and innovation and overwork your people to attempt to satisfy virtually unlimited demands.

The Path: Entrepreneurship

Doug and I quickly agreed on the destination—a budget and a product/service catalog that documents the full cost of IT’s deliverables. The trouble began when I started probing him on the path.

I’ve spent 25 years preaching the business-within-a-business paradigm, where every little group behaves like an entrepreneurship, recognizing that it’s there to “sell” products and services to customers. Customers are not just clients out in the business units. I pointed out to Doug that some groups in an IT department are there to serve customers who are within IT, and many serve both internal customers and clients.

So, I suggested, instead of attaching costs to activities, how about we attach all costs to products/services—both internal and external? Then, costs can flow through the value-chain until they ultimately end up on the external products/services.

Doug’s answer was abrupt: “That’s not ABB,” he said.

But in the spirit of customer focus and entrepreneurship, I protested, don’t you want everybody to be accountable for their products/services, not just the motions they go through to make them? The word “activities” implies means, not ends. All we have to do is define the concept of activities as equivalent to internal products/services, and ABB would be consistent with the business-within-a-business paradigm.

“No,” Doug answered. “The only thing that really counts are the products and services sold to clients in the business. Everything else is just an activity done to produce those external products/services.”

By his adamant focus on the language of activities, Doug created two classes of citizenship: those who sell to clients (the “important” functions within the organization), and those who simply do activities that are somehow incorporated into those products (the second-class citizens).

In this strict definition of ABB, groups who serve customers within the organization don’t have to be customer focused, don’t have to be entrepreneurial and don’t have to accept accountability for their product lines.

The Path: Teamwork and Accountability

I was discouraged that I couldn’t get Doug to see that the concept of ABB could be applied, and with a small tweak in the language, we could still treat everyone as an entrepreneur. But I thought I’d try another angle.

In the business-within-a-business paradigm, every external product/service is produced by a “prime contractor.” For example, an enhancement to an application is sold by the applications engineering function, while applications hosting is sold by the computer service bureau (the operations group).

In this world of business, like in the real world, teams form when a prime contractor subcontracts with peers for component products and support services. For example, an applications engineer may subcontract with an information engineering group for a data model, with a project-management group for project management support, and with the service bureau for installation into production. Similarly, service-delivery teams form through prime-sub relationships. An e-mail entrepreneur would subcontract for computer time, network services, storage and help-desk support.

In this way, teams form automatically. Individual accountabilities are clear, as is accountability for the whole (the prime). And there’s a clear chain of command, from prime to sub and perhaps to subs of subs, such that differences of opinion can be resolved within each team. Self-forming and self-managing teams are the essence of high-performance teamwork.

How is this treated in ABB? As Doug described it, a number of groups may be responsible for activities that go into a product/service, but they’re all just apportioned and added together. There’s no concept of a prime with subcontractors.

“Everyone is accountable for a given product?” I asked.

“Well, I suppose you could pick one of them and make them accountable, but that’s outside the scope of ABB,” was Doug’s answer.

ABB, in its strict interpretation, makes everybody accountable for going through the motions, but nobody accountable for end results. And there’s no contribution to teamwork in this vision of ABB; it’s strictly an accounting technique.

The Path: Value Chains

From a technical viewpoint, ABB has another flaw. Activities become cost pools, which are then allocated among the external products. It’s a simple, two-step process. But in real life, some of those activities support other activities—the products sold to others within the organization. And these, in turn, may support both external and internal products. And so on….

For example, it would be tempting to assign the costs of infrastructure engineering to the infrastructure-based services (like e-mail and applications hosting) which are sold to clients. But remember that some infrastructure engineers contribute to applications project teams. And some infrastructure services (like e-mail, network services, shared storage) are consumed internally by groups that serve both clients and peers within IT.

In real life, there’s a complex web of customer-supplier relationships inside any organization. Allocating the costs of all activities directly to external products ignores these internal value chains.

In doing so, it introduces distortions in the cost which are not measured and may be significant. For example, if all infrastructure engineering is embedded in the costs of infrastructure services, and all of that is charged to clients, then the infrastructure services will appear more expensive and applications engineering (which uses both the infrastructure engineers and some of those infrastructure services) will get off scot-free.

Religious Zeal

It became clear that his religious zeal would not allow Doug to consider any modification to the language of ABB. ABB means costing activities. That was that!

What a shame. The basic concepts are there. A small tweak in language combined with a more robust planning process, and ABB would be a powerful method of costing and of building a vibrant, customer-focused, entrepreneurial, accountable, team-oriented organization.

I guess I can’t call the process of costing everybody’s products/services ABB. But let’s not throw out the baby with the bathwater; let’s take from ABB the good and leave the bad.

How Costing Should Work

Associating all costs with products/services is not only right; it’s the basis for all sensible resource governance processes. Everybody should understand their products/services (service catalog) and their customers, both within the organization and out in the business units, and the full costs of each.

Direct costs are easy to assign to those products/services. Indirect costs within each group must be amortized into that group’s unique products/services. Then, the cost of internal products/services should be transferred to the internal customer, and spread over that group’s products/services. At this step, costs flow through the web of internal support relationships until they ultimately end up on the external products/services.

Finally, primes and subs add up their full costs to get the total cost of each external product/service.

The recently released Full-Cost Maturity Model explains this process, at five levels of maturity, with all the details needed to assess where you are, the gaps and what you need to do to cost your products/services.

A full-cost process based on the business-within-a-business paradigm produces a product/service catalog with costs, a budget with the costs of proposed products/services and chargeback rates. It achieves the same purpose as ABB (and more) and it’s entirely consistent in concepts. But the language of business improves the accuracy of the costing and contributes to organizational dynamics in a powerful way.

Let this be a lesson to the zealots—all zealots, be they proselytizers of ABB, ITIL, project management, Six Sigma or whatever: Obsessive focus on the means may weaken otherwise valuable ends.

You can read a version of this article on the author’s website with links to other Beneath the Buzz columns, relevant white papers, books and other resources.

Dean Meyer coaches CIOs on organizational, political and leadership issues. He listens, and offers perspective with his compelling business-within-a-business paradigm and the common sense built over 35 years in the IT industry. He works with you to plan practical solutions, drawing from a wealth of implementation experiences and proven systemic change processes. For a no-obligation get-to-know-you chat, contact his office at ndma@ndma.com or 203-431-0029. For more on Meyer’s work, see www.ndma.com.