Unlike a lot of others, I was introduced to Theory Of Constraints (TOC) by the business novel
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: theory of constraints, toc, software, return on investment, roi
Copyright Abhijit Nadgouda.
August 1st, 2006 at 12:55 pm
Do u have any idea about any software company implementing this concept to make an application out of this concept??
August 1st, 2006 at 2:52 pm
I am not aware of any application, however I have met some individuals who follow things closer to this approach.
August 5th, 2006 at 5:53 pm
i2 Technologies was founded in 1988 and created Rhythm (now known as Factory Planner) based on TOC.
August 5th, 2006 at 5:58 pm
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.
August 5th, 2006 at 7:29 pm
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.
August 16th, 2006 at 9:16 pm
You article on the theory of constraints is very well organized and has great applicability to sales discussions of software as well.
August 16th, 2006 at 9:16 pm
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.
August 23rd, 2006 at 3:14 pm
Thanks Brian.
August 23rd, 2006 at 5:07 pm
[...] 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. [...]
August 26th, 2006 at 8:46 pm
Abhijit:
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.
August 27th, 2006 at 10:37 am
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)
October 25th, 2006 at 3:51 pm
[...] 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. [...]
October 28th, 2006 at 12:50 pm
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….
October 29th, 2006 at 12:55 am
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.
January 8th, 2007 at 8:48 am
[...] 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. [...]
February 4th, 2007 at 7:28 pm
[...] 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 [...]
February 28th, 2007 at 4:51 pm
[...] 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 [...]
March 13th, 2007 at 12:32 pm
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.
Regards
Debashish
March 14th, 2007 at 4:20 pm
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.
April 3rd, 2007 at 3:42 am
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.
April 3rd, 2007 at 3:52 am
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.
April 3rd, 2007 at 12:39 pm
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.