By The Book 3: Throughput Accounting
This is the third part in a series on management accounting for software development. The material is from a book I am working on. To make sense out of it, read part 1 and part 2 first.
Let's look at the diagram modeling team A and B again:
The developers in team A are already working at full capacity. Thus, they are the constraint of the process.
Adding 8 hours of work for a developer, means adding 8 hours to the constraint. Adding 8 hours to the constraint is the same as adding 8 hours to the whole project. The cost is €175 times the number of developers and testers, plus an additional €200 (8 * 4,000 / 160 = 200) for the team leader. This works out to €1,425 (7 * 175 + 200 = 1,425) in increased project costs. In addition, there may be a considerable cost associated with delaying delivery. I'll leave that can of worms alone. (Read about it in Lean Software Development by Tom and Mary Poppendieck, or check out a blog posting by Gustaf Brandberg.)
Team B has an easier time dealing with defects. The developers are idle about 16 hours/month. 8 of those hours have been wasted the current iteration, but the remaining 8 hours per developer is just enough for a developer to fix the defect. Project throughput won't be affected at all. There will be no project delay. There is no change in Operating Expenses because of the defect. Thus, the defect can be fixed at zero cost. This of course assumes the cost of reporting a defect is negligible. A complex defect report procedure would add to the cost of the project every time a defect is found.
Note that up to know we have dealt with one particular problem with Cost Accounting: that Cost Accounting treats all parts of a system (project, company, conglomerate, whatever) as separate and equally valuable. In reality, different parts make contributions of different value (at different times, just to make it interesting). I hope I have shown that Throughput Accounting offers an alternative that makes more sense.
There is another problem with Cost Accounting: do you remember the overhead costs mentioned earlier. Even in the rare cases where managers do understand that the overhead allocations distort figures, they tend to dismiss it as unimportant. In the book Throughput Accounting, Thomas Corbett contends that this distortion can be pretty serious. It can make the most profitable product, project, or company seem the least profitable, and vice versa.
This is bad enough, but there is another area where overhead allocation can gum things up: when you use ROI calculations for decision support. Agile methodologies do this. Scrum, for example, has a very tight focus on maximizing ROI. During the projects, this is done in a pretty freeform manner, and Cost Accounting never enters the picture. (Unless the team has to ask for money to do or buy something).
Before a project begins is another matter. For example, Scrum uses ROI calculations to provide decision support for go/no go decisions. (Scrum does not tell how to do it, just that it should be done.) Using ROI calculations is a good thing, but when a company uses a dysfunctional management accounting system, the effects can be devastating.
Of course, you'll have to wait for the next post to get the details.
Let's look at the diagram modeling team A and B again:
The developers in team A are already working at full capacity. Thus, they are the constraint of the process.
Adding 8 hours of work for a developer, means adding 8 hours to the constraint. Adding 8 hours to the constraint is the same as adding 8 hours to the whole project. The cost is €175 times the number of developers and testers, plus an additional €200 (8 * 4,000 / 160 = 200) for the team leader. This works out to €1,425 (7 * 175 + 200 = 1,425) in increased project costs. In addition, there may be a considerable cost associated with delaying delivery. I'll leave that can of worms alone. (Read about it in Lean Software Development by Tom and Mary Poppendieck, or check out a blog posting by Gustaf Brandberg.)
Team B has an easier time dealing with defects. The developers are idle about 16 hours/month. 8 of those hours have been wasted the current iteration, but the remaining 8 hours per developer is just enough for a developer to fix the defect. Project throughput won't be affected at all. There will be no project delay. There is no change in Operating Expenses because of the defect. Thus, the defect can be fixed at zero cost. This of course assumes the cost of reporting a defect is negligible. A complex defect report procedure would add to the cost of the project every time a defect is found.
Note that up to know we have dealt with one particular problem with Cost Accounting: that Cost Accounting treats all parts of a system (project, company, conglomerate, whatever) as separate and equally valuable. In reality, different parts make contributions of different value (at different times, just to make it interesting). I hope I have shown that Throughput Accounting offers an alternative that makes more sense.
There is another problem with Cost Accounting: do you remember the overhead costs mentioned earlier. Even in the rare cases where managers do understand that the overhead allocations distort figures, they tend to dismiss it as unimportant. In the book Throughput Accounting, Thomas Corbett contends that this distortion can be pretty serious. It can make the most profitable product, project, or company seem the least profitable, and vice versa.
This is bad enough, but there is another area where overhead allocation can gum things up: when you use ROI calculations for decision support. Agile methodologies do this. Scrum, for example, has a very tight focus on maximizing ROI. During the projects, this is done in a pretty freeform manner, and Cost Accounting never enters the picture. (Unless the team has to ask for money to do or buy something).
Before a project begins is another matter. For example, Scrum uses ROI calculations to provide decision support for go/no go decisions. (Scrum does not tell how to do it, just that it should be done.) Using ROI calculations is a good thing, but when a company uses a dysfunctional management accounting system, the effects can be devastating.
Of course, you'll have to wait for the next post to get the details.
Comments
I'm no expert, but the conclusion you draw for Team A seems wrong. In that case, the Operating Expense is still unchanged: the "cost" of e1425 that you calculate is still a cost-accounting sum. In reality, no extra developers were hired to fix the defect, and so costs remain the same. The impact on Team A is equal only to the loss of throughput for those 8 hours - ie. it is the lost value that wasn't delivered during that time, plus the reduced future value of all other work that was delayed in turn. The importance of this example hinges on future revenues, not on the salaries of the employees.
(Thing is, I never know whether to express that as euros/day or euro-days ...)
The reason team A will be delayed is that the programmers are already working at full capacity. The defect represents more work. Completing that extra work will take extra time.
It is like driving a car at full speed. You have to drive 10 km, then the destination changes, and you have to drive 2 km more. You must spend a bit of extra time in the car, and so must all your passengers.
Obviously, in real life, if team A had only one defect to deal with, it would be possible to temporarily increase the production capacity of the team: overtime, let a developer skip a meeting or two, let a developer work at home for a few days to cut travel times, etc. However, that does not change the fact that Cost Accounting comes up with the wrong answer under some common circumstances. (Not under all circumstances, which makes the problem more insidious.)
The example is about the importance of treating a project as a system. As I mentioned, only direct project costs are considered. Cost of delay is an important concept, but it is not what the example is about.
In real life, managers must consider both the increased project costs due to loss of Throughput capacity, as described in the example, and the delay costs, which you mention. The former has an effect on budget and cash flow, the latter, as you point out, on future revenues.
I have noticed that TOC people focus on the former (David Anderson), while Lean people focus on the latter (Mary and Tom Poppendieck). I believe both are important. Which is most important, has to be decided on a case by case basis.
It is worth noting that choosing the scope of the system we are doing Throughput calculations for is very important. For example, the increased project cost for Team A does not automatically translate into an increased cost for the company. This would be true if the company's system constraint is outside the development teams. For example, if the constraint is in sales, the total Operating Expenses of the company will not increase. Money will just be shuffled around inside it.
Fascinating comment that TOC and Lean folks consider different things to first. Food for thought...
ROI = (T-OE)/I
Lean first works on reducing I, then on increasing T, and last on reducing OE.
TOC first works on increasing T, then on reducing I, and last on reducing OE.
Both ways work. However, they do lead to different priorities. In this case, it is pretty clear that the TOC priorities are the basis for considering loss of Throughput. The lean perspective, looking at future loss of revenue, stems from the interest in reducing lead times. (Or so I believe. It is just conjecture on my part.)
Great analysis. I have been a software developer for 13 years and am about 3/4 of the way through my MBA.
While I was in my Operations/Production control class one thing I realized is that one of the reasons why agile "methodologies" work is that they are keeping their batch sizes small and operating at level of the constraint (i.e. the team doing the work).
Traditional project methodologies try to run everything through the project all at once. So essentially you end up with what is a lot of inventory in your production line.
In the analysis phase you have all of the business analysts busy defining requirements. In order to keep the developer(s) on the team busy, the PM will often push to get requirements done as quickly as possible so the developers are not being kept idle (very similar to machines being kept busy so that they cover their overhead costs).
After the analysts get the requirements to the developers you have the developers pounding away at code. Because you are delivering a large amount of functionality through the coders and waiting until the end for the testers, you end up with a significant amount of "hidden" defects that do not surface until formal system testing.
Agile projects promote small batch sizes where there is very little intellectual inventory and defects are exposed earlier before they are allowed to stockpile up.
I know my analogy is pretty rough, but it has been a successful argument I have used to get my previous company to adopt agile techniques.
I would love to talk further on this subject. I am currently championing a lean six sigma effort at my company and firmly believe that the silver bullet companies are going after lies in the eliminating much of the waste they introduce in their software development processes. Please drop me a line (john_carnell@yahoo.com)