I came across a very problematic example of addressing a software development problem using the theory of constraints at http://www.agiledesign.co.uk/2010/theory-of-constraints-for-beginners
So, an example of applying these steps in a software development context might be;
Our goal is to construct, test and deploy software.
Our constraint is in system test, this is apparent due to a build up of software that has not been tested.
We identify exploit opportunities by considering where we loose test capacity e.g. recording timesheets. Since test is the bottleneck, time spent doing administration is directly reducing the output of the system.
We subordinate the system to the bottleneck by changing responsibilities e.g. PM to take on some administrative tasks from testers.
At this stage we return to assessing where the bottleneck is. If we run out of exploit / subordinate opportunities we may choose to elevate the constraint. This is where we consider adding resources, automation or training.
There are several big problems with this.
First, most product approaches insist that the source of the defects be responsible for the the costs, this provides valuable feedback and the right incentives. Shifting to the PM hides the problem.
Second, it assumes that bugs will just happen. This is wrong, they can be prevented or removed earlier in the process.
Third and biggest is assuming that this is a testing problem. It is far more likely a construction problem. Stop sending so many defects into test and you the paperwork won’t be so severe. It is common for 40-50 percent of project effort to be consumed with rework. World class organizations get this to under 5 percent. They don’t do this by having the PM write up the reports or adding testers. They do this by preventing defects or finding them before they get into test.