Business of Software Engineering - Throughput Accounting and the Theory of Constraints

In his recent blog posting “Theory of Constraints and Software Engineering” Steve Tendon addresses why throughput accounting should be preferred over cost accounting in software development organizations. He also provides a simple model for throughput accounting that is applicable to software engineering.

In addition to responsibilities such as architecture design, the role of a software architect requires a focus on the business case. Architects need to take business aspects into account in their architecture decisions, because otherwise they might build systems without appropriate economic value. The blog post of Tendon, a consultant specialized in software engineering management, provides a proposal for assessing business value based on throughput instead of costs.

As an appropriate model for his argumentation the author leverages the Theory of Constraints (TOC) with its “a chain is no stronger than its weakest link” perspective:

TOC considers any business as a system transforming inputs into outputs. The inputs undergo a number of work steps and are transformed into outputs. The outputs are the products/services valued and paid for by the business's customers. 

The key tenet of TOC is that there is always one work step that limits the system’s output capability. This entity is called the Capacity Constrained Resource (CCR). According to Tendon, the CCR  is often given away by chains of work in process and inventories.  In software engineering, a unit of inventory could be a use case in the Rational Unified Process, a story point in XP, or a backlog item in Scrum. To optimize the CCR, the method is proposing a model, called the five focusing steps which according to Wikipedia.org comprise:

1. Identify the system's constraint(s) (that which prevents the organization from obtaining more of the goal in a unit of time)
2. Decide how to exploit the system's constraint(s) (how to get the most out of the constraint)
3. Subordinate everything else to above decision (align the whole system or organization to support the decision made above)
4. Elevate the system's constraint(s) (make other major changes needed to break the constraint)
5. Warning!!!! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system's constraint.

After introducing the TOC model, Tendon explains the concept of Throughput Accounting (TA) which is defined by three formulas:

• Throughput: T = Revenue – Totally Variable Expense
• Net Profit: NP = Throughput – Operating Expenses
• Return on Investment: ROI = Net Profit / Investment

Adopted to software engineering,

• Throughput: TE is the rate of cash generated through delivery of working code into production [...] It is computed as sales price minus direct costs, such as packaging, delivery, installation, training, support, and networking.

• Investment: I is all money invested in software production systems plus money spent to obtain ideas for client-valued functionality. It thus includes software development tools and requirements gathering. [...]

• Operating Expense: OE is all money spent to produce working code from ideas. It is primarily direct labor of software engineers, but it also includes selling, general, and administrative costs.

This simple model makes TA accessible even to non-accounting professionals such as software architects. While many organizations often emphasize cost reduction to improve business performance, Throughput Accounting proposes alternative considerations. As Tendon puts it,

Reducing cost is limited, while increasing throughput is potentially unlimited. An excessive focus on cost reduction can jeopardize the company's capability to deliver, and instead it will decrease throughput, with much more devastating consequences.

In the post, Tendon gives three examples for applying the throughput accounting method.

• One way to reduce the operating expenses in TA would be discarding requirements before implementation. Each single story eliminated reduces the operating expenses and increases the net profit.
• Adopting Open-Source Software helps to reduce investment, while increasing the operating expenses. However, the increase of operating expenses should be less than building the same system.
• When choosing niche markets, software organizations might increase the unit price by offering unique features for that market.

As Tendon explains, throughput accounting is not only an accessible accounting model for software engineers, but also a radical alternative to traditional cost accounting which focuses more on cost reduction such as decreasing operating expenses. At the end of his posting Tendon explains TA’s effect on other common processes such as turnover, hiring, and project constraints in terms of schedule, budgets, resources and scope. He concludes his posting with:

TA can be used to take management decisions on all business processes, including turnover, hiring, outsourcing, choice of methodology, and so on. The trick is simply that of relating any decision to T, OE and I, in order to make an informed and financially sound decision.

A couple of readers were commenting on the blog post. For example, Robert McGinley supports the Theory Of Constraints approach:

I've been a big believer in TOC since I read "The Goal".  I always thought it made sense to apply it to SE and there is a lot of great explanation in this article.

Dave Nicolette likes the article but disagrees with the treatment of story points:

I have to disagree with the practice of associating story points with estimated revenue value. IME story points are based on level of effort and estimated value is orthogonal to level of effort. I generally prefer to use Earned Business Value (see http://danube.com/system/files/CollabNet_WP_Earned_Business_Value_041910.pdf and http://danube.com/system/files/CollabNet_WP_AgileEVM_and_Earned_Business_Value_Metrics_032510.pdf, among others) to track the delivery of customer-defined value. It is applicable to both traditional and adaptive development. When I've seen people track both scope and value using the same measure, it's been problematic. Your experience may differ.

Tendon responded to this point:

Yes, you are naturally correct that associating story points with revenue value is not the best approach, and that earned value metrics are more appropriate. However, in the cases I've handled this has been a good enough approximation, that easily allows bridging the developer's estimates to the numbers needed to take management decisions. In other words: it was a practical approach that gave good enough solutions.  It works because of averages. On average a story point can be associated with an average revenue value. And if you're strict with triaging the todo list, that average will be quite representative of the work remaining on the list.

Christian Beck enjoyed the article but thinks that constraints are not always bad:

Constraints are not always bad. In a CDS, constraints largely determine not just the volume of output (which is also difficult to define/measure in software), but other important properties of the output like quality, how innovative the output is. Even more, constraints are deliberately an integral part of the systems design (e.g. WIP limits, time boxes).  Changing constraints is an important tool to influence (not control) the output.

The blog author responded with:

Yes! Constraints must always be seen in relation to your own goal. Some constraints will actually guide you in the right direction (good ones); others will be obstacles (bad ones). It is a good skill to have to know how to distinguish between the two; and also to know how putting into place artificial or deliberate ones (like WIP limits in Kanban) can be beneficial for your own goals.