I have been banging my head against a long-standing paradox within TOC--the paradox that while the concepts of TOC are simple to grasp and understand intellectually, they have not been simple at all for people and organizations to implement. Or said more plainly: "How can something so easy, be so darn hard to implement?"
I think that the essence of the correct answer is generally well known to people in the TOC world and is even captured in the 5 steps. The underlying reason TOC is so hard to implement, even though it is simple to understand, is inertia. The methodology, in all its simplicity, actually demands that so many aspects of how we run and manage our organizations be re-thought. Things like the metrics we use, cost-accounting, scheduling, logistics, sales, inventory management, etc. all are altered by the core principles of TOC. Each of these areas, and more, should be re-thought and re-worked in light of the TOC principles.
In other words, while grasping intellectually the 5 steps and the essence of TOC is truly simple, the implications it has for nearly everything in an organization are extremely far-reaching. The principles impact things that people have done a certain way in organizations for a long time. They encounter many points where people have inertia built from years of past practice. So while the principles can be grasped simply, we immediately bump into the need to change a significant number of things people have always done differently--if you will we activate a lot of inertia.
Since people are not generally in the habit of re-thinking everything just because they have been exposed to a new concept like TOC, there is little actual recognition that so many things are affected by the new insight of TOC. So people don't even realize in most cases many of the things that should be changed. As people we simply carry on as we always have until something causes us to see the need to change it.
I think this is exactly what we encounter when we try to bring TOC into an organization. People get the principles quickly, on an intellectual level, and because they are so simple conceptually, they have the mistaken perception that implementation will also be simple. "Yeah, we get it, find the weakest link, exploit it, etc. What's the big deal?" But the things they don't are the implications of the concepts.
I suspect that people like myself who are working to help companies really capitalize on TOC may have fallen into the same trap. We understand TOC so well and have made such a profound shift in our own thinking, that we have forgotten the magnitude of the inertia that TOC bumps into in organizations when we try to implement it. And as a result of this I think we haven't done all we can or should do to address the real barrier to implementing TOC, which is how to overcome the organizational inertia (not the intellectual inertia of understanding TOC). I don't think we have focused enough of our efforts on strategies, tools, processes, techniques, models, roadmaps, etc. to help expose the impact of TOC on existing organizational behaviors, and how to shift those behaviors.
I have a lot more to say on the subject, but I really need to know what you think about it, and whether you think my observations are sound.
Showing posts with label Goldratt. Show all posts
Showing posts with label Goldratt. Show all posts
Friday, March 25, 2011
Wednesday, March 16, 2011
TOC in a word: Focus
Many others, including Goldratt, have already suggested that if you had to summarize TOC in a single word, the best word is "focus." The essence of the core principles of TOC (5 steps, thinking processes, etc.) is that they provide a way to separate the important few from the trivial many. I agree this is at the essence of TOC, and in and of itself is extremely powerful.
Following the principles one is able to look at a large, highly complex organization, no matter what it does, and define where the key points are to improve it. Without a similar insight, one is almost forced into the historical solution for dealing with complex systems--breaking them down into some smaller subsystems that we feel we can get our hands around. We know that this creates distortion, usually large distortions, because the individual components of an organization are not usually smaller versions of the whole, they are "pieces" of the whole. And as soon as we try to optimize the little parts we have divided the organization into, we lose touch with how they are supposed to work together.
The fact that TOC provides a process and a logic to effectively see where to focus without distorting the picture is enormously powerful. If we know where are the weakest links, the constraints, in our system we know which actions will lead to improving the organization, and which will not. It gives us a methodology for brushing aside those things which will not improve the whole, those many things that occupy most of people's time.
This topic reminds me of my first job in industry, with a large multi-national conglomerate. At my facility we had a team of engineers who each year were assigned ambitious cost reduction targets. Each year these people worked diligently to devise creative solutions to reduce costs in every area of the business. And year after year they successfully achieved their targets, saving 2 minutes of labor here, 6 minutes of re-work there, and of course all of the overheads associated with that labor. Yet year after year, in spite of these millions of annual cost savings our division's bottom line remained largely unchanged. Why? because almost none of their efforts were targeted at the organization's constraint.
What would the power of focus have meant to them and to the company? I can only imagine if they had had the ability first to pinpoint the constraints in the business what kinds of real gains they would have been able to make. So much effort was spent optimizing non-constraints, reducing times at steps with extra capacity that did not limit Throughput, and which produced only paper cost-savings because we couldn't lay-off 2/17's of a person. (In any event we had a policy of not laying off staff due to productivity improvements, we would just transfer them somewhere else!)
Without increasing any of the skills, training or tools of those engineers, but simply by providing them with a means of focusing their efforts using TOC they could have had a profound, and almost immediate, impact on the company's bottom line. In my mind that's the definition of a powerful solution--change one little thing and the results increase dramatically.
Another illustration of the potential of focus is management time. Ask nearly every manager what s/he is focusing on and you will get a list of half a dozen or more items--by definition the opposite of "focus". I have even gone so far as to ask managers, if they had "two full days a week, uninterrupted, to focus on solving one problem in their organization (no matter what that problem is) would they be able to make meaningful, significant improvement in that area?" Universally the answer I get is "yes, absolutely". So why don't they do it? Because they don't have "the luxury" of being able to focus like that, they must manage all of the other things as well.
It's interesting because managers immediately get the fact that this lack of focus means that problems rarely get solved, they get at best "band-aids" which will require further time from them in the future to re-patch. They recognize that intuitively not all things are equally important and that focusing on a few would produce lasting and significant improvements, but our habits, and the mode of operation that drives our organizations undermines their ability to do it. In my experience this is prevalent even in companies where there is widespread awareness and appreciation of Theory of Constraints.
I find this paradox interesting and worth exploring further. I would very much like your thoughts on the subject of focus and the gap between the "focus" suggested by TOC as a set of core principles and the focus, or lack thereof, we see in reality. If you're interested I have a few more thoughts I might share on the subject.
Following the principles one is able to look at a large, highly complex organization, no matter what it does, and define where the key points are to improve it. Without a similar insight, one is almost forced into the historical solution for dealing with complex systems--breaking them down into some smaller subsystems that we feel we can get our hands around. We know that this creates distortion, usually large distortions, because the individual components of an organization are not usually smaller versions of the whole, they are "pieces" of the whole. And as soon as we try to optimize the little parts we have divided the organization into, we lose touch with how they are supposed to work together.
The fact that TOC provides a process and a logic to effectively see where to focus without distorting the picture is enormously powerful. If we know where are the weakest links, the constraints, in our system we know which actions will lead to improving the organization, and which will not. It gives us a methodology for brushing aside those things which will not improve the whole, those many things that occupy most of people's time.
This topic reminds me of my first job in industry, with a large multi-national conglomerate. At my facility we had a team of engineers who each year were assigned ambitious cost reduction targets. Each year these people worked diligently to devise creative solutions to reduce costs in every area of the business. And year after year they successfully achieved their targets, saving 2 minutes of labor here, 6 minutes of re-work there, and of course all of the overheads associated with that labor. Yet year after year, in spite of these millions of annual cost savings our division's bottom line remained largely unchanged. Why? because almost none of their efforts were targeted at the organization's constraint.
What would the power of focus have meant to them and to the company? I can only imagine if they had had the ability first to pinpoint the constraints in the business what kinds of real gains they would have been able to make. So much effort was spent optimizing non-constraints, reducing times at steps with extra capacity that did not limit Throughput, and which produced only paper cost-savings because we couldn't lay-off 2/17's of a person. (In any event we had a policy of not laying off staff due to productivity improvements, we would just transfer them somewhere else!)
Without increasing any of the skills, training or tools of those engineers, but simply by providing them with a means of focusing their efforts using TOC they could have had a profound, and almost immediate, impact on the company's bottom line. In my mind that's the definition of a powerful solution--change one little thing and the results increase dramatically.
Another illustration of the potential of focus is management time. Ask nearly every manager what s/he is focusing on and you will get a list of half a dozen or more items--by definition the opposite of "focus". I have even gone so far as to ask managers, if they had "two full days a week, uninterrupted, to focus on solving one problem in their organization (no matter what that problem is) would they be able to make meaningful, significant improvement in that area?" Universally the answer I get is "yes, absolutely". So why don't they do it? Because they don't have "the luxury" of being able to focus like that, they must manage all of the other things as well.
It's interesting because managers immediately get the fact that this lack of focus means that problems rarely get solved, they get at best "band-aids" which will require further time from them in the future to re-patch. They recognize that intuitively not all things are equally important and that focusing on a few would produce lasting and significant improvements, but our habits, and the mode of operation that drives our organizations undermines their ability to do it. In my experience this is prevalent even in companies where there is widespread awareness and appreciation of Theory of Constraints.
I find this paradox interesting and worth exploring further. I would very much like your thoughts on the subject of focus and the gap between the "focus" suggested by TOC as a set of core principles and the focus, or lack thereof, we see in reality. If you're interested I have a few more thoughts I might share on the subject.
Thursday, November 29, 2007
Project Lessons: Focus on Completing Projects On-time, Not Completing Tasks On-time
It may seem counterintuitive, to say we shouldn’t focus on completing tasks on-time, in order to deliver our projects on-time. After all isn’t it obvious that if we complete each task in a project on-time, that the project will finish on-time? This statement is of course true, but within it hides another trap for people managing projects.
Since this method of driving timely task completions is probably the most widely used strategy for trying to bring projects in on-time, we can look at public data on project performance to evaluate its effectiveness. Various public studies (Forrester, Gartner, World Bank) illustrate the widespread problem of bringing projects in on time. Depending on the source the studies show 40% to 67% of projects miss their planned delivery date. While there are many factors at work here it’s pretty clear from the data that this method is not very effective at overcoming the challenges of bringing projects in on-time. But why?
The trap in this methodology comes from two elements of managing projects. The first element is that uncertainty on projects is very high, making it very rare and almost impossible to finish every task on-time. Unplanned events, changes, disruptions, resources not being available, etc. wreak havoc with even the best plans, resulting in many tasks sliding beyond their planned completion date. The result being that the project as a whole is delayed and misses its completion date.
The second element is the human dynamic that results from any attempts to focus on task completion dates. If an organization makes completing each task on-time important, how will people respond? We all know the validity of the statement “tell me how you measure me and I will tell you how I am going to behave.” Even if there is not a formal measurement, but just a management focus, expectation, or even the belief that management judges something to be important, it will impact how people behave. So how does making timely task completion impact people’s behavior in project environments?
The first way is pretty obvious, people will provide and negotiate for task durations that are conservative, for task durations they are confident that they can achieve. No one wants to do a bad job, and when management drives timely task completions people will respond by increasing their estimates of how long a task will take. This is not bad behavior on their part, after all the reality of projects is uncertainty. No one really knows how long a task is going to take this time, what challenges we will encounter, whether the specifications will have changed, what other work they may be required to do at the same time, etc. So in order to provide a reliable task duration people will naturally provide estimate that they believe is achievable, even if things go wrong.
This behavior is magnified if management routinely uses the practice of trimming the durations of people’s estimates to insure that project timelines meet the organization’s business needs. If people know their estimates will be trimmed anyway, they will add additional padding in their estimates. It is identical to the dynamics organizations experience with budgeting. Every manager knows that if he needs a million dollars to run his department next year, that he better ask for much more initially, in order to end up with the million he needs. The same “game” is played with task durations. And again it’s not bad behavior, it’s people trying to do the best job they can within the rules of the system.
So, one result of focusing on completing tasks on-time is that the task estimates (and therefore the project plans as a whole) get inflated. This however creates for us an apparent paradox. How can it be that our task estimates are so inflated and still we cannot meet them reliably?
Again basic human behavior is at work, but this time it is the behavior during project execution, not in the planning stage. Imagine the reality: we have a task estimate that provides us with what looks like ample safety time, because we have buffered it for uncertainty and other factors in order to be able to deliver it reliably. So when the work actually arrives, there is a clear sense that there is ample time to complete the task. In other words there is very little sense of urgency to start the task immediately, and in any event most project resources are overloaded with other things already so it might even be that there is not the ability to start the task right away. We know this dynamic from our school days. We know the test is out there, but when there is the perception that “we have plenty of time” there is really no need to start studying. Often we end up beginning only the night before, or at most a few days ahead of time.
On projects this translates to the reality that some, often most, of the safety time gets wasted at the front end of the task because of lack of urgency. Now if there is any unforeseen delay, change, or hiccup of any sort on the work, the task date will in all likelihood be missed. So even though we have put safety time into the task estimate, common human behavior will in most cases cause it to be wasted.
While this is not hard to picture in reality, a sharp mind will point out that it will not happen in all cases, and even when it does, sometimes a task will go smoothly and could be finished ahead of the planned time. This is in fact true. Unfortunately when an organization places importance on finishing tasks on-time, it is at the same time creating a strong dis-incentive for people to finish earlier than expected. Again picture the reality: what is likely to happen if someone reports finishing a task a week ahead of schedule? What will be the expectation for a similar task on the next project? Of course, finishing early will result in the task duration being cut the next time, again just as not spending all of your budget in a given year will result in your getting less the next year. It’s obvious that you padded the estimate so you can expect it to be cut even more the next time.
Similarly if a task is ready ahead of time the committed employee is also likely to spend the remaining time “improving” the work, making it even better than it was. As long as there is still time available people are likely to fill it with efforts to make the work as good as possible. We all know this behavior to the degree that it has a common name, Parkinson’s Law: the work expands to fill the time available. The result is that task rarely finish (much) ahead of their planned times, so the potential gains are typically lost in the process.
In total some tasks finishing late, while others finish on-time, and almost no tasks finish early. The sum of this is that projects will finish late in many cases, exactly what the studies and most people’s experience shows. Of course if finishing a project on-time is a mandate there are alternatives that will mask the reality with apparently good on-time performance. Organizations can turn to a reduction in the scope of a project or to increasing their spending to compensate for the delays. But while the project may finish on-time in our metrics, it often does so only at the expense of the original scope or the original budget. In reality then, even organizations with “better” than average on-time performance are being directly impacted by the methodology of focusing on completing tasks on-time.
Unfortunately a common reaction to the poor project performance is to sharpen the focus on timely task completion. It is not uncommon to see managers get more and more involved in the details of managing individual tasks in the effort to “get control” of the situation and help insure that more tasks finish on-time. Not surprisingly this only heightens the behavioral response described above. The more important it becomes for people to hit task dates, the stronger the above behaviors will be. So in their efforts to address the problem, most organizations only serve to solidify the underlying causes of it.
It may be possible to change these underlying human behaviors, but it seems to me that the better and faster way is to change the system of managing projects. For more on this see other postings in this blog on Critical Chain project management, or send you specific information request to info@tocc.com.
Since this method of driving timely task completions is probably the most widely used strategy for trying to bring projects in on-time, we can look at public data on project performance to evaluate its effectiveness. Various public studies (Forrester, Gartner, World Bank) illustrate the widespread problem of bringing projects in on time. Depending on the source the studies show 40% to 67% of projects miss their planned delivery date. While there are many factors at work here it’s pretty clear from the data that this method is not very effective at overcoming the challenges of bringing projects in on-time. But why?
The trap in this methodology comes from two elements of managing projects. The first element is that uncertainty on projects is very high, making it very rare and almost impossible to finish every task on-time. Unplanned events, changes, disruptions, resources not being available, etc. wreak havoc with even the best plans, resulting in many tasks sliding beyond their planned completion date. The result being that the project as a whole is delayed and misses its completion date.
The second element is the human dynamic that results from any attempts to focus on task completion dates. If an organization makes completing each task on-time important, how will people respond? We all know the validity of the statement “tell me how you measure me and I will tell you how I am going to behave.” Even if there is not a formal measurement, but just a management focus, expectation, or even the belief that management judges something to be important, it will impact how people behave. So how does making timely task completion impact people’s behavior in project environments?
The first way is pretty obvious, people will provide and negotiate for task durations that are conservative, for task durations they are confident that they can achieve. No one wants to do a bad job, and when management drives timely task completions people will respond by increasing their estimates of how long a task will take. This is not bad behavior on their part, after all the reality of projects is uncertainty. No one really knows how long a task is going to take this time, what challenges we will encounter, whether the specifications will have changed, what other work they may be required to do at the same time, etc. So in order to provide a reliable task duration people will naturally provide estimate that they believe is achievable, even if things go wrong.
This behavior is magnified if management routinely uses the practice of trimming the durations of people’s estimates to insure that project timelines meet the organization’s business needs. If people know their estimates will be trimmed anyway, they will add additional padding in their estimates. It is identical to the dynamics organizations experience with budgeting. Every manager knows that if he needs a million dollars to run his department next year, that he better ask for much more initially, in order to end up with the million he needs. The same “game” is played with task durations. And again it’s not bad behavior, it’s people trying to do the best job they can within the rules of the system.
So, one result of focusing on completing tasks on-time is that the task estimates (and therefore the project plans as a whole) get inflated. This however creates for us an apparent paradox. How can it be that our task estimates are so inflated and still we cannot meet them reliably?
Again basic human behavior is at work, but this time it is the behavior during project execution, not in the planning stage. Imagine the reality: we have a task estimate that provides us with what looks like ample safety time, because we have buffered it for uncertainty and other factors in order to be able to deliver it reliably. So when the work actually arrives, there is a clear sense that there is ample time to complete the task. In other words there is very little sense of urgency to start the task immediately, and in any event most project resources are overloaded with other things already so it might even be that there is not the ability to start the task right away. We know this dynamic from our school days. We know the test is out there, but when there is the perception that “we have plenty of time” there is really no need to start studying. Often we end up beginning only the night before, or at most a few days ahead of time.
On projects this translates to the reality that some, often most, of the safety time gets wasted at the front end of the task because of lack of urgency. Now if there is any unforeseen delay, change, or hiccup of any sort on the work, the task date will in all likelihood be missed. So even though we have put safety time into the task estimate, common human behavior will in most cases cause it to be wasted.
While this is not hard to picture in reality, a sharp mind will point out that it will not happen in all cases, and even when it does, sometimes a task will go smoothly and could be finished ahead of the planned time. This is in fact true. Unfortunately when an organization places importance on finishing tasks on-time, it is at the same time creating a strong dis-incentive for people to finish earlier than expected. Again picture the reality: what is likely to happen if someone reports finishing a task a week ahead of schedule? What will be the expectation for a similar task on the next project? Of course, finishing early will result in the task duration being cut the next time, again just as not spending all of your budget in a given year will result in your getting less the next year. It’s obvious that you padded the estimate so you can expect it to be cut even more the next time.
Similarly if a task is ready ahead of time the committed employee is also likely to spend the remaining time “improving” the work, making it even better than it was. As long as there is still time available people are likely to fill it with efforts to make the work as good as possible. We all know this behavior to the degree that it has a common name, Parkinson’s Law: the work expands to fill the time available. The result is that task rarely finish (much) ahead of their planned times, so the potential gains are typically lost in the process.
In total some tasks finishing late, while others finish on-time, and almost no tasks finish early. The sum of this is that projects will finish late in many cases, exactly what the studies and most people’s experience shows. Of course if finishing a project on-time is a mandate there are alternatives that will mask the reality with apparently good on-time performance. Organizations can turn to a reduction in the scope of a project or to increasing their spending to compensate for the delays. But while the project may finish on-time in our metrics, it often does so only at the expense of the original scope or the original budget. In reality then, even organizations with “better” than average on-time performance are being directly impacted by the methodology of focusing on completing tasks on-time.
Unfortunately a common reaction to the poor project performance is to sharpen the focus on timely task completion. It is not uncommon to see managers get more and more involved in the details of managing individual tasks in the effort to “get control” of the situation and help insure that more tasks finish on-time. Not surprisingly this only heightens the behavioral response described above. The more important it becomes for people to hit task dates, the stronger the above behaviors will be. So in their efforts to address the problem, most organizations only serve to solidify the underlying causes of it.
It may be possible to change these underlying human behaviors, but it seems to me that the better and faster way is to change the system of managing projects. For more on this see other postings in this blog on Critical Chain project management, or send you specific information request to info@tocc.com.
Thursday, November 8, 2007
New Series
Writing these long blogs has not proven easy for me and has resulted in long gaps between entries. Additionally they probably aren't read as widely as shorter entries. So in an effort to get more content "out there" and to promote wider reading and dialogue I have decided to blog in the more traditional way in smaller parcels.
Someone suggested a series of smaller entries on some of the key learnings TOC has generated over the years, so I am going to try. Let me know what you think, the first series I am going to offer is "lessons in Learned about managing Projects, Strategies for delivering more projects, faster."
I hope you enjoy it.
Kevin
Someone suggested a series of smaller entries on some of the key learnings TOC has generated over the years, so I am going to try. Let me know what you think, the first series I am going to offer is "lessons in Learned about managing Projects, Strategies for delivering more projects, faster."
I hope you enjoy it.
Kevin
Monday, July 30, 2007
Product Octane: the overlooked lever in TOC
It has always amazed me that more companies are not capitalizing on the leverage of the concept of product octane in driving higher profits. Octane is Goldratt's concept of calculating the Throughput per time of your constraint. Thousands of people over the years have been introduced to this concept through the famous PQ quiz, and the Socratic simulator tool used in so many TOC workshops yet the penetration of this simple yet enormous powerful concept is very low.
The concept is pretty straightforward. Given that you have a constraint resource that limits your system from producing more and more Throughput, the aim is to generate not just more product volume through it, but really more dollar volume for every minute of this constraint. Some products may generate more overall Throughput, but take much longer at the constraint. Consider the following data on two products, from Goldratt's PQ exercise:
Product P Product Q
Selling Price $90 $100
Raw Material $45 $40
Throughput $45 $60
Time at Constraint 15min 30min
T/ constraint time $3/min $2/min
It is clear that in the same 30 minutes of constraint time you can produce either two P's or 1 Q. While Q has a higher T/ unit, considering that the constraint limits your output, producing the two P's produces 50% more T than producing the Q's.
What makes this even more interesting is when you consider the standard cost view of P and Q. P takes a total of 55 minutes of labor to produce, and Q just 50 minutes of labor. This means the labor (and overhead) costs assigned to Q will be smaller than those of P in standard (or ABC) costing. So every cost system in the world will show Q as the better product. The reality, as is shown very nicely by the exercise, is that companies will make much higher profits (by 50% in this case) if they sell P's instead of the "higher margin" Q's.
The exercise shows the principle, but the reality for mist orgainzations is typically much more lucrative. We have done an analysis of the portfolios of more than 100 companies over the years to calculate the octane of all of their products. The spread between the highest and lowest octane products has never been smaller than 2x, and is usually between 10x and 20x. Meaning the lowest octane products produce 1/10th of the T/hour of the highest. Assuming that we look at an hour's worth of time at the constraint, the high octane products would produce 10 times the Throughput of the lower octane products.
More often than not most of the highest octane products are the ones with the lowest margins. And since most sales people and executives focus on margins, it also means that they are the products receiving the least attention from sales. Many times it happens that a company is the process of getting ready to trim these products from their portfolios as poor performers. When they realize that these are actually the gems in their portfolios they start to re-think their strategy.
It is not hard to calculate that shifting even a portion of the company's sales from the low octane (maybe high-margin) products to the higher octane products will produce a very large increase in revenues and profits. This analysis also creates the opportunity for companies to set their prices in a way that drives more of the high octane business their way.
Consider that for low margin products, companies will want to increase prices, this will naturally drive demand away from the company. But if these products that are considered low margin turn out to be very high octane relative to the other products, there is actually the opportunity to lower prices (which will reduce the octane as well) enough to drive more volume of these products their way, and still maintain relatively high octane.
This simple principle seems to have been lost from many TOC practitioners and companies who have deployed the TOC methodology, yet it holds the potential to rapidly increase profits without requiring new capital or labor. If you have any doubts about it, try it with some of the products in your company. Calculate the Throughput for a number of products (selling price minus material, outside services and commissions) and divide it by the amount of constraint time the product needs. You should see a spread of at least 2x, and probably closer to 10x, between the highest and lowest octane products.
To see just how much of an opportunity your company is missing, check the margins for these products as well. If there are some items with high margins that are low on the octane scale, or with low margins that are high on the octane scale, it means that there are significant opportunities to accelerate profits quickly. From my 20 years experience, I'd be very surprised if you found there weren't any opportunities...
The concept is pretty straightforward. Given that you have a constraint resource that limits your system from producing more and more Throughput, the aim is to generate not just more product volume through it, but really more dollar volume for every minute of this constraint. Some products may generate more overall Throughput, but take much longer at the constraint. Consider the following data on two products, from Goldratt's PQ exercise:
Product P Product Q
Selling Price $90 $100
Raw Material $45 $40
Throughput $45 $60
Time at Constraint 15min 30min
T/ constraint time $3/min $2/min
It is clear that in the same 30 minutes of constraint time you can produce either two P's or 1 Q. While Q has a higher T/ unit, considering that the constraint limits your output, producing the two P's produces 50% more T than producing the Q's.
What makes this even more interesting is when you consider the standard cost view of P and Q. P takes a total of 55 minutes of labor to produce, and Q just 50 minutes of labor. This means the labor (and overhead) costs assigned to Q will be smaller than those of P in standard (or ABC) costing. So every cost system in the world will show Q as the better product. The reality, as is shown very nicely by the exercise, is that companies will make much higher profits (by 50% in this case) if they sell P's instead of the "higher margin" Q's.
The exercise shows the principle, but the reality for mist orgainzations is typically much more lucrative. We have done an analysis of the portfolios of more than 100 companies over the years to calculate the octane of all of their products. The spread between the highest and lowest octane products has never been smaller than 2x, and is usually between 10x and 20x. Meaning the lowest octane products produce 1/10th of the T/hour of the highest. Assuming that we look at an hour's worth of time at the constraint, the high octane products would produce 10 times the Throughput of the lower octane products.
More often than not most of the highest octane products are the ones with the lowest margins. And since most sales people and executives focus on margins, it also means that they are the products receiving the least attention from sales. Many times it happens that a company is the process of getting ready to trim these products from their portfolios as poor performers. When they realize that these are actually the gems in their portfolios they start to re-think their strategy.
It is not hard to calculate that shifting even a portion of the company's sales from the low octane (maybe high-margin) products to the higher octane products will produce a very large increase in revenues and profits. This analysis also creates the opportunity for companies to set their prices in a way that drives more of the high octane business their way.
Consider that for low margin products, companies will want to increase prices, this will naturally drive demand away from the company. But if these products that are considered low margin turn out to be very high octane relative to the other products, there is actually the opportunity to lower prices (which will reduce the octane as well) enough to drive more volume of these products their way, and still maintain relatively high octane.
This simple principle seems to have been lost from many TOC practitioners and companies who have deployed the TOC methodology, yet it holds the potential to rapidly increase profits without requiring new capital or labor. If you have any doubts about it, try it with some of the products in your company. Calculate the Throughput for a number of products (selling price minus material, outside services and commissions) and divide it by the amount of constraint time the product needs. You should see a spread of at least 2x, and probably closer to 10x, between the highest and lowest octane products.
To see just how much of an opportunity your company is missing, check the margins for these products as well. If there are some items with high margins that are low on the octane scale, or with low margins that are high on the octane scale, it means that there are significant opportunities to accelerate profits quickly. From my 20 years experience, I'd be very surprised if you found there weren't any opportunities...
Thursday, June 14, 2007
TOC Stories: Accelerating Projects
The remarkable success of Goldratt's business novel The Goal demonstrated the power of using a story to communicate business concepts. While this concept is not new, it had not been widely applied to business principles before Goldratt did it in 1984. More than 20 years later the book is still selling annually quantities most business authors would be happy to see in a lifetime of book sales.
Following this model I have created a number of stories based on real experiences we have had with organizations applying TOC. The following story is true and the results are real, though I have fictionalized the company name and blurred some details so as not to expose any proprietary information. I hope that you will find this format an interesting vehicle for learning more about TOC and the potential to be gained from its application.
The Story
“Big Pharma” develops, produces, and sells pharmaceuticals. They had a big fish on the line, a blockbuster drug with sales expected to be in the billions per year. And they were in a race. A competitor was working on a very similar product and the first company to get their product to market would secure the large pent up demand for the new drug. Arriving second would mean having to displace the other company’s product, a much slower, more expensive proposition. Being first to the market was easily worth billions in the first year alone.
One can imagine that with so much at stake, money was flowing freely in both companies. But outsourcing and adding staff didn’t always accelerate the process. As one executive said, “I know we need more people but I don’t know where and how many. Every time I have done that in the past all it did was increase my costs.”
The first need the company had was to understand exactly where the constraint was in their development cycle. As the drug was late in the development process, where most of the investment and effort is in the clinical trials to test the effectiveness of the drug, this was the area of most concern. When they used TOC to analyze their flow and understand where the bottlenecks were it became apparent that the real constraint was in an unlikely place, the clinical pharmacy. The clinical pharmacy supplies the drugs, and the placebos, that are used in the clinical trials conducted by doctors in their hospitals around the world. Doctors enroll patients and then need precisely prepared supplies of the drug and placebos (to insure the scientific validity of the trials) according to a pre-planned timeline. Missing the timeline would mean the loss of the test patients delaying the completion of the needed scientific data to get the drug approved.
The Obstacles
At this point in the drug approval process there are large volumes of clinical trials that need to be done and the weight of the workload had brought the clinical pharmacy to its knees. The planned preparation time for delivering the samples had been 8 weeks, but they were already extended out to 10 weeks, and were frequently missing even those delivery dates. On the horizon was an even bigger volume of work to meet the demands of the last trials before the submission of the new drug. The company had explored outsourcing the process to a contractor, but it was going to take months to validate them as a supplier and moving the process out of the company would also extend the lead times due to the approvals that were needed on each batch of products. Adding people to their existing operation would also take time, especially for some of the more unique jobs where things were breaking down already.
The climate in the clinical pharmacy made it not exactly opened to improvement. The group had recently been moved off the main campus of the company to make room for the growing staff there, resulting in a negative impact on the workers quality of life, and a loss of social connections to their colleagues in other departments. Moving to a remote physical location was also slowing down certain approvals and sign-offs from managers who remained on the main site. Things that had been handled in five minutes by walking over to a person’s desk, now turned into unanswered voice and e-mails, adding to the delays. In addition, once the analysis showed where the real constraint was, and with the mounting pressure of the growing workload, the people naturally became increasingly defensive, and protective of their turf. “Helping” people under these circumstances to improve their process was not exactly the ideal situation.
The Opportunity
The opportunity that existed for the clinical pharmacy was to understand much better how work flowed, or in their case piled up and trickled, through their system. The conventional methods of project management had long been established in the company with all of the usual effects apparent:
Projects were consistently behind schedule or late
Resources were not available when needed, even if promised
There was constant firefighting, with priorities shifting continually
There were too many changes and too much re-work
Necessary things (specifications, approvals, documentation) were not available when needed
They needed to understand how their mode of operating caused these effects, and to see how the Critical Chain approach would enable them to address the underlying causes of these symptoms. One of the most important of these causes was bad-multitasking, in other words stopping work on a task before it is completed to work on another more urgent one. It was widely believed that the “earlier you start a project, the early it will finish.” This had resulted in the large piles of work evident at each step of the process. With the increasing pressure brought on by the growing demand of trials and their missing delivery dates, bad-multitasking was the daily reality.
The other major contributor to the situation was the common management practice of focusing on the on-time completion of each tasks, in the mistaken belief that this would result in projects finishing on-time. Instead, as it does in most environments, it had resulted in people inflating their task estimates to protect themselves. With the growing work loads and the large piles of tasks at each step of the process (there were no fewer than 5 tasks on each person’s desk at any given time), this meant that most of the time it took to complete a task was waiting in the queue to get started. All the data they had showed that the time to complete a given task was getting longer, and that people’s estimates were in line with these times. What they didn’t understand was that there was a different way to manage the projects that would enable them to reduce both the individual tasks times and the overall project durations.
The solution to both of the core problems already existed in the critical chain process. First it was essential to reduce the work-in-process in the system, to shrink the queues at each step so the work would flow faster, and to eliminate the pressure to multi-task that was coming from having so many active projects that were not progressing. Through self-discovery workshops using interactive games and exercises, the clinical pharmacy’s managers realized for themselves how their conventional management methods were creating the problems they faced. They saw also how these practices could be modified to create very different results. While the changes were significant, the tools and processes enabled them not only to accept them but to take a strong measure of ownership in them.
Applying the methodology with the support of Concerto® software, the clinical pharmacy made the three fundamental changes for Critical Chain:
· They loaded projects into their pipeline only to the level that their most heavily loaded resource (their constraint or bottleneck) could handle them. This meant staggering the projects, starting many of them later than they had previously planned.
· They cut the times of each task by 50%, aggregated this time into a project buffer placed at the end of the project plan to protect them against the uncertainties and variability inherent in their projects. Then they cut this buffer in half, reducing the overall project duration to about seven weeks, from a little more than the previous ten weeks.
· They began to drive priorities only according to the rate at which these buffers were being consumed. In other words, tasks were worked based on which project had the least amount of buffer left relative to the amount of work remaining on the project.
By loading the projects based on their real capacity, the team insured that there would not be increasing backlogs of work in the system, thus the work would flow much faster without having to wait. With fewer open tasks the opportunities to multitask were greatly reduced, and work spent much less time waiting in queues to be worked. Stripping out much of the safety time from the tasks, then did not create any problems as most of this time had been needed for the queues. By placing it in the buffer at the end meant that it was visible to all, so they had a clear barometer for seeing if a project was tracking on time. It also made the safety time available for anyone whose work might take longer than expected due to unforeseen issues. But with work flowing more rapidly than before much less total safety time would be needed, so the overall project times went down. Shifting the behavior to focus on the most at-risk tasks insured that these projects got first attention. Projects with more safety, could wait without jeopardizing their delivery date. The team adjusted their measurements and indicators to match the new model.
The Results
Right from the beginning things improved. Within one month on-time delivery went from almost zero, to 50%. The lead time to deliver was reduced to seven weeks from ten, and within three months on-time delivery was at 100%, with projects completed up 40% After the first wave of improvements and stabilizing on-time deliveries at 98+%, the team realized there was the opportunity to further reduce the project lead times. Lead times were cut first to six weeks and then to three, just four months after launch. After six months the number of projects completed had doubled from the original rate, while on-time performance held steady at the new level.
The impact on the drug launch was remarkable. By addressing the constraint of the larger system the entire time-to-market of the drug was reduced. The rate of the clinical trials was accelerated and what had been an estimated advantage of “a couple of weeks” over the competition resulted in Big Pharma launching their drug four months ahead of the competition. During it’s the first year on the market their product outsold the competitors by more than $1 billion dollars, but it had cost less than $200,000 for the full implementation.
Since then Big Pharma expanded the use of Critical Chain to all of its global clinical pharmacies, to other critical product development processes, to facility construction and upgrade, and manufacturing process validation, with similar results. But these are subject for other stories.
Of course not every company has the leverage of a multi-billion dollar drug, but cutting project durations by half, while increasing output substantially, and moving to nearly 100% on time, can still has substantial benefits for almost every company. We hope you have enjoyed this installment in our series.
To comment on this story or to inquire about other stories you'd like to see, e-mail me at kfox@tocc.com
Following this model I have created a number of stories based on real experiences we have had with organizations applying TOC. The following story is true and the results are real, though I have fictionalized the company name and blurred some details so as not to expose any proprietary information. I hope that you will find this format an interesting vehicle for learning more about TOC and the potential to be gained from its application.
The Story
“Big Pharma” develops, produces, and sells pharmaceuticals. They had a big fish on the line, a blockbuster drug with sales expected to be in the billions per year. And they were in a race. A competitor was working on a very similar product and the first company to get their product to market would secure the large pent up demand for the new drug. Arriving second would mean having to displace the other company’s product, a much slower, more expensive proposition. Being first to the market was easily worth billions in the first year alone.
One can imagine that with so much at stake, money was flowing freely in both companies. But outsourcing and adding staff didn’t always accelerate the process. As one executive said, “I know we need more people but I don’t know where and how many. Every time I have done that in the past all it did was increase my costs.”
The first need the company had was to understand exactly where the constraint was in their development cycle. As the drug was late in the development process, where most of the investment and effort is in the clinical trials to test the effectiveness of the drug, this was the area of most concern. When they used TOC to analyze their flow and understand where the bottlenecks were it became apparent that the real constraint was in an unlikely place, the clinical pharmacy. The clinical pharmacy supplies the drugs, and the placebos, that are used in the clinical trials conducted by doctors in their hospitals around the world. Doctors enroll patients and then need precisely prepared supplies of the drug and placebos (to insure the scientific validity of the trials) according to a pre-planned timeline. Missing the timeline would mean the loss of the test patients delaying the completion of the needed scientific data to get the drug approved.
The Obstacles
At this point in the drug approval process there are large volumes of clinical trials that need to be done and the weight of the workload had brought the clinical pharmacy to its knees. The planned preparation time for delivering the samples had been 8 weeks, but they were already extended out to 10 weeks, and were frequently missing even those delivery dates. On the horizon was an even bigger volume of work to meet the demands of the last trials before the submission of the new drug. The company had explored outsourcing the process to a contractor, but it was going to take months to validate them as a supplier and moving the process out of the company would also extend the lead times due to the approvals that were needed on each batch of products. Adding people to their existing operation would also take time, especially for some of the more unique jobs where things were breaking down already.
The climate in the clinical pharmacy made it not exactly opened to improvement. The group had recently been moved off the main campus of the company to make room for the growing staff there, resulting in a negative impact on the workers quality of life, and a loss of social connections to their colleagues in other departments. Moving to a remote physical location was also slowing down certain approvals and sign-offs from managers who remained on the main site. Things that had been handled in five minutes by walking over to a person’s desk, now turned into unanswered voice and e-mails, adding to the delays. In addition, once the analysis showed where the real constraint was, and with the mounting pressure of the growing workload, the people naturally became increasingly defensive, and protective of their turf. “Helping” people under these circumstances to improve their process was not exactly the ideal situation.
The Opportunity
The opportunity that existed for the clinical pharmacy was to understand much better how work flowed, or in their case piled up and trickled, through their system. The conventional methods of project management had long been established in the company with all of the usual effects apparent:
Projects were consistently behind schedule or late
Resources were not available when needed, even if promised
There was constant firefighting, with priorities shifting continually
There were too many changes and too much re-work
Necessary things (specifications, approvals, documentation) were not available when needed
They needed to understand how their mode of operating caused these effects, and to see how the Critical Chain approach would enable them to address the underlying causes of these symptoms. One of the most important of these causes was bad-multitasking, in other words stopping work on a task before it is completed to work on another more urgent one. It was widely believed that the “earlier you start a project, the early it will finish.” This had resulted in the large piles of work evident at each step of the process. With the increasing pressure brought on by the growing demand of trials and their missing delivery dates, bad-multitasking was the daily reality.
The other major contributor to the situation was the common management practice of focusing on the on-time completion of each tasks, in the mistaken belief that this would result in projects finishing on-time. Instead, as it does in most environments, it had resulted in people inflating their task estimates to protect themselves. With the growing work loads and the large piles of tasks at each step of the process (there were no fewer than 5 tasks on each person’s desk at any given time), this meant that most of the time it took to complete a task was waiting in the queue to get started. All the data they had showed that the time to complete a given task was getting longer, and that people’s estimates were in line with these times. What they didn’t understand was that there was a different way to manage the projects that would enable them to reduce both the individual tasks times and the overall project durations.
The solution to both of the core problems already existed in the critical chain process. First it was essential to reduce the work-in-process in the system, to shrink the queues at each step so the work would flow faster, and to eliminate the pressure to multi-task that was coming from having so many active projects that were not progressing. Through self-discovery workshops using interactive games and exercises, the clinical pharmacy’s managers realized for themselves how their conventional management methods were creating the problems they faced. They saw also how these practices could be modified to create very different results. While the changes were significant, the tools and processes enabled them not only to accept them but to take a strong measure of ownership in them.
Applying the methodology with the support of Concerto® software, the clinical pharmacy made the three fundamental changes for Critical Chain:
· They loaded projects into their pipeline only to the level that their most heavily loaded resource (their constraint or bottleneck) could handle them. This meant staggering the projects, starting many of them later than they had previously planned.
· They cut the times of each task by 50%, aggregated this time into a project buffer placed at the end of the project plan to protect them against the uncertainties and variability inherent in their projects. Then they cut this buffer in half, reducing the overall project duration to about seven weeks, from a little more than the previous ten weeks.
· They began to drive priorities only according to the rate at which these buffers were being consumed. In other words, tasks were worked based on which project had the least amount of buffer left relative to the amount of work remaining on the project.
By loading the projects based on their real capacity, the team insured that there would not be increasing backlogs of work in the system, thus the work would flow much faster without having to wait. With fewer open tasks the opportunities to multitask were greatly reduced, and work spent much less time waiting in queues to be worked. Stripping out much of the safety time from the tasks, then did not create any problems as most of this time had been needed for the queues. By placing it in the buffer at the end meant that it was visible to all, so they had a clear barometer for seeing if a project was tracking on time. It also made the safety time available for anyone whose work might take longer than expected due to unforeseen issues. But with work flowing more rapidly than before much less total safety time would be needed, so the overall project times went down. Shifting the behavior to focus on the most at-risk tasks insured that these projects got first attention. Projects with more safety, could wait without jeopardizing their delivery date. The team adjusted their measurements and indicators to match the new model.
The Results
Right from the beginning things improved. Within one month on-time delivery went from almost zero, to 50%. The lead time to deliver was reduced to seven weeks from ten, and within three months on-time delivery was at 100%, with projects completed up 40% After the first wave of improvements and stabilizing on-time deliveries at 98+%, the team realized there was the opportunity to further reduce the project lead times. Lead times were cut first to six weeks and then to three, just four months after launch. After six months the number of projects completed had doubled from the original rate, while on-time performance held steady at the new level.
The impact on the drug launch was remarkable. By addressing the constraint of the larger system the entire time-to-market of the drug was reduced. The rate of the clinical trials was accelerated and what had been an estimated advantage of “a couple of weeks” over the competition resulted in Big Pharma launching their drug four months ahead of the competition. During it’s the first year on the market their product outsold the competitors by more than $1 billion dollars, but it had cost less than $200,000 for the full implementation.
Since then Big Pharma expanded the use of Critical Chain to all of its global clinical pharmacies, to other critical product development processes, to facility construction and upgrade, and manufacturing process validation, with similar results. But these are subject for other stories.
Of course not every company has the leverage of a multi-billion dollar drug, but cutting project durations by half, while increasing output substantially, and moving to nearly 100% on time, can still has substantial benefits for almost every company. We hope you have enjoyed this installment in our series.
To comment on this story or to inquire about other stories you'd like to see, e-mail me at kfox@tocc.com
Why Theory of Constraints?
I first got exposed to Goldratt and Theory of Constraints (TOC) soon after my father, Bob Fox, signed on as his partner in 1981. I began to work with him personally in 1985 and was amazed by what he taught me. I think most people agree that there is not enough common sense at work in the world, or certainly that we could use more of it. I have come to understand that calling an idea "common sense" is one of the highest forms of praise for something. It means that it is so valid, so right that it is obvious.
At the same time common sense is not common at all, and TOC falls very much into this category. The principles are so self-evident when one is exposed to them, yet at the same time they are far from common practice in most organizations. This paradox and the desire to bridge this gap have been the focus of my professional and much of my private life since I first came to grasp TOC more than 20 years ago.
I have learned that the real work in this change is not to grasp the concepts intellectually. As common sense this is not hard for peole. The real work is to overcome the inertia of our past practices and beliefs. TOC challenges and invalidates many assumptions widely held for many years in industry and in managing organizations, and in so doing replaces these assumptions, with different ones that better match with the reality of complex systems and organizations. These fundamental changes require people to re-think a host of decisions, processes, procedures, measurements and beliefs that they have about how best to manage a system. But such a fundamental "re-thinking" is not something that most people do as a matter of course when they are exposed to a new idea. And knowing the power of the grip of inertia on human beings this is neither an easy nor trivial task.
Over the years the things that I think have helped me and the many people and organizations I have worked with the most are the stories and discussions around specific applications of the fundamental TOC principles. Such stories demonstrate the logical extension of the TOC concepts and help to breakdown the inertia we all have with regard to re-thinking how we work. Some of the stories are mine, many are from others and from the companies I have worked with over the past 15+ years. I hope in them you will find both the insight and the inspiration to turn common sense into common practice in your world.
I hope that you will participate in sharing your stories, experiences and learnings, so that this will be a forum where the exchange of ideas and information will thrive. I also welcome your feedback about what is written here and what you would like to see more of here. My primary intent is to make this site as useful to the readers as possible. Thanks for visiting.
At the same time common sense is not common at all, and TOC falls very much into this category. The principles are so self-evident when one is exposed to them, yet at the same time they are far from common practice in most organizations. This paradox and the desire to bridge this gap have been the focus of my professional and much of my private life since I first came to grasp TOC more than 20 years ago.
I have learned that the real work in this change is not to grasp the concepts intellectually. As common sense this is not hard for peole. The real work is to overcome the inertia of our past practices and beliefs. TOC challenges and invalidates many assumptions widely held for many years in industry and in managing organizations, and in so doing replaces these assumptions, with different ones that better match with the reality of complex systems and organizations. These fundamental changes require people to re-think a host of decisions, processes, procedures, measurements and beliefs that they have about how best to manage a system. But such a fundamental "re-thinking" is not something that most people do as a matter of course when they are exposed to a new idea. And knowing the power of the grip of inertia on human beings this is neither an easy nor trivial task.
Over the years the things that I think have helped me and the many people and organizations I have worked with the most are the stories and discussions around specific applications of the fundamental TOC principles. Such stories demonstrate the logical extension of the TOC concepts and help to breakdown the inertia we all have with regard to re-thinking how we work. Some of the stories are mine, many are from others and from the companies I have worked with over the past 15+ years. I hope in them you will find both the insight and the inspiration to turn common sense into common practice in your world.
I hope that you will participate in sharing your stories, experiences and learnings, so that this will be a forum where the exchange of ideas and information will thrive. I also welcome your feedback about what is written here and what you would like to see more of here. My primary intent is to make this site as useful to the readers as possible. Thanks for visiting.
Subscribe to:
Posts (Atom)