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.
