Theory Of Constraints And Software Concerns

Unlike a lot of others, I was introduced to Theory Of Constraints (TOC) by the business novel

Necessary But Not Sufficient

and was instantly addicted to the revolutionary approach, an output of exceptional work by Eliyahu Goldratt.

The Theory

Theory Of Constraints (TOC) is, at its basics, a problem solving approach that focuses on the constraints or limitations involved. Anything that we are part of today – work or family or organizations – involves multiple factors. There is a continuous effort to get better at it. The apparent approach is to maximally use the resources, change all the variables so that the betterment is optimum. However, the working is usually limited by not all, but some factors – the constraints. TOC makes this more explicit by approaching the solution by looking at an entity through its constraints. A business has to work under constraints – monetary, time, workforce, competition and probably hundreds more. To bring about an improvement, the effort should be directed towards the constraints.

At its center is a set of tools called Thinking Processes, containing causality and necessity as two basic elements. The revelation of cause and effect can identify root cases of undesirable effects (UDEs) and help us answer the three important questions:

  • What to change?
  • To what to change?
  • How to change?

Consider the following excerpt from the video transcript of introduction to TOC“:

Just to give us a couple of very simple, trivial examples. If we talk about causality, it might be as simple as “if I touch a hot stove, then I get burned.” That’s our understanding of reality. And if we want to change it, then we may look at some of the assumptions and alter the situation that says, for example, now “if I touch a hot stove and I’m wearing a pot mitt, then I don’t get burned.”

Instead of one reality, we have what we’ve put into place that alters that reality. This is utilizing this cause and effect.

Had we expressed it more in the realm of necessity, it might appear that “in order to avoid getting burned, I must not touch the stove.” Why? “Because touching a hot stove might burn me.”

Thinking Process provides following tools for a systematic approach:

  • Current Reality Tree (CRT): to identify UDEs and their root causes
  • Clouds: to resolve conflicts that causes UDEs
  • Future Reality Tree: future state of the system after some actions are identified
  • Negative Branch Reservations: possible negative ramifications of actions chosen
  • Prerequisite Tree: a pre-plan which identifies the intermediary objects required and possible obstacles
  • Transition Tree: details of the action to be taken

This is very analogous to what my friend says about using Business Models for as-is system, to-be system and the transition.

TOC And Software Industry

TOC has been applied to multiple industries like Production, Logistics, Accounting, Marketing and many more. It has resulted into amazing processes like Drum-Buffer-Rope (DBR) that lead to synchronized manufacturing or throughput accounting or Critical Chain.

I want to tackle application of TOC to software industry in two different ways. One is impact of TOC on software concerns to provide maxium ROI. The other is use of TOC in managing software processes.

ROI From Softwares

Scott swirls his brandy and takes a taste. “When does a new technology bring value?” He starts with a rhetorical question. “We expect that a new technology will bring benefits, when and only when, the new technology diminishes an existing limitation. It is simply common sense.”

“Maybe to you. What do you mean?”

“If the new technology does not diminish any limitation whatsoever, there is no possible way in which it can bring benefit.

This is an excerpt from Chapter 12 from the book that I mentioned before.

TOC tells that an organization can benefit if its constraints are targeted and resolved. If a software has to be beneficial, it has to follow the same way. The key benefit of software is automation – automation of processes. TOC, through its focus on constraints, which are part of processes in an organization, typically leading to BPR. Use of TOC in Business or System Modeling can lead to right automation of these optimized processes which will provide maximum benefit to the organization.

TOC In Software Engineering

Software businesses can use TOC to improve by overcoming its constraints. Just like every other business, even a software business has limitations. TOC can be used to identify them and act on them to provide improved processes.

Software solutions require more and more out-of-box thinking, solutions that are not run-of-the-mill but innovative and original. TOC can provide answers to the basic questions leading to an unique and effective solution. Use of TOC can also provide pragmatic solutions in project management.

Each of these deserve individual discussions on them, which I hope to follow up with.

There might be many more applications of TOC in software industry. There are already some softwares out there which provide TOC solutions. Let us look for more usage of TOC in software industry for the benefit of both, the software users and creators.

Technorati tags: , , , ,

Copyright Abhijit Nadgouda.

Discussion [Participate or Link]

  1. Sanjay said:

    Do u have any idea about any software company implementing this concept to make an application out of this concept??

  2. Abhijit Nadgouda said:

    I am not aware of any application, however I have met some individuals who follow things closer to this approach.

  3. Shiva Shenoy said:

    i2 Technologies was founded in 1988 and created Rhythm (now known as Factory Planner) based on TOC.

  4. Shiva Shenoy said:

    I may have misunderstood the question. If you are referring to using TOC for software development, the answer is I don’t know of any commercial products, but there are some products developed and used internally (for development and customer support) at i2 that use some of the concepts.

  5. Abhijit Nadgouda said:

    Hi Shiva,

    Its great that i2 uses TOC for software development. So, Sanjay there are inhouse applications, but still not sure if there are any commercial ones available. Is Factory Planner a APS that implements TOC for other industries?

    Where does i2 apply TOC in software development? As mentioned in the article, there are two applications of it, one is its use in feasibility and ROI study and requirements elicitation and the second in applying TOC for software project management.

  6. Brian Hersh said:

    You article on the theory of constraints is very well organized and has great applicability to sales discussions of software as well.

  7. Brian Hersh said:

    Your article on the theory of constraints is very well organized and has great applicability to sales discussions of software and software development services as well.

  8. Abhijit Nadgouda said:

    Thanks Brian.

  9. iface thoughts » Blog Archive » IT ROI Measurement Still In Incubancy said:

    […] I have brushed this topic earlier. Theory Of Constraints (TOC) says breaking of an existing constraint can provide the maximum benefit. If IT is breaking a constraint, it is the easiest way of identifying the ROI. In such cases, the ROI gets more accurate. […]

  10. Shiva Shenoy said:

    Factory Planner is TOC based but is not used in software development.
    The principles of TOC were used to build an internally used system to manage the software development and support process.

  11. Abhijit Nadgouda said:

    Hi Shiva,

    It is commendable that TOC principles are being used for software development. It is still not popular. I hope someday you guys come up with a commercial product (or process) 🙂

  12. iface thoughts » Blog Archive » Theory Of Constraints And Software ROI said:

    […] As a software professional I have found presenting this value or convincing the customer of the ROI a difficult task, sometimes futile too. This was the first thing I realised can be resolved when I was introduced to Theory Of Constraints (TOC). If a software can be shown to break a constraint for a user, or rather a business constraint assuming that you would want to treat every user as business, then its ROI could be made apparent and convincing, as in the cases mentioned earlier. […]

  13. thosar@vsnl.com said:

    We have actually used the ToC to REAL productive usage in software development and maintenance. Reduced a 20-fire-fighting job inducted in parallel with routine development from an unfeasible 3000+ odd manhours to around 24% of that in practice, leaving enough buffer for the bottleneck resources. TOok only the first three steps. NO additional investments….

  14. Abhijit Nadgouda said:

    That’s great! I think more of such cases should be studied and used to encourage TOC. The surprising thing is that I haven’t seen it in any of the processes for IT.

  15. Do Not Worry About Microsoft on iface thoughts said:

    […] My first realisation about the impact a piece of software can have on businesses was through the reading of Necessary But Not Sufficient. These softwares, the enterprise softwares, provide maximum ROI and they can do this only if they get completely absorbed in the business, so much so that the business starts depending on them. As a result you start depending on the vendor for your business, which can be a career threatening move. I have always maintained that companies should adopt softwares, not adapt to them. For example, in case of business processes, they should be designed outside the softwares, purely for the business needs. Software should be a used to break constraints that the business processes face, which involves tweaking and realigning the processes. If not, I see the dependency on such softwares, and possibly the vendors, is more harmful than beneficial. […]

  16. Does IT(it) Matter? on iface thoughts said:

    […] would like to qualify Nick Carr’s argument that IT doesn’t matter by saying IT is necessary but not sufficient. I agree with Nick that IT, as a commodity, is not going to build an edge over competitors. I also […]

  17. Engineering And Manufacturing on iface thoughts said:

    […] processes (even if adhoc) and reality of the team. Well, more reasons for me to believe that Theory Of Constraints can help software engineering a lot. OpenIDSay your […]

  18. Debashish said:

    Hi Abhijit,
    There are three aspects to be addressed here:
    One is TOC as applied to Software in Business Processes. The implementation of a software can bring benefits only if it is able to diminish the existing limitation that is hindering the growth. If we continue with the old rules that were existing before the implementation and if we do not put new rules in place, then the advantage can never be realised. e.g. An ERP implementation will never bring benefits unless we start thinking globally and not locally. Information sharing for bringing global benefits is the key to success.

    The second aspect is application of TOC in software development. There are many companies who use The Critical Chain methodology for project management in software development.

    There is a third aspect which softwares which use TOC as their base principles for supply chain or project management solutions. For e.g. Inherent Simplicity is a software provider specializes in Theory of Constraints (TOC) products for all supply chain aspects.
    Although i2 initially based its Factory Planner solution on TOC principles, it later waivered away from it. The story mentioned in the Necessary but not Sufficient book is something similar to the i2 case 😉

    The way I look at it is that you are looking forward to the second aspect more than anything else. You can use agile or XP in combination with Critical Chain to achieve amazing results.


  19. Abhijit Nadgouda said:

    Debashish, you are right, I am interested in application of TOC in project management, like applying Critical Chain.

    But I am also interested in leveraging the knowledge of TOC to find about ROI of software in a certain case. One of the most convincing arguments for ROI is to break an existing constraint. TOC can immensely help in first identifying constraints and then using its techniques to break them using software/automation.

  20. David Locke said:

    The TOC has an interesting role in software development if you look at software development as an organized collection of decisions. What you end up with is a decision tree. The development methodolgoy would be expressed in the decision tree as layers of decisions from point A to point E being requirements. The layer that would be design is situated between the requirements and the code, not because of the waterfall, but because of the content of the decisions.

    Requirements tell us what and how well. Ignore the how well, non-functional requirements.

    The implementation environment are decisions mostly imported through the components of the environment. Pick a programming language and you are building on top of the decisions that created that programming language. Those decisions are fixed in the programming language. They are the constraints imposed by the programming language. The OS, the programming language, the database system, the …., the whatever, creates forests of decisions realized as constraints.

    So somewhere between the environmental constraints and the what lies the architecture, which is built to align the constraints with the decisions. This is design.

    This model plays out for every media, not just software. It might be a painting, or a business system, or a microchip. The decision tree spans the concept and moves it towards realization. It extends beyond the GUI into user tasks, bridged by work design towards real work, to financial results.

    Constraints are decisions assumed to be fixed. Some of those decisions were optimal at some point in history, but who amoung us reviews a list of constraints and reminds ourselves that constraint number 7653 has been loosened, so those things built in a manner to balance against that constraint needs to be reviewed and possibly rewritten? Nobody I know.

  21. David Locke said:

    Many things mitigate against the achievement of ROI in IT systems. Gartner defined the total cost of ownership. While they were doing it, they defined a class of cost that they called negative use costs. These costs are not incorporated in the definition of the TOC today, because the numbers that support it are not captured by accountants.

    Examples of such costs are the time spent developing and using desktop applications like Excel to reorganize table data for a function not incorporated in the software, time spent reading the manual, time spent on the phone with technical support. All of these costs are never captured and are thus invisible.

    In the TOC, the costs are subtracted from the projected gain, then divided by the infrastructural multiple. This infrastructural multiple is the sum of all the costs associated with networks, the hardware, the desktops, the wifi gear, etc. This multiple was 2 back in the early 80’s, it was 6 before Wifi, it is even more today. So the real gains are quickly diminished by the math.

    The other problem is that multistakeholder systems can hardly serve even on of those stakeholders well, so each stakeholder has to build those desktop applications, or abandon their meaning. It systems CONTAIN and MANIPULATE what they contain, meaningless numbers. The meaning is attributed after the fact. We do not compute on meaning. Users work on meaning, so the meaning is lost once we automate their work.

    Ask a sales rep what a customer is. Ask a marketer what a customer is. Those two meanings are not reconciled with a name and address, a person, a lead, a sale, hardly. The meaning is lost. Worse, the meaning is also extacted from the data in a manner that corrupts the decisions made with that data.

    So where is the ROI? It is miniscule, fractured, and misleading.

  22. Abhijit Nadgouda said:

    From a software engineering perspective, I want to use TOC to identify constraints in development itself. Like identifying factors that are unknown, and identifying their degree of being unknown. Or the ones that can change any time, without a warning. I consider these as constraints, and identifying them can help in deciding on various ingredients of the software design. The constraint of a limited number of people or like you said, environment constraints.

    Regarding the ROI, it is quite possible that TOC might not help a lot in calculating the ROI. But it can help in very first step of identying if there is an ROI or not. The decision whether to automate or not. Of course, nothing is free, it important to consider the cost of using software too. But while talking to a business about its problems, TOC can help in answering why a certain piece of software should or should not be used. For example, whether a business should use ERP or not. The best ROI it can provide is by breaking some constraint which was limiting the business. I found that the TOC approach was helpful in software design if we realized that it was breaking a constraint.

  23. Ivan Appel said:


    Regarding TOC & software. I’m developing a tool for drawing diagrams for TOC Thinking Processes at (http://code.google.com/p/jthinker), maybe you’ll be interested to take a look 🙂

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.