“From Manufacturing to MIS and Medicine: The Theory of Constraints in Knowledge Industries”

“Limits of the Balance Sheet: How Financial Reports can Obscure Operational Problems”

“Aligning Operations and Strategy using the Discipline of the Project Triangle”

This concept is promoted by Eliyahu Goldratt and his Theory of Constraints and in his books like The Goal. He argued that in in the case of discrete manufacturing–where individual goods are produced in a continual but not continuous process through the discrete application of heterogeneous transformations–as the utilization (or efficiency) of the individual steps approaches their maximum, the productivity (or throughput) of the system as a whole approaches a minimum. Now, software development looks to me a lot like discrete manufacturing. You have a set of inputs of varying quality: requirements, best practice documents, etc. In a factory, the machines that perform a step in the manufacturing process often differ – they could be different models, have different maintenance histories, have different tolerances with regards to inputs or throughput, or produce at different levels of quality. Tom DeMarco reminds us that knowledge workers–and this includes the analysts, designers, developers, and engineers–are similarly not fungible. Not only does each individual have their own specialties and deficits but people have task switching costs analogous to the set up costs with factory machines.

While Slack was the first book I read to apply TOC methodologies to software development, I’ve been noticing that it’s not an uncommon perspective. The Agile Management Blog is thick with these ideas as is Steve Hebert’s Development Blog, the Creative Generalist, and Frank Patrick’s Focused Performance Weblog.

Using the TOC approach provides two primary advantages:

1. The opportunity to apply an empirical science to the fuzzy art of software development management–and a science tested in modern manufacturing industry.
2. A concrete and tested method for examining, evaluating, understanding and improving your development processes

As the name implies, a central tenet of TOC is the identification of your system’s primary constraint. Often called the bottleneck, this the step in your system that controls the maximum throughput, and systemic throughput, according to TOC, is the most important metric of effectiveness. As the constraint control the throughput of a system, no increase in resource utilization outside the constraint will increase systemic throughput. The only option, then, is to increase utilization of the constraint itself.

In the software world, the constraint could be code review by the lead architect. It could be sign off by legal. It could be client feedback. It could be any number of things. However, once the constraint is identified there are a limited number of available actions:

1. Add capacity to the bottleneck. Typically this means increasing the number of people who can perform the bottleneck task(s).
2. Ensure the bottleneck only does high quality work–improve the quality of its inputs. Before the architectural code review, code could be peer reviewed. The legal department could prepare guidelines or an inexpensive paralegal. Internal client surrogates could be used.

Remember, though, that these changes can possibly move the bottleneck. Code review is fine but QA is stalled. Client feedback is coming in fast and furious but issues are no longer being adequately prioritized. Moreover, resources cannot be added indiscriminately–there’s still a cost to task switching and adding resources to an already late project typically only increases the delay.

That’s enough out-loud thought for me. Something to think about – what limits your organization’s productivity? And what can you learn from other disciplines?

1. Understand how their company “makes money”–their corporate strategy for success and metrics for determining progress towards that goal
2. Be able to evaluate requirements (i.e., cost, schedule, and features) in terms of the above metrics and goals
3. Be able to cost and price and understand the difference between the two

What is the difference between cost and price? Why would price be different than cost? Cost is a description of the impact on your resources of doing something–of meeting a set of requirements. Price is a means for communicating your priorities and preferences to those whose requirements you are asked to meet.

From the perspective of managing a project, there are only three requirement: Cost, schedule, and features, and it’s accepted project management practice that only two of them can be specified at a time (as engineers say: “Better, faster or cheaper–pick two”). If you understand your corporate strategy you can help your customers understand which two are the most important. For example, in the retail financial services world, IT costs are often only a small part of the budget for a new product launch. However, the IT portion of the project can still be on the critical path–if the IT part is delayed or doesn’t meet the feature and quality requirements the opportunity cost is great. It would then be reasonable to assume that the sponsoring business group would be willing to pay a high premium–possibly above estimated costs–to guarantee that their feature and schedule requirements are met.

It’s not enough to be willing to adjust prices to meet feature and schedule requirements. You need to be operationally prepared to accept the work. This is done by maintaining a level of staffing slack above your expected work level. Your level of slack bounds your capacity to meet new requirements and new projects. How much slack is required?

That’s a harder question than deciding how much slack to pay for. One way to calculate it would be to identify the corporate cost of missing features or delaying delivery. The cost to the company should approximate the price they’d be willing to pay to avoid it, which is to say, the price they’d be willing to pay for slack.

Interestingly, it’s likely that maintaining slack across the team and the IT organization will probably lower overall costs, but my theory that IT is just discrete manufacturing probably deserves its own post.

Eclectic Bill: TOC Analysis of Technology