For quite some time I have been trying to digest and slowly apply Theory Of Constraints in what I do. Like Jack Vinson says, Necessary But Not Sufficient is a great book to get encouraged about it. I too was drawn in by the same book.
I am trying to pursue application of TOC for software from two angles:
- Using TOC to justify ROI for software
- Using TOC in software development processes and methodologies.
Jack Vinson puts the rules for technology quite nicely.
However, there are cases where certain limitations are dependent on each other. Breaking or minimizing the effect of a constraint warrants us to look at others as well. A lot of times they get ignored because of the scope we limit ourselves in for the project.
Gautam Ghosh asks about the rules that we ignore during a change. I am not sure of the rules, but I think we can look at following types of constraints:
- External constraints imposed on us, usually by other players of the industry, or by its very nature.
- External constraints because of nature of our business.
- Internal constraints that are created because of change in scale.
- Internal constraints because of the tools and processes we have gotten used to. Every solution comes with its own set of constraints.
- Internal constraints because the team’s skillset and knowledge.
- Internal constraints we force upon ourselves, e.g., quality compliance.
TOC can help us identify rules because of such constraints. If a business need demands us to break or minimize effect of certain constraints, rules have to be correspondingly changed. Otherwise its benefits will not reach the business.