In this second part to my series on Throughput Accounting, I'm going to explore the concept of Throughput, starting with a definition.
Every system has a goal it is trying to achieve. For most business processes this goal is revenue - money given to the organisation by customers due to sales of product or services. Given this, 'Throughput' is simply defined as a measure of the rate at which a system is achieving its goal. It is not a measure of profit or any indicator of efficiency, it is just a measure of flow.
Throughput is often expressed in terms of 'goal units'. In for-profit organisations, these units may be dollars of revenue. For non-profit organisations it may be expressed by another measure, such as patients successfully treated in a hospital emergency ward.
When dealing with monetary goal units, Throughput (T) is often measured as gross revenue from sale of a product (S) minus totally variable costs (TVC), which are only the costs that vary directly with the system output. In a manufacturing setting, TVC is often just the cost of raw materials. Thus T = S - TVC.
In the example from my last post, a company was producing 800 widgets per month. Their TVC, for materials, was $40 per widget. If those widgets were being sold at $50, the throughput per widget would be $10 and the system throughput is $8000 per month, or around $0.18 per minute.
In calculation, this is identical to the cost accounting metric 'contribution margin'. The contribution margin is used to determine the fraction of sales that contributes to offsetting fixed costs and can be used to disambiguate some decisions, such as the purchase price example from my previous post. As Throughput Accounting manages fixed costs separately, it is not required for this purpose - but has a much broader role.
It is important to note that Throughput is measured only as the ultimate achievement of a system, for example it may be the final sale of a product or service. It is not measured in terms of production of assets that will then be processed further to achieve the ultimate goal (eg. assets sold to achieve revenue). This is inventory - which I will discuss in a later post.
A good question is how to define Throughput in the context of a software delivery engagement. Ultimately the software system supports a business process which is in turn producing revenue - so it could be defined in terms of dollars made by the business. Pragmatically, however, it is more useful to define Throughput as the rate at which software additions and/or modifications are delivered into an environment where they can be utilised by the business process.
It is tempting to measure this rate in terms of 'business benefit' (possibly also in dollars), which is the ultimate goal unit of the entire business process. This is an important thing to focus on as often the best improvements can involve organisational changes as well as software changes. However, when the software production process is the organisation's constraint (as it often is) then we are focussed on just this process alone. In which case we need to use a 'goal unit' that is reflective of the amount of the work done to produce some change in software.
In Agile software delivery methodologies there is the concept of 'story point', which is simply a relative measure of the effort required to deliver a particular requirement. Given its relative nature, we can measure it over an arbitrary time period to determine the rate of delivery of story points, which we can use as Throughput. This is effectively the same as the Agile term 'velocity' and this comparison is useful for applying some TA concepts to software delivery. I'll return to this point in future posts...
Tuesday, July 22, 2008
Friday, July 18, 2008
Throughput Accounting
Let me declare today that I have a new enemy - Cost Accounting.
In 1981, at a conference of Management Accountants, Eliyahu Goldratt declared Cost Accounting to be "Enemy #1 of Productivity". In my work as a consultant for ThoughtWorks, I value productivity highly. Hence the enemy of my friend is also my enemy.
Goldratt, author of the popular business novel "The Goal", showed how traditional cost accounting easily and trivially leads intelligent managers and other decision makers to make bad decisions - decisions that have massive negative effects on performance and profitability. This was actually not surprising news, as the problems with cost accounting had been recognised. But Goldratt also proposed an alternative.
His alternative was titled "Throughput Accounting", and was described in the 1998 book by Thomas Corbett. It is an accounting model which does not focus primarily on local cost optimisation and instead focuses primarily on overall system throughput. Importantly, it does not attempt to allocate overhead costs across products and services.
Why is this important? Cost accounting attempts to allocate a companies fixed costs over a given time period to the products or services produced in that period. It enables managers to ignore the fixed costs and focus instead on the results of each period in relation to the products produced. This made sense in the 1890s, when cost accounting was developed, as most companies had extremely low fixed costs. The majority of costs were labour, which at the time was fully variable, as workers were only paid for the hours they laboured at the demand of the employer. Although there was distortion due to the overhead allocation, it was extremely small.
Modern businesses, however, have a much lower proportion of fully variable costs. Most costs are fixed, especially labour as now most employees work fixed hours regardless of demand. Due to this environmental change, the distortion caused by cost allocation is much larger and can cause management decisions, based on cost accounting, that directly result in large loses of productivity and profit.
As an example, imagine a company has fixed overheads of $10,000 (plant and labour) per month and currently produces 800 widgets with a materials cost of $40. The unit cost per widget would be $52.50 ($40 + $10,000/800). If an order now came for an additional 500 widgets at a price of $50, then management based on cost accounting should reject the order as it would result in a loss of $2.50 per widget. However, as the majority of costs are fixed, the increase in production would actually result in a new unit cost of $47.69 ($40 + $10,000/1300), so profits would actually increase by $1,153.85. This might seem clear, but imagine this example with many different products and prices in the mix and quickly it becomes hard to see the mistake. This is only one example of a poor decision made due to a cost accounting metric.
So why am I so concerned? In the software industry, especially, there is very little variable costs. The overwhelming expense is for developers, which are typically in short supply, so they are not a variable cost. Basing our decisions around software projects and the ROI from software delivery on cost accounting can lead to incredibly poor outcomes.
In future blog posts, I'll also explore what I believe is another critically important aspect of Throughput Accounting - the focus on throughput and inventory reduction over costs. I believe this has the potential for a massive effect on the software delivery process, especially when combined with the Lean practices that ThoughtWorks is pursuing in the industry.
Believe me when I say this - Throughput Accounting will become of major importance in our industry. It will make a dramatic change to the way we finance software projects and it has the power to put real numbers around why we use Agile and Lean principles and practices (as shown in David Andersons book "Agile Management for Software Engineering").
If your interested in another good introductory text, in addition to Corbetts book, try the book by Steven Bratt, also titled "Throughput Accounting".
In 1981, at a conference of Management Accountants, Eliyahu Goldratt declared Cost Accounting to be "Enemy #1 of Productivity". In my work as a consultant for ThoughtWorks, I value productivity highly. Hence the enemy of my friend is also my enemy.
Goldratt, author of the popular business novel "The Goal", showed how traditional cost accounting easily and trivially leads intelligent managers and other decision makers to make bad decisions - decisions that have massive negative effects on performance and profitability. This was actually not surprising news, as the problems with cost accounting had been recognised. But Goldratt also proposed an alternative.
His alternative was titled "Throughput Accounting", and was described in the 1998 book by Thomas Corbett. It is an accounting model which does not focus primarily on local cost optimisation and instead focuses primarily on overall system throughput. Importantly, it does not attempt to allocate overhead costs across products and services.
Why is this important? Cost accounting attempts to allocate a companies fixed costs over a given time period to the products or services produced in that period. It enables managers to ignore the fixed costs and focus instead on the results of each period in relation to the products produced. This made sense in the 1890s, when cost accounting was developed, as most companies had extremely low fixed costs. The majority of costs were labour, which at the time was fully variable, as workers were only paid for the hours they laboured at the demand of the employer. Although there was distortion due to the overhead allocation, it was extremely small.
Modern businesses, however, have a much lower proportion of fully variable costs. Most costs are fixed, especially labour as now most employees work fixed hours regardless of demand. Due to this environmental change, the distortion caused by cost allocation is much larger and can cause management decisions, based on cost accounting, that directly result in large loses of productivity and profit.
As an example, imagine a company has fixed overheads of $10,000 (plant and labour) per month and currently produces 800 widgets with a materials cost of $40. The unit cost per widget would be $52.50 ($40 + $10,000/800). If an order now came for an additional 500 widgets at a price of $50, then management based on cost accounting should reject the order as it would result in a loss of $2.50 per widget. However, as the majority of costs are fixed, the increase in production would actually result in a new unit cost of $47.69 ($40 + $10,000/1300), so profits would actually increase by $1,153.85. This might seem clear, but imagine this example with many different products and prices in the mix and quickly it becomes hard to see the mistake. This is only one example of a poor decision made due to a cost accounting metric.
So why am I so concerned? In the software industry, especially, there is very little variable costs. The overwhelming expense is for developers, which are typically in short supply, so they are not a variable cost. Basing our decisions around software projects and the ROI from software delivery on cost accounting can lead to incredibly poor outcomes.
In future blog posts, I'll also explore what I believe is another critically important aspect of Throughput Accounting - the focus on throughput and inventory reduction over costs. I believe this has the potential for a massive effect on the software delivery process, especially when combined with the Lean practices that ThoughtWorks is pursuing in the industry.
Believe me when I say this - Throughput Accounting will become of major importance in our industry. It will make a dramatic change to the way we finance software projects and it has the power to put real numbers around why we use Agile and Lean principles and practices (as shown in David Andersons book "Agile Management for Software Engineering").
If your interested in another good introductory text, in addition to Corbetts book, try the book by Steven Bratt, also titled "Throughput Accounting".
Wednesday, July 9, 2008
The 3 Ps of Estimation
There's been a few posts recently regarding estimation on agile projects, all expressing issue with the way it is most commonly approached. A common theme to these posts seems to be a slight under-appreciation for the multiple purposes of story estimation.
I consider there to be 3 roles for estimation, which can be categorized with 3 Ps as follows:
Prediction (or Planning)
The most commonly observed purpose of estimation is for prediction - trying to determine at what time a certain amount of work will be completed, or what amount of work will be completed at a given time. With an estimate on each story in the backlog and an understanding of the rate of completion of those stories (velocity), either of these can be predicted with an accuracy equal to the accuracy of the estimates. Note that the accuracy tends to rapidly decrease as the amount of work or the timeframe gets larger.
Prioritisation
Prioritisation can be considered as the task of scheduling work by decreasing value. So when prioritising stories, the one with the highest value is scheduled first, followed by the next, and so on. This of course begs the question of how we determine the value.
I've blogged this topic previously, but I consider that value is essentially determined by a comparing benefit and cost. The story describes the benefit and an estimate on it can be used as a measure of the 'cost'. Thus estimation is essential for prioritisation.
Note that for prioritisation it doesn't matter what sort of estimation metric is used. It will still be treated as relative, as the prioritisation is about the relative value of each story.
Performance
Estimation is also required to measure changes in the performance of a team. The throughput (velocity) of a team is determined by the amount of 'work' being done over a given time-period and is measured in terms of the estimate. When changes are made to the team or the environment, the previous and new throughput can be compared to see if an increase (or decrease) in performance has been observed.
I consider there to be 3 roles for estimation, which can be categorized with 3 Ps as follows:
Prediction (or Planning)
The most commonly observed purpose of estimation is for prediction - trying to determine at what time a certain amount of work will be completed, or what amount of work will be completed at a given time. With an estimate on each story in the backlog and an understanding of the rate of completion of those stories (velocity), either of these can be predicted with an accuracy equal to the accuracy of the estimates. Note that the accuracy tends to rapidly decrease as the amount of work or the timeframe gets larger.
Prioritisation
Prioritisation can be considered as the task of scheduling work by decreasing value. So when prioritising stories, the one with the highest value is scheduled first, followed by the next, and so on. This of course begs the question of how we determine the value.
I've blogged this topic previously, but I consider that value is essentially determined by a comparing benefit and cost. The story describes the benefit and an estimate on it can be used as a measure of the 'cost'. Thus estimation is essential for prioritisation.
Note that for prioritisation it doesn't matter what sort of estimation metric is used. It will still be treated as relative, as the prioritisation is about the relative value of each story.
Performance
Estimation is also required to measure changes in the performance of a team. The throughput (velocity) of a team is determined by the amount of 'work' being done over a given time-period and is measured in terms of the estimate. When changes are made to the team or the environment, the previous and new throughput can be compared to see if an increase (or decrease) in performance has been observed.
Subscribe to:
Posts (Atom)
