[FoRK] Theory of Constraints Primer

Stephen Williams sdw at lig.net
Sat Mar 16 11:53:03 PDT 2013


http://www.edn.com/electronics-blogs/analog-ic-startup/4408240/-So--when-will-you-be-done-with-your-design-
>
> At Touchstone Semiconductor 
> <http://www.touchstonesemi.com/?utm_source=EDNBlogJF_homepg_030413&utm_medium=DesignDone_#3&utm_content=030413&utm_campaign=TShomepglink>, 
> we’re having some success with a simplified version of the approach described in the book “Critical Chain 
> <http://en.wikipedia.org/wiki/Critical_Chain_%28novel%29>” by Eliyahu Goldratt. What Goldratt describes is especially 
> applicable to large complex development schedules with lots of interdependencies. Our design teams are small, usually just one 
> to three engineers, and that helps to simplify the planning. These are very driven, very motivated and highly qualified 
> professionals with many years of experience, but even then, it proves quite difficult to come up with a realistic schedule of 
> the design tasks.
>
> A schedule that is too much padded just invites inefficiency and typically, the allotted time will be used up anyway. 
> Over-aggressive schedules will always be missed, and because of that, they lose their significance, and even demotivate the 
> team. The critical-chain method attempts to avoid both those pitfalls.
>
> The concept starts with estimating the time needed for completing each sub-task. These should be reasonable estimates that 
> have a 50%-60% chance of being realized. Then, for each of the sub-tasks, estimate safety or buffer needed to almost certainly 
> meet the schedule. That buffer is not added to each of the sub-tasks, but instead, all individual buffers are added together 
> to form a project buffer.
>
> The goal is then to keep this project buffer intact as long as possible, which means focusing on the tasks that still need to 
> be completed, rather than at the ones that are completed already. This keeps the urgency on the need to meet the project 
> milestones, while allowing for setbacks that inevitably will occur, not on all, but on some of the sub-tasks.

http://en.wikipedia.org/wiki/Critical_Chain_%28novel%29
>
>
>       Scheduling Estimates
>
> Goldratt claims that the current method of generating task time estimates is the primary reason for increased expense of 
> projects and their inability to finish on time. The commonly accepted principle is to add safety (aka 
> <http://en.wikipedia.org/wiki/List_of_acronyms_and_initialisms:_A#AK>: pad or slop) to generate a task time length that will 
> essentially guarantee the step gets completed. He asserts that estimates for a task are based on individuals providing values 
> that they feel will give them an 80-90% chance of completing the step, these estimates are further padded by managers above 
> this person creating a length of time to complete a task that is excessive - as much as 200% of the actual time required. It 
> is this excessive padding that has the opposite effect - guaranteeing the task will run full term or late. As counter 
> intuitive as this seems, he provides examples of why this is the case. This predisposes the people on the project to consume 
> the time estimate by:
>
>  1. Triggering the "student syndrome <http://en.wikipedia.org/wiki/Student_syndrome>" in the resource assigned to the task -
>     they have more than enough time to do the task, therefore they start the task late using up all the safety.
>  2. Encouraging multitasking <http://en.wikipedia.org/wiki/Human_multitasking>. The safety is added knowing that the resource
>     will not be able to focus on the task and hence encouraged to multitask on multiple projects at a time, which
>     significantly impacts all projects.
>  3. Not claiming early completion. In order to preserve the safety concept in future projects, resources do not report tasks
>     completed early. Obviously, though, there is no way to hide a late completion.
>

I've seen these ideas in other forms, including, I believe, my Scrummaster certification training.
In some large and small important cases, I've seen these effects occur with traditionally planning / estimating.  For much of 
the 20K lines of code I wrote in the last couple years, I was able to avoid these issues by focusing exclusively on the 
problems, turning them over as fast as I could, staying in flow[1] as much as possible.

There is a relationship here to the complexity and unintended results of externally rather than internally driven (i.e. 
self-selected, self-directed, internally / individually motivated) efforts.  There is also some work about harm from certain 
kinds of reward patterns.

The description of the suggested method is high level, and not unlike what we already do in some respects.  It is also just 
Amdahl's Law as applied to management.  What's not clear here is that there are throughput, risk, and difficultly aspects to 
manage, although these can probably all be mapped to different flavors of throughput.  Marketing / partner / investment 
relationship development may also should fit into this paradigm.

>
>       Theory of Constraints Primer
>
> The book presents a primer for Theory of Constraints. This is done in the form of a lecture by a professor who has recently 
> returned from a sabbatical <http://en.wikipedia.org/wiki/Sabbatical> at a large conglomerate 
> <http://en.wikipedia.org/wiki/Conglomerate_%28company%29> that uses the Theory of Constraints. The discussion focuses on the 
> current methods of measuring success at a work center (cost <http://en.wikipedia.org/wiki/Cost_estimation_models> and 
> throughput <http://en.wikipedia.org/wiki/Throughput_accounting>) and shows how they are contradictory to the success of the 
> production line as a whole.
>
> The book enumerates the five principle steps of the Theory of Constraints:
>
>  1. Identify. Identify the bottleneck of the system.
>  2. Exploit. Exploit this bottleneck, making its throughput efficient by changing processes, equipment maintenance procedures,
>     training, policies, etc.
>  3. Subordinate: Subordinate the throughput of all other work centers to this work center.
>  4. Elevate. Invest in this work center to increase its throughput - add equipment, manpower, etc.
>  5. Inertia. Start the process over on the line to determine the new bottleneck.
>
> This philosophy keeps the cost and throughput models at odds with one another since the subordination process necessarily 
> decreases efficiency. Hence, evaluation criteria for properly managing a work center must change to properly reward the 
> organization’s success.
>
> The book points out this conflict with respect to an axiom in the Theory of Constraints that states that if two concepts are 
> in direct conflict, then there is an assumption as part of those concepts that is incorrect.
>

[1] http://en.wikipedia.org/wiki/Flow_%28psychology%29

Stephen

-- 
Stephen D. Williams sdw at lig.net stephendwilliams at gmail.com LinkedIn: http://sdw.st/in
V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407
AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres
Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer



More information about the FoRK mailing list