Why is activity based costing vulnerable to poor application and project management. How can this be avoided? By Ross Webb, independent consultant specialising in financial management and financial control.
In an article in November 2006 Insight, I gave an illustration of a typical activity based costing (ABC) implementation.
In this article, I will explore some key aspects of achieving successful and robust outcomes. I will also ask why is it that, despite best efforts to manage projects, the results can be open to criticism?
Like any systems development, an ABC implementation is vulnerable to poor application and project management. Some issues are particularly pertinent to ABC. These include data quality, upfront agreement on output goals, managing scope creep, managing expectations and differential product analysis.
Benefits and successes
The success of ABC has led to a growing number of organisations implementing their own programmes. Often, ambitious goals have been set. These goals can be based on what is believed to have been achieved elsewhere or on a ‘blue sky’ approach.
The first issue is that ABC systems are only ever as good as the quality of the data available.
This is not a groundbreaking point. The concept of GIGO (garbage in, garbage out) has been around for longer than most of us care to remember.
Senior management often assumes that the appropriate data is readily available. More often than not the data does exist. The problem is accessing it. Most organisations have vast amounts of data stored in an array of systems, but they are not very good at getting to it and turning it into meaningful information.
Projects are typically sold to senior management with brief scopes detailing attractive goals and clearly defined time and cost parameters.
These scopes are often hastily prepared with little study of the data systems conducted. The result is that glaring disconnections between goals and data availability are revealed when the data collection stage begins.
Driver data
The lifeblood of ABC system creation is driver data.
Driver data shows you the detailed volumes of items that drive costs. You need this to drive costs from resources through to activities, and onto products and customers. The data quality will determine the reliability of your activity list, and product list in terms of granularity.
This is the heart of ABC, the real nuts and bolts. Too often, too little attention is paid to getting quality driver data. You have to keep saying to yourself that you are trying to implement an activity based system, not an allocation system. The quality of the driver data will determine the quality of the activity costs, product costs and customer costs that can be produced.
You now face the question of tradeoff, between effort spent on obtaining quality driver data and speed of delivery.
Key questions
One of your first questions should be ‘What do we want to do with the output?’ This should give a clear indication of the level of granularity (for example, strategic, tactical and operational) for reporting and the level to which you need driver data.
For example, suppose senior management said that they wanted to see the cost of each of the main stages in the company’s value chain. This might be thought of as not needing particularly robust data at a detailed task level. But what if management also asked for the cost of the processing substage and reworks?
In this example, reworks would be the time taken to repair trades due to incorrect or incomplete information being entered on the original trade. Reworks would need a greater level of detailed analysis along with more appropriate driver data. This example shows what is meant by the demands from driver data depending on the granularity required.
People will be shouting 'scope creep!' at this point. They are right. Adding a more detailed substage midway through a project will have impacts on time and cost. This needs to be clearly explained to management.
Interestingly, scope creep is a double edged sword. On one hand, it changes the original remit and often means that further work needs to be carried out. On the other, it shows that management is taking an active interest in the ABC project and its outcome. It is critical to ensure that management fully understands the implications of new requirements.
Expectations
When you start mapping out the activities that make up your company’s value chain, you have the chance to revisit and lock down expectations of the final model. This is the time to reign in the blue sky thinking and talk about what you think will be achievable.
Blue sky thinking isn’t bad in itself. However, management will want the project delivered, so there must be a good element of achievability. This is why you really need to involve the wider organisation at this stage. Management will be more easily persuaded further to changes down the line if they are confident that their team members have been actively involved and consulted.
Product weightings
Product weightings are used to differentiate between the resource - and therefore the cost - of processing one unit of two separate products from one activity.
Let’s say that an activity called ‘documentation’ is performed on all products. If the documentation activity takes twice as much time for product A than it does for product B, then this should be reflected.
Product weighting is about trying to measure the amount of effort and cost consumed by a single unit of product. This differential is achieved in part by the granularity levels of the activities. If product A is the only product to consume activity X, then by definition you are building in an element of product differential.
An important additional part of this is the product weightings. You can find information to determine this from a variety of sources, including systems data, alternative driver sources, time recording systems and manager’s opinion. Problems arise when time is not taken to investigate and map out product weighting.
The key to successful ABC implementation is engagement. The most important stage of any implementation is engagement with the business. Senior management may not be responsible for the build, but they are responsible for the end result. The business must take ownership of problems. You need to facilitate the process that makes the business comfortable with modifications.
Contact rosswebb@hotmail.com.