tag:blogger.com,1999:blog-47382851076848922712024-03-06T14:59:57.009-05:00Theory of ConstraintsAll about Goldratt's Theory of Constraints, applications, stories, successes and challenges, and open dialogue on Theory of Constraints methodology for improving almost any kind of system. Particular focus on TOC applications in Project Management, Manufacturing and Distribution. All things Theory of Constraints, TOCKevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.comBlogger18125tag:blogger.com,1999:blog-4738285107684892271.post-38250617775647680832013-10-04T14:28:00.000-04:002013-10-04T14:28:39.360-04:00Nice Article on the perils of multi-taskingI came across this article today and wanted to pass it along. I've noticed a substantial increase the number of articles, studies, and general commentary on the adverse effects of multi-tasking. Here's another one that provides some additional evidence and insight. It's a very quick read, well-worth the time, but first finish what you're doing so you don't multi-task yourself!<br />
<br />
<a href="http://www.linkedin.com/today/post/article/20131003165549-128811924-why-focus-should-really-be-the-next-big-thing">http://www.linkedin.com/today/post/article/20131003165549-128811924-why-focus-should-really-be-the-next-big-thing</a>Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com0tag:blogger.com,1999:blog-4738285107684892271.post-25282318886154631902013-08-27T19:38:00.002-04:002013-10-04T14:29:47.417-04:00The under-appreciated importance of ExecutionI came across this nice piece on Execution the other day and since I've recently been writing about the very subject I thought I'd share the link. The author makes some very interesting points about the common aversion of many executives to execution as a tactical matter that is beneath them, and shares thoughts from Larry Bossidy and Ram Charan's excellent book, <em>Execution- The Discipline of Getting Things Done. </em>It's a short but well worthwhile read.<br />
<br />
<a href="http://www.linkedin.com/today/post/article/20130826054157-175081329-the-most-underestimated-skill-of-a-great-leader?trk=tod-posts-art">http://www.linkedin.com/today/post/article/20130826054157-175081329-the-most-underestimated-skill-of-a-great-leader?trk=tod-posts-art</a>-Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com0tag:blogger.com,1999:blog-4738285107684892271.post-47412090964979501032013-08-20T12:54:00.001-04:002013-08-20T14:10:49.091-04:00Why Measurements MatterI was re-reading Bill Gates' annual letter on behalf of the Bill and Melinda Gates Foundation the other day (<a href="http://www.billsletter.com/">www.billsletter.com</a>) and reflecting on the power and importance of measurement. Bill stresses this issue in the opening part of his letter and cites numerous examples of how careful measurement has helped numerous foreign aid and humanitarian programs to be evaluate their effectiveness and make adjustments which led to even greater successes. While he is speaking about large global development issues, his comments are just as applicable to the business world and I encourage everyone to read it. <br />
<br />
In it he refers to William Rosen's fantastic book, <em>The Most Powerful Idea in the World</em>, about the invention of the steam engine and in particular about the development of a new way to precisely measure energy output. The book makes a very strong case that this invention, which enabled people to evaluate quickly and effectively the impact of design modifications on performance, was the key to fostering the rapid innovation which created this enormous expansion in our quality of life. As Rosen wrote it enabled invention to become "commonplace". Rosen makes a strong case that without such tools, invention is "doomed to be rare and erratic".<br />
<br />
I believe the same is true for business operations, and not just on the product innovation side of things. Operational improvement is essential in every business, and having measurements that provide us with fast, effective feedback is critical to success. Businesses and markets are highly complex organisms so it is rare that anyone would succeed completely in the launch of any new initiative or improvement. We need a way to get fast and accurate feedback on the actions we take, or we are destined to flail around blindly trying new things and hoping they work. <br />
<br />
Organizations are launching new initiatives all of the time, whether it's re-structuring, or some program like Lean, Six Sigma, Balanced Scorecard, TOC, etc. Unfortunately most of these efforts go on for a while, deliver little real gain (at least less than expectations in almost all cases), and then fall by the wayside. Re-structuring is a good example. How many companies have go through re-organizations to make them flatter or more hierarchical, more centralized or less centralized, only to go in the opposite direction 5-10 years later when they are going through a down period? And how many times have you heard: "Oh we tried <u>(fill in the blank)</u> already, it won't work for us", even though some of the things worked and also worked in other companies. The next step of course is to abandon the initiative entirely--to throw the baby out with the bath water.<br />
<br />
Improvement efforts often take a long time, but, why? And do they really have to? Of course they will take a long time (and deliver much less than they could) if we don't have a fast, effective feedback mechanism like Rosen talks about in his book, because it will be trial and error, with little way even to evaluate our errors. But what is it like when we do have a fast feedback loop that quickly tells us the effectiveness of our actions, and points to where and how they are falling short. Monitoring how effective are our improvement actions in business provides us the input we need to make the small corrections, additions, and changes that will get us to the next level. It's not about luck, and its not about genius, it's straightforward test and re-test. You hit a golf ball on the driving range and it slices to the right. You get immediate feedback that your clubface was open at impact and you need to make an adjustment in your swing to close it. Imagine what it would be like if you couldn't see the flight of the ball to tell you how effective your swing was?<br />
<br />
For years I have included this as one of the five key principles of improvement that I share with my clients--take structured actions and design ways to get fast feedback on their effectiveness. "Structured actions" means implement changes consistently because if you do things a little bit different in different places/ situations, you won't know what really caused the results you got. It's not easy to design these fast feedback loops so that you can judge the effectiveness of your actions, and I think too often we skip this step in our excitement to improve things. But the price organizations pay when they skip this step will be high. The good results they do get will be slower and lower than if they were able to monitor progress over a short horizon and make the small corrections that are almost always needed.<br />
<br />
Thanks to Bill Gates and William Rosen for reminding us of just how important effective, fast measurements are to any process.Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com0tag:blogger.com,1999:blog-4738285107684892271.post-49552315841283765292013-08-16T17:23:00.001-04:002013-08-19T11:18:52.175-04:00The Strategy-Execution Gap, Part 1Lately I have been thinking about the challenge executives face in turning strategy into effective execution. Over the years I have read numerous reports on studies and surveys of executives who routinely list "failure to execute" as the leading cause of why the company underperformed. From my experience I am inclined to think this is true and happens a lot. And I've certainly seen companies succeed brilliantly with mediocre strategies that were effectively executed.<br />
<br />
While there are undoubtedly causes specific to a given company and why it failed to properly execute a strategy and reap the rewards, with anything that is widespread like this phenomenon, there must be some common causes at the root too. Whenever I look for such underlying causes I immediately start with basic principles of management that are of a more generic nature, things that are likely to be common in most organizations. <br />
<br />
One of the most common practices of management is to divide to conquer. In other words in order to manage a large and/or complex business we will break it into functions, departments, business units, regions, etc. in order to more effectively manage the many pieces. And then of course we have to have some measurements in order to evaluate and control what each function, level, department, etc. does. Measurements are one of the great tools of management because not only do they help tell us how we are doing, they also drive what gets done and how it gets done. I believe the old saying is true: "tell me how you measure me, and I will tell you how I will behave."<br />
<br />
While every company has global measures, like Net Profit and ROI, they tend to have many more measures that are used to evaluate and drive the performance of the individual parts of the business. Since individual departments can't fully control the global profit and ROI measures (e.g. manufacturing can produce great products but if sales can't sell them profitably, the company won't make money), these local measures are needed to evaluate the performance of the local area and will tend to be the more important measures for those managers and staff.<br />
<br />
The beauty of this breakdown is obvious as it enables managers to influence, control, and direct a far bigger operation than one could supervise directly. Unfortunately the very potency of such a powerful mechanism means that it can also do great damage to if not used carefully. And this is one of the main ways I think strategy can go off the rails when it comes to execution. If the local measures are not closely tied to the strategy, and designed in a way to produce the needed collaboration between departments, functions, etc. the organization can quickly find itself working at cross-purposes with itself. In my experience this mis-alignment happens often and undermines the organization's ability to reach its goals, though often in ways that are not obvious or readily recognized by management. <br />
<br />
Here are some examples of how some common local measures contribute to profits being lost: <br />
<ul>
<li>Manufacturing is often measured according to costs using some form of efficiency measure. This drives each department and plants in general to produce goods in large batches to maximize these measures. But large batches delay the production of other items and many companies find themselves with surpluses of some items and shortages of others--increasing working capital, and lowering sales. </li>
<li>In many companies purchasing is driven to buy items at the lowest cost using a measure like purchase-price variance. While everyone wants to buy their parts and supplies at a low cost this can lead to buying from less reliable or lower quality suppliers, or to purchasing in large batches (to get a lower unit cost), resulting in production problems or even late shipments, and elevated inventory levels or even write-offs, respectively. </li>
<li>In one of my former employers we measured manufacturing engineers on cost savings generated. So they used their powerful knowledge to come up with ways to run more parts through a given machine faster, often investing thousands in new tooling. Often though these were not bottlenecks and the neither produced more throughput, nor resulted in laying anyone off, they were just cost-savings on paper--but they sure looked good on their local measures. </li>
<li>Many consumer goods companies motivate their business units using quarterly sales targets. This creates the incentive to sell at discounts in order to achieve the goal, and the retailer to wait and stock up on goods when the end of the quarter sale rolls around, undermining full-price sales. </li>
<li>In software design and other types of project environments, it is common to measure people on how well they deliver on their individual work tasks within a project. This naturally causes people to provide lengthy estimates on their tasks in order to be reliable in the face of the inherent uncertainty of project work. And then, knowing that if they deliver ahead of time they will be forced to cut their estimates the next time, there is a disincentive to finish early--no wonder projects take so long!</li>
<li>Of course the same thing happens with budgets. Budgets are used almost universally in companies to try to control spending--certainly a good idea. However since how much money one needs for the year is an inherently uncertain thing, everyone will pad their estimates, inflating the budget, and then spend it because if they don't the will get less the next year. </li>
</ul>
There are many more examples one can bring, but I think the connection is clear--local objectives and their supporting measurements often result in actions that are counter-productive to the company's performance. If they are not carefully analyzed and aligned both to the strategy and to each department/function's role in supporting the strategy, can readily undermine the execution of any strategy, no matter how good it may be. I think this is a major contributor to why many companies fail to realize the promise of their strategies and underperform expectations. Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com0tag:blogger.com,1999:blog-4738285107684892271.post-39384991829584302452013-08-13T16:02:00.002-04:002013-08-20T14:13:50.097-04:00Want a Quick way to improve productivity: Stop Multi-tasking!<br />
<span style="font-family: Calibri;"><span style="font-family: Times New Roman;"><strong>
</strong></span></span><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-indent: 0.5in;">
<span style="font-family: Calibri;">Multi-tasking is so pervasive in
organizations, and modern life in general, that we often don’t even think about
how damaging it is to productivity. Even worse many people claim to be great multi-taskers
whose productivity doesn’t suffer from switching between tasks. Unfortunately
all the research now being done fully supports, what even a simple exercise in
multi-tasking shows—it’s not only damaging to individual productivity its
devastating to organizational productivity. This is particularly true when the
work being done is only one activity in a large process or project—as most work
in organizations is. </span></div>
<span style="font-family: Calibri;">
<span style="font-family: Times New Roman;"><strong>
</strong></span>
</span><div class="MsoNormal" style="margin: 0in 0in 10pt; text-indent: 0.5in;">
<span style="font-family: Calibri;">Let’s define multi-tasking as
stopping one task, before it is either complete or has reached a logical
stopping point to go and do something else. This seemingly benign behavior
creates two significant problems. First it drains the efficiency of the
individual, because every time a task is set aside to go do something else the
person must spend time “getting back up to speed” when s/he returns to the
task. For most of what I call “knowledge work” this time can be considerable,
and in many instances this re-starting is also the source of errors or bugs as
things are missed. If a resource has to re-start a task several times, the
amount of time spent repeatedly preparing to do the work, can easily exceed the
time spent doing the task. Additionally, because people are always busy, either
working on a task or getting back up to speed on one, it appears that there is
no spare capacity anywhere, no efficiency to be gained. And many organizations
find themselves having to add staff, even though in reality there is
substantial hidden capacity, on top of the frustration and quality problems
stemming from multi-tasking. </span></div>
<span style="font-family: Calibri;">
<span style="font-family: Times New Roman;"><strong>
</strong></span>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-indent: 0.5in;">
As if this wasn’t bad enough, the
larger, and less well understood, issue is what it does to organizational
efficiency. When people are forced to multi-task, that task gets interrupted
and set aside, unfinished. But the clock on the work doesn’t stop, it just
keeps ticking; so that customer’s project, application, product, claim, or
whatever is not moving, but it’s eating up time, waiting for the person to come
back to finish it and move it to the next step in the process. Each interruption
delays the completion of the task and extends the lead time. Since
multi-tasking is likely to happen at each step of a process these delays
multiply quickly. Lead times and backlogs can grow quickly this way and
jeopardize the performance of the company, eroding customer satisfaction. It’s
not easy to precisely quantify how much lead times are inflated, but it’s
typically far more than one would think.</div>
<span style="font-family: Times New Roman;">
</span>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-indent: 0.5in;">
I typically use a simple game to
illustrate just how much multi-tasking impacts organizational performance. If
you like you can do it on your own in just a minute. I ask people to perform
three tasks: write all the numbers 1-20 in the first column, all the letters
A-T in the second, and then to draw twenty shapes in the third in the sequence
circle-square-triangle. I then give people two options for how to accomplish
the work. They can either complete it by working one task at a time, start to
finish, (all the letters first then the numbers and finally the shapes), or
they can multi-task doing one number, one letter, one shape and then repeating,
as in 1, A, Circle, 2, B, square, etc. Not surprisingly everyone wants to work
the tasks start to finish. At the same time they all readily agree that the
second way, multi-tasking, is more like how they have to work in their
organization. To play the game do the activities each way, timing each run
separately. When you’re ready, turn the page to continue the discussion. </div>
<span style="font-family: Times New Roman;">
</span>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-indent: 0.5in;">
I always find it best to do the
game in a group because you are assured to get a range of results, and a
measure of statistical validity. Having done this with several thousand people
over the years, the average times to complete the three projects is typically:</div>
<span style="font-family: Times New Roman;">
</span>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 0pt;">
Multi-tasking:<span style="mso-tab-count: 2;"> </span>85
seconds</div>
<span style="font-family: Times New Roman;">
</span><div class="MsoNormal" style="line-height: normal; margin: 0in 0in 0pt;">
Without Multi-tasking:<span style="mso-tab-count: 1;"> </span>45 seconds</div>
<span style="font-family: Times New Roman;">
</span><br /><o:p> </o:p>
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
While it’s a simple game, it’s a very powerful illustration
of the impact of multi-tasking:</div>
<span style="font-family: Times New Roman;">
</span>
<div class="MsoListParagraphCxSpFirst" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo1; text-indent: -0.25in;">
<!--[if !supportLists]--><span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]-->If you multi-task, it takes twice as long to
complete the tasks</div>
<span style="font-family: Times New Roman;">
</span><div class="MsoListParagraphCxSpMiddle" style="margin: 0in 0in 0pt 0.5in; mso-list: l0 level1 lfo1; text-indent: -0.25in;">
<!--[if !supportLists]--><span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]-->If you don’t multi-task, you can do almost twice
as many projects in the same time </div>
<span style="font-family: Times New Roman;">
</span><div class="MsoListParagraphCxSpLast" style="margin: 0in 0in 10pt 0.5in; mso-list: l0 level1 lfo1; text-indent: -0.25in;">
<!--[if !supportLists]--><span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><!--[endif]-->Everyone agrees its easier and probably produces
better quality without multi-tasking—so you’re not getting more by “working
harder”</div>
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
In the multi-tasking iteration all three of the tasks finish
at virtually the same time, about 85 seconds. But when they work each task
start to finish, the projects don’t finish in a big wave, they finish one at a
time staggered about every 15 seconds (15-30-45 sec. for the three projects),
meaning that the first two projects finish dramatically earlier than with
multi-tasking. It’s not hard to extrapolate the results further if we imagine
that each of the three tasks was just one step in a larger process within an
organization. If we assume there were 10 sequential steps in the project, the
three projects would take 850 seconds to complete under multi-tasking mode, since
each step takes 85 seconds to complete the three projects. However, working
start to finish on each task the first task would be done and passed on after
just 15 seconds, the second after 30 and the last one after 45 seconds. Each
successive step, working the same way, would complete its stage in 15 seconds
and pass it on. So for a 10 step project the first project would finish after
just 150 seconds, with the second one at 165, and the third 15 seconds later
and 180 seconds. Compared to 850 seconds under multi-tasking, this translates
into a lead time reduction of more than 75%.</div>
<span style="font-family: Times New Roman;">
</span>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-indent: 0.5in;">
To be sure, reducing multi-tasking
is difficult, and eliminating it entirely is probably impossible. It requires a
shift in a number of common practices and some very common beliefs people have
about how to work and what it means to provide good service to customers and
colleagues. But what about the alternative? Continuing high levels of
multi-tasking reduces efficiency, produces lower output, extends customer lead
times, threatens quality, and makes everyone work harder for lower results.
Personally I don’t know many faster, more effective ways of improving
productivity, profits, and service than reducing multi-tasking. </div>
<span style="font-family: Times New Roman;">
</span>
<div class="MsoNormal" style="margin: 0in 0in 10pt; text-indent: 0.5in;">
Here’s a final thought to highlight
just how much multi-tasking is impacting your business and its productivity: Do
you or your colleagues ever come to work early, stay late, work from home, or
work on weekends? People tell me these are some of their most productive hours…when
they aren’t getting multi-tasked! <span style="mso-spacerun: yes;"> </span></div>
<span style="font-family: Times New Roman;"><strong>
</strong></span></span>Links to Press on Multi-tasking:<br />
<a href="http://www.linkedin.com/redirect?url=http%3A%2F%2Fblogs%2Ehbr%2Eorg%2Fschwartz%2F2012%2F03%2Fthe-magic-of-doing-one-thing-a%2Ehtml%23%2521&urlhash=EyCa&_t=tracking_disc" target="_blank">http://blogs.hbr.org/schwartz/2012/03/the-magic-of-doing-one-thing-a.html#%21</a>
<br /><a href="http://www.linkedin.com/redirect?url=http%3A%2F%2Fbusiness%2Etime%2Ecom%2F2013%2F04%2F17%2Fdont-multitask-your-brain-will-thank-you%2F&urlhash=ccrS&_t=tracking_disc" target="_blank">http://business.time.com/2013/04/17/dont-multitask-your-brain-will-thank-you/</a>
<br /><a href="http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Efoxnews%2Ecom%2Fhealth%2F2013%2F06%2F18%2F12-reasons-to-stop-multitasking-now%2F&urlhash=ocyw&_t=tracking_disc" target="_blank">http://www.foxnews.com/health/2013/06/18/12-reasons-to-stop-multitasking-now/</a>
<br /><a href="http://www.linkedin.com/redirect?url=http%3A%2F%2Fpsychology%2Eabout%2Ecom%2Fod%2Fcognitivepsychology%2Fa%2Fcosts-of-multitasking%2Ehtm&urlhash=OiL3&_t=tracking_disc" target="_blank">http://psychology.about.com/od/cognitivepsychology/a/costs-of-multitasking.htm</a>
<br />Also check NPR, they did a couple of interesting segments on the radio this year and several years ago.Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com0tag:blogger.com,1999:blog-4738285107684892271.post-91532770754216644272011-03-29T13:53:00.003-04:002011-03-29T18:03:28.197-04:00TOC's power of perspectiveOne of the most liberating and powerful aspects of TOC is that it provides one with a different, more effective perspective on organizations (particularly businesses). Most people who learn about the concepts and take them in deeply enough to re-think the way they view a business find that they can never go back to their old way of seeing things. It's like the old story of the emperor's new clothes. Once you have seen that the emperor is naked, you can no longer see anything else. People who absorb TOC even a little bit find that their perspective of virtually everything is colored by it. They see the constraints in any system--in the line at McDonald's, at the doctor's office, in their children's schools, and in their own companies. <br />
<br />
They just see things very differently than many of those around, and I would say more clearly. It's not that they are smarter than the next guy or gal, or have more experience than someone else, they simply have a very powerful set of lenses (TOC) that shapens their vision beyond that of others. I think I am personally a good illustration of this. I had the good fortune to meet and work with Eli Goldratt at a young age, and my father is Bob Fox, before I worked in the world and aquired the conventional way of looking at things which I characterize as the lens of complexity. In other words I had very little experience in looking at systems by breaking the complexity down into lots of smaller pieces in order to make sense of it. I was given the gift of being able to see them whole through TOC and the 5 steps. <br />
<br />
I could give lots of examples of how this perspective helped me to see and understand large highly complex businesses very quickly, and to see them more clearly than almost anyone within those companies, but I won't. (If you want to read one of them check out the post on this blog called "TOC Stories #2: Blue Light".) What is important is that TOC is a game-changer. It provides an enormously powerful lens for looking at systems, organizations of any type, that enables the user to identify extremely quickly what really matters within the entire thing and what to do to immediately to improve that system. <br />
<br />
It is not just an improvement methodology or a powerful set of techniques. It is a new perspective, it is the ability to see aqnd understand the world better and more clearly. Armed with an understanding of the 5 steps or the TOC thinking tools, any individual becomes capable of seeing through enormous amounts of noise, detail and confusion filtering out the trivial many from the very few truly important things in any system. This is an enormously empowering ability to possess. I have felt it personally and have seen it repeated hundreds of times in the companies I have worked with. <br />
<br />
Since most people suffer greatly due to an inability to understand and control the things that go on in their world, acquiring the perspective of TOC literally changes people's lives. With the ability to understand comes a significant peace of mind, even if other factors prevent one from immediately changing things. But TOC provides the perspective and the skills to change things as well, further increasing a person's enjoyment and satisfaction in life. <br />
<br />
We've long characterized our consulting work as "unleashing the potential of the organization" because we have always viewed what we do as an effort to provide our clients with the new perspective of TOC and enough coaching to use it to change their own organization. Once they acquire the perspective they are able to see for themselves much more clearly what to do and how to do it. The only reason they need the additional coaching and guidance we provide is because they carry a lot of baggage from the way they have always done things. In other words they have inertia and initially will readily slip back into the old perspective, take off the TOC glasses and look at things without those lenses. So it helps to have us stick around until the TOC becomes fixed and established broadly and deeply enough in the organization. <br />
<br />
For my money nothing else out their in the improvement universe holds a candle to TOC. TOC has given us the perspective and the skills to understand cause and effect in complex systems. A good analogy in my mind is that TOC is akin to the skills and abilities a doctor gets in his medical school and residency training, giving one the ability to select and utilize the specific tools around us, as a doctor uses scalpels, X-rays, and MRI's. <br />
<br />
The value of the perspective of TOC is hard for me to overstate. Over the last 25 years since I was first exposed to it, I have watched repeatedly as individuals and organizations have been transformed by it. The measurable gains that we all read about in terms of the performance of organizations are astounding, but what is less well publicized and less easily measured is the impact that it has had on people like me and our ability to understand, manage and improve our worlds. Everyone is aware of the power of a fresh perspective on things, TOC has created processes tools and techniques whereby anyone can acquire and consistently apply such a perspective. This is indeed a powerful thing.Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com1tag:blogger.com,1999:blog-4738285107684892271.post-14850902032030475302011-03-25T14:01:00.000-04:002011-03-25T14:01:07.994-04:00The Simplicity ParadoxI 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?"<br />
<br />
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. <br />
<br />
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.<br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com1tag:blogger.com,1999:blog-4738285107684892271.post-15198452095225784102011-03-23T15:49:00.000-04:002011-03-23T15:49:29.310-04:00We have to change?!! Oh no!I get asked all of the time why TOC isn't more widespread, why it isn't at least as big as movements like Lean and Six Sigma. There are lots of theories about this from many quarters and I certainly don't have the definitive answer. I do have a couple of observations I think are worth sharing. <br />
The TOC concepts are not complex or difficult to understand. In fact by comparison, Lean and Six Sigma are far more complex and demand much technical knowledge of statistics, variation and the like. What makes the change to TOC more difficult is not learning the concepts, but it's coming to grips with all the ramifications those concepts have for how we run our organization. <br />
<br />
TOC suggests a complete "re-modeling" of the organization, it's measures, the roles each function play, how levels work together, what information is important, etc. I don't think any of this will be news to most followers of TOC. I like the analogy of re-modeling the organization though, I think it offers an insight into one of the reasons TOC is not as widespread as it could or should be by now. <br />
<br />
Think about what you would do if you were going to remodel something, say your house. What would be some of the steps you would take? Certainly you would sketch out some plans of what you want the house to look like when you are done. If it was a large enough remodel you would have a builder or an architect create detailed plans of the new layout. You would make sure that these plans then got in the hands of the builders so that they purchased the right materials, dug holes in the proper places, erected the correct structures, and executed everything you wanted properly. Without the picture (the drawing, blueprint, design) and the specifications it's hard to imagine the remodel turning out the way we want it to. <br />
<br />
I don't think it's any different with remodeling an organization using TOC. Yet when I look at the ways TOC has traditionally been brought into organizations, I don't see many examples of blueprints for how the organization should look AFTER TOC has been rolled out. For the most part what we have given organizations is the generic process (the 5 steps) and a number of applications (DBR, Critical Chain, Throughput Accounting, etc.) to functional needs. To use the analogy of remodeling a house, these are akin to the generic process of building a house (first you dig the foundation, then you pour it, then you frame the structure, etc.) and the technical skills needed to do the various components of the remodel (the wiring, plumbing, drywall, etc.). While each of these is necessary to being successful, we still need to apply them to each organization's unique situation, and individual objectives. In other words we need the blueprint laying out how TOC is going to be applied in each specific organization. <br />
<br />
Without a specific design for a given organization, we have no way of telling the builders (the managers and staff of the organization) what they should be doing, how they should be applying the skills and knowledge they have. Imagine hiring the best builder in the world, with the best process, skills and resources and then asking him to build you a great house without any plan, design or model. It's not likely the house would be well suited to your specific needs or desires. <br />
<br />
I believe we have done much the same in TOC. We have great processes, and generic applications like DBR and Critical Chain, but for the most part we have not provided organizations with the picture of how to apply these capabilities in their environment. We haven't given them a very clear picture of what their organization looks like on TOC. And without a clear and visible destination it's hard to keep people focused, to keep them aligned and to keep them on-task. I believe this inability to see what my organization looks like on TOC is a part of the problem with TOC becoming more widespread. <br />
<br />
This is not to say that there aren't some out there who have recognized and are addressing this shortcoming. Eli's Strategy and Tactic teams provide some of the missing specifications. Realization, the providers of Concerto for critical chain, typically does a first-class job of mapping out how each client's organization will look, including definitions of the roles and responsibilities, before launching into the change process. My organization, Viable Vision, utilizes a simple visual blueprint we call the Throughput Operating Strategy in every TOC implementation we are involved in. In simple terms its a picture of the organization's workflow, and how they want to apply the 5 steps to managing their business. It documents the metrics, roles and focus of each department and level of the organization as we want them to function.I can't imagine embarking on a change the magnitude of TOC without having this blueprint of how the organization should look when it is working in the new way. <br />
<br />
Change is hard enough, especially when it requires us to challenge so many fundamental assumptions and long-held beliefs as TOC does. I think we (the TOC community) have made it even more challenging by not giving people a clear picture of the target, the destination, the end state. What do you think?Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com0tag:blogger.com,1999:blog-4738285107684892271.post-58545166410952570812011-03-16T13:58:00.002-04:002011-03-16T14:03:37.917-04:00TOC in a word: FocusMany 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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
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. <br />
<br />
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!)<br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
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.Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com2tag:blogger.com,1999:blog-4738285107684892271.post-14704937862469790072007-11-29T11:23:00.000-05:002007-11-29T11:25:14.414-05:00Project Lessons: Focus on Completing Projects On-time, Not Completing Tasks On-timeIt 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.<br /><br />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?<br /><br />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.<br /><br />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?<br /><br />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.<br /><br />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.<br /><br />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?<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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 <a href="mailto:info@tocc.com">info@tocc.com</a>.Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com3tag:blogger.com,1999:blog-4738285107684892271.post-87996953483673803482007-11-27T18:06:00.000-05:002007-11-27T18:08:05.976-05:00Breaking out of the Project Scheduling TrapProject scheduling is a difficult art as anyone who has practiced it understands. At the same time it is one of the most common reasons cited among the causes of project failures. There is great debate over the best methods for making good plans and especially over the level of detail that should be specified in any given project plan.<br /><br />In most cases project planning is a time consuming activity. Even the most experienced project managers and planners find themselves having to re-plan projects as a result of unexpected events during execution, sometimes more than once. Great efforts are expended with, based on the public research, very little effect on making projects go smoothly and finish on-time, on-scope and on-budget.<br /><br />But there is much more effective way for organizations to plan their projects, a way that takes less time and delivers far better results with very little re-scheduling. To reach this much better way requires answering two critical questions:<br /><br />How do we plan for the inevitable uncertainty in projects?<br />To what level of detail should projects plan go?<br /><br />Planning for uncertainty is one of the greatest challenges any project manager or executive faces. On projects uncertainty is the way of life: the specifications can change, the required needed can change, the work content can change, resources may be occupied elsewhere when needed, work can be delayed, tasks can take longer than expected, approvals can be held up, along with a host of other variables that can throw the best conceived plan into chaos.<br /><br />It would be easy to plan for uncertainty if time didn’t matter. Adding lots of safety buffers would enable us to provide for any eventuality. Unfortunately, in most environments, time does matter, and it usually matters a great deal. So the challenge is how to provide for uncertainty, and still plan projects to complete as fast as possible?<br /><br />The common approach of planning projects is to insert safety time into each task in the plan. If task managers are asked to estimate durations, they will typically estimate them with some degree of safety factored in. This is especially true if the organization holds them accountable to hitting their task estimates. It also makes good sense, since we cannot have a reliable project plan if every estimate is the minimum possible time to do a task. Even organizations who feel as if their task estimates are super-aggressive will find if they check that there is still considerable safety time embedded in task estimates.<br /><br />Often additional safety gets added at management levels as they pass their estimates upward. Again the same motivation is at work, the need to provide realistic estimates that they can meet. There is also the awareness that often times people’s estimates will be cut anyway, so adding safety time is essential to insure that you will end up with task times that still account for uncertainty.<br /><br />There are several problems with inserting safety time into tasks. The first is that it is hard to see how much of it has been used at any given point in time during execution. The second is that the safety time, once put into the task, typically gets wasted in two possible ways. The first is something we all know from school—the student syndrome. When the test is still far off there is little urgency to start to study. In projects this means that there is little urgency to start a task when it becomes available, because “we still have plenty of time.” The second way safety is wasted is through Parkinson’s Law—the work expands to fill the time available. People will continue to “polish” their work right up to the day it is due. And in most organizations there is also a strong dis-incentive to finish a task earlier than planned, because the next time management will expect the same “faster” time.<br /><br />So while we definitely need to plan for safety time to cope with the uncertainty of projects, embedding this time in the tasks themselves almost insures that it will be lost. The better strategy by far is to remove the safety time from the tasks (we start by cutting all current task durations by 50%) and to place it in a buffer at the end of the project. By placing the safety time at the end of the project (after the last task) several benefits result:<br /><br />The safety time is available to anyone on the project who might need it (since it’s not embedded in a task and is at the end any delay can consume the buffer).<br />The safety time is visible and we can tell at any given point how much of it has been consumed and how much is still available to protect against delays.<br />The safety time can be used to manage priorities within, and across projects (tasks whose buffers have been more fully consumed take a priority over ones whose buffers are larger as a percentage).<br />We neutralize the Student Syndrome and Parkinson’s Law by increasing the sense of urgency to start and reducing the time available at the end of a task to be absorbed by the work.<br />We actually need less safety time in total so we can trim some of it and reduce our overall project durations. (The chance that something will go wrong on any given task in the project is very high, but the chance that something will go wrong on every task is very low. So by aggregating the safety time at the end of the project, we actually do not need all of it and can reduce it—again we typically cut it by 50%)<br /><br />While this answers the first question of how to plan for uncertainty, it does not address at all the second question around the proper level of detail for the project plan. In an effort to get a better handle on uncertainty, and to promote better project discipline, most project plans contain a high level of detail, at least much higher than we recommend. Another reason for putting a high level of detail into the project plans is to detail the work that needs to be done so that tasks do not get missed and will ultimately match up to the required specifications.<br /><br />By putting each detailed step of the work as a task managers are almost guaranteeing that they will need to re-plan at some point during the project, if not many times. The main culprit again is uncertainty. When we try to detail every little step and there is a change (in the specifications, the features, the research, a failed test that needs to me repeated, etc.) the plan as it was originally conceived becomes invalid. We know that this uncertainty will hit us, but know one, even the best project managers, knows when or how it will hit.<br /><br />There are two elements of the solution. The first is to greatly reduce the level of detail in the project plans. By specifying tasks at a much higher level we greatly dampen the likelihood that the plan will need to be re-written. In any event the buffer at the end of the plan exists to compensate for the uncertainty, so it is not at all essential that we actually hit any given task estimate. If a tasks turns out to be more work than expected, than it will consume the buffer, no re-planning is needed. From our experience the number of tasks in most plans should be cut by an order of magnitude, sometimes two. The US Navy now plans ship maintenance projects with fewer than 300 tasks, where they used to have 30,000—and they deliver on-time and on-budget where they rarely did before.<br /><br />The second element is to use checklists within the tasks to account for the details of the task. This enables managers to insure that there is clear communication as to the specific elements of the work (and to see each element checked off the list) and enables them to modify the checklists as needed without having to do any re-planning or re-pipelining of the schedules. In this way the original plan can be created much faster (there are far fewer tasks to detail, and vastly fewer relationships or estimates to get) and will require little if any re-planning.<br /><br />To summarize, if you want to get out of the project scheduling trap, try these three steps:<br /><br />Take the safety time out the tasks and put it into a buffer at the end of the project, preferably cutting that buffer as well.<br />Plan tasks at a high level (never less than a day, and typically not less than a week for most tasks)<br />Use task checklists to manage and modify the details of the work within each task.<br /><br />For more info send a request to <a href="mailto:info@tocc.com">info@tocc.com</a>. Be sure to include the details of your question or request.Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com1tag:blogger.com,1999:blog-4738285107684892271.post-70388870675251667212007-11-08T13:36:00.000-05:002007-11-08T13:44:27.044-05:00New SeriesWriting 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.<br /><br />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."<br /><br />I hope you enjoy it.<br /><br />KevinKevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com3tag:blogger.com,1999:blog-4738285107684892271.post-51843768126858820462007-08-14T17:34:00.001-04:002007-08-14T17:39:16.784-04:00More Projects Faster: Critical Chain Project ManagementThanks for all the great responses to past. Given the apparent interest in Project management issues from my last article on the subject, and the numerous requests for the follow on article, I have decided to post it here. It's a bit long for a blog, so if you want a pdf to print out, ask for it.(For those of you who have requested the article directly through <a href="mailto:info@tocc.com">info@tocc.com</a>, it has been sent in pdf to you already.) I hope we keep the exchange going.<br /><br />Kevin<br /><br /><strong>More Projects, Faster, with Fewer Resources: Critical Chain Project Management</strong><br /><br /><em><span style="color:#ff0000;">“It’s not important to complete tasks on-time, it is essential to complete projects on-time.”</span></em><br /><br /> No matter where you look in today’s competitive world, the pressure to complete more projects, faster at lower cost is pervasive. Speeding construction projects brings new plants and stores, with their substantial revenue streams, on-line earlier, improving investment returns. Accelerating new product development and launch expands market share, increases sales and for many companies can be the difference between being the market leader and being an also-ran. In information technology, bringing new systems on-line faster means enhanced capabilities for customer service, inventory management, and a host of other mission-critical management activities. For most companies involved in strategic projects, delivering more projects faster is not just important, it is imperative. <br /><br /> While there is a wide range of different project types companies undertake, there is a surprisingly consistent set of issues, or complaints across this spectrum. In most project environments, the list typically includes all or most of the following concerns:<br /><br />· The original dues dates are not usually met<br />· There are too many changes<br />· Too often resources are not available where and when needed (even if promised)<br />· Necessary things are not available on-time (information, specifications, materials, designs, approvals)<br />· There are fights over priorities<br />· There are budget overruns<br />· There is too much re-work<br /><br />The simple fact that this list is so common and pervasive, strongly suggests that the common problem is much more related to how companies manage projects than to any technical or specific factor. The existence of a common core problem also provides companies with an exciting opportunity to make significant strides in delivering more projects faster with fewer resources.<br /><br />Critical Chain highlights that there are three main factors in how companies manage projects which lead almost inevitably to the concerns listed above. These core drivers are:<br /><br />1. Bad Multi tasking<br />2. Student syndrome<br />3. Parkinson’s Law<br /><br />Bad multi-tasking is the process of stopping a task before it is finished in order to do something else that is either immediately urgent, or otherwise important. Each time a task is stopped there is an immediate efficiency loss due to the time needed to “get back into” the task when it is resumed. In knowledge work especially, it is not insignificant to have to re-orient oneself to the work each time it is re-started. Worse still are the delays these stops and starts cause to downstream tasks. Each time other work is inserted into a task, its elapsed duration grows. Because there are dependencies between tasks in projects these delays immediately start to delay the downstream tasks, and quickly impact the overall project timeline.<br /><br />Given that most companies readily admit that this multi-tasking occurs frequently, and that people generally have many open tasks on their desks at any given time, it is not hard to see how the prevalence of this practice quickly results in the “Cascade Effect.” In other words delays move like dominoes through the project, extending overall durations and delaying project completions. (For a more complete explanation of this effect request TOCC’s “Bad Multi-tasking” article from <a href="mailto:info@tocc.com">info@tocc.com</a>)<br /><br />The second and third factors above are directly linked to how companies manage safety time in projects. Uncertainty is the reality of projects. While some actions may be taken to reduce some of the uncertainty, eliminating uncertainty and variability is simply not possible. Projects are like driving in a large metropolitan area, no matter what you do there is always the chance of encountering delays (rush-hour traffic, an accident, construction). No one can say for sure how long it will take to go from one place to another. One can only adjust the safety time allowed to insure arriving on time.<br /><br />In projects companies often behave as if they can eliminate the inherent variability of the work involved. They do this by trying to improve the quality of their estimated task durations. The aim is to arrive at task estimates that can be met, while at the same time not being too long to meet the required timelines, and then holding people accountable to hitting those estimates. The logical reaction of people, in the effort to provide what is required, is to give estimates that they are confident can be met. This means that people must estimate task durations with enough safety to account for the significant number of things “that could go wrong” along the way.<br /><br />While this makes perfect sense and is done with the best intentions at heart, the impact on projects is devastating. As soon as safety is built directly into task estimates, the student syndrome is triggered. In school students will argue for additional time before a test or an assignment is due. And then, when it appears they have plenty of time, there will be no urgency to start, often beginning work very close to the deadline. The same is true in projects. When people are busy, and their estimates provide the belief that there is ample time to complete the task, there will not be any real urgency to start when the task becomes available. As a result a good measure of the safety time built into the tasks is wasted at the front end of each task. The student syndrome accounts for a significant measure of the delays and long durations of projects. It is safety time that is really not used to complete the work, in spite of people’s best intentions. And all too often while this safety time was lost at the front end, it turns out to be needed at the back to overcome some unforeseen obstacles, resulting in tasks finishing late in spite of the safety.<br /><br />At the back of each task is another mechanism, Parkinson’s Law, which helps to insure that even though safety time has been added to the estimates, that tasks will not finish (much) ahead of the planned time, even if no obstacles are met. The reality here is two-fold. First, if people do find they have extra time to finish a task they often use that time to “perfect” or “polish” their work, wanting to do the best job possible. So the work expands to fill the time available. The second issue is that there is a dis-incentive for people to finish early. Finishing much ahead of the planned completion date for a task sends the signal to management that the estimate was “fat” and that in reality it can be done much faster. The next time these estimates will be cut further in an effort to reduce overall project durations. Knowing that in the future this safety time may well be needed to account for unforeseen problems, people will not be quick to report early finishes of their tasks.<br /><br />The result of these factors is that most companies will observe that their tasks generally come in very close to the estimated times, with a number of tasks completing later than planned. It can be easy to conclude that the company does an excellent job of estimating its task durations, and that there is thus not much opportunity to improve through better synchronization, but this is far from the reality. The simple nature of projects and project tasks is that there is variability. Doing a similar task may take 10 days one time, and due to certain obstacles or challenges, take 15 days the next time. This is the reality of trying to predict durations, just like predicting how long it takes to drive into a busy city on any given day. It will take different times each time it is done.<br /><br />This means that if the company’s task estimates appear to be very reliable (i.e. they are met most of the time) that in fact there must be considerable safety that is being lost in the process. And as a result there is considerable opportunity to reduce durations, and increase project output, without adding resources.<br /><br />Critical Chain addresses the core drivers of projects through three mechanisms. In order to curtail the bad multi-tasking effect there is the need to reduce the amount of available work in the pipeline. The mere presence of many jobs on each desk creates sufficient opportunity for resources to multi-task and misprioritize work, that it simply cannot be managed. Project managers, motivated to complete their projects on-time will persuade and cajole resources to shift priorities, customers and executives will exert their own pressures to re-focus resources, and the simple desire of people to choose between various tasks will insure that the bad multi-tasking will take place.<br /><br />Initially Critical Chain drives the reduction in active work-in-process by freezing a significant percentage of the projects in the pipeline. By reducing the opportunities to multi-task, people can stay focused on and complete tasks much faster, enabling them to move more quickly from step to step, encountering much smaller queues of work. Freezing at least 25% of the projects typically is sufficient to accelerate the flow of work and thus the completion of projects. As projects finish the frozen projects can be released and also move much more quickly through to completion. This mechanism alone typically results in improving on-time project completion considerably, without making any projects (even the frozen ones) later than they would have been otherwise.<br /><br />After the initial freezing process, to get to a steady-state of operation, it is essential to insure that work is released in a metered fashion so that WIP stays relatively low and bad multi-tasking is reduced. Theory of Constraints points out that any system, or project pipeline, can only do as many projects as it can get through the weakest link (the constraint) in its chain. Releasing more work than the constraint can complete in any period will only result in work piling up in front of the constraint, not in completing more projects. Critical Chain thus highlights that work should be released according to the capacity of the weakest link (most heavily loaded resource) in the system. Projects can then be pipelined and due dates committed to according to when there is an available slot on the constraint.<br /><br />The second essential element of Critical Chain deals with how to plan for safety time in projects, so that the added time will not be wasted, and so that project plans will be as short as possible while still sufficient to give reliable delivery dates. This is accomplished by first identifying the longest chain of dependent tasks and resources for the project. This is very similar to what is widely known as the “critical path” but also allowing for any resource contentions (points where the same resource is required on two parallel tasks) that exist along the way. The resulting “resource-leveled critical path” or critical chain is what will determine the overall duration of the project.<br /><br />For all the tasks on the critical chain the task estimates are cut, typically to 50% of their current duration, and the cut time is placed at the end of the project as a buffer. By removing a significant measure of the time from the estimates and placing it at the end, this safety time is now both much more visible for management purposes, and is available to every task on the critical chain who might encounter a real delay. However once this time is extracted and aggregated at the end it is possible to reduce it considerably, and with it the overall project duration. When the safety time is available to all, and tasks times are much shorter (therefore less likely to induce the student syndrome), and there are far fewer delays stemming from multi-tasking, the total safety time needed is by far less. The chance of encountering a delay on any given task is very high, but the chance of encountering a delay on ALL the tasks is very, very low. Critical Chain advocates cutting the safety time in the buffer in half, and experience has proven that in nearly every organization, there is still ample safety time remaining to complete the projects on time.<br /><br />The last core step of Critical Chain is execution management using the buffers to guide decision making. If delays are encountered on the critical chain, some of the buffer time at the end of the project will be consumed. By observing the ratio between the percent of work completed on the critical chain and the percent of the safety consumed managers can see for any project the risk profile. When a project’s buffer is being consumed at a faster rate than the work on the critical chain, the buffer is red, or at risk. When both the buffer and the critical chain are moving at the same rate, it is yellow or “okay.” When the work is being done at a rate faster than the buffer is being consumed then the project is ahead, or “green.” At a glance executives can see which of its projects are at risk and which are on track and decide where and when to intervene.<br /><br />For project managers, whose responsibility is to deliver the projects on-time, it is essential that they know immediately what task is responsible for a buffer being consumed faster than the work is being completed. They need to be able to see which task is holding the work in these cases so that they can undertake the proper actions to bring projects back to the green zone. By monitoring the buffer trends over time (getting more green, or getting more red) they can readily see and manage the corrective actions they are taking to insure their effectiveness.<br /><br />For functional managers responsible for deploying people and other resources on project tasks, the central issue is setting priorities and matching people and equipment properly to tasks. Given that each task feeds into the project buffer, it is possible to tell if the task is feeding a buffer that is okay, or green, or in trouble, red. Project tasks that are red are given higher priority than those that are green, which can wait because there is still safety time available. Functional managers can thus deploy their resources according to the status of all the projects, and eliminate the fights over priorities that are a constant occurrence today in most organizations. By looking ahead to see the upcoming tasks for their department, and the status of each, managers can properly plan and assign resources to tasks based on the work involved and the relative urgency of that work.<br /><br />Finally, Critical Chain provides the execution model for the task resources themselves, the people who do the work on the projects. The visibility of the buffer status for each task enables people to see clearly which of their tasks are the most urgent and make the right decisions about priorities without needing management instruction. They also can tell whether it is important to seek help when there is a delay. Red tasks clearly mandate getting help when there is an obstacle, whereas green tasks can suffer a delay without jeopardizing the project.<br /><br />Of course it is essential to report certain data on projects to insure that the needed information is up to date and accurate. In many approaches progress is measured either as a percentage of the work complete, or the amount of time put in (often referred to as Earned Value). Unfortunately these reports of the amount of effort put in, do not indicate very clearly how much more time is required until the task is complete, which is ultimately what is needed. Many managers have experienced this in reality when it seems to take as long to complete the last 10% of a task as it did to do the first 90%. To counteract this, Critical Chain has Task Managers report the time remaining to complete a task. In most cases this is a far easier figure to give than the percent complete or the hours put in. And by reporting the time remaining it is easy to add up the remaining time on the critical chain and compare it to the amount of buffer consumed. (There are several software packages available in the market which automatically provide the information and reports described above, greatly facilitating the application of Critical Chain in organizations. More information is available by request at <a href="mailto:info@tocc.com">info@tocc.com</a>)<br /><br /> The result of the application of these three central steps (project staggering according to the pipeline’s constraints, critical chain project planning with buffers, and buffer driven execution management) is a significant acceleration in project flow. Companies who have applied these steps have routinely seen on-time completions move to above 95%, while project durations have been cut 25-50% of there previous lengths. They have achieved these results through synchronizing the flow of work across their resources, and without adding more people or cost to their systems. The reduction in project durations translates directly into completing more projects in the same period of time, greatly improving the return on investment in projects and accelerating revenues.<br /><br /> While the changes suggested by Critical Chain are not difficult to understand in concept, putting them into practice in an organization carries with it some notable challenges. The greatest of these is the courage required to change the long-standing practices, procedures, and measures used to manage projects at all levels. Moving from the mode of pushing projects into the pipeline as early as possible to releasing them according to the constraints means changing the widely held belief that the earlier you start a project, the earlier it will finish. Without the cooperation of sales and upper management in the metering of projects, the pressure to launch more and more projects will overwhelm the pipeline and insure the return of bad multi-tasking.<br /><br />Putting visible buffers into projects requires executive support based on an understanding of the fundamental principles, or it will result in these buffers being eliminated and unrealistic plans being launched. Managing projects and priorities according to buffers means that managers and task resources must surrender their reliance on managing individual task times as their main means of control. The magnitude of these changes is not insignificant as each requires overcoming the inertia of long-time practices and beliefs, any one of which can quickly undermine the process.<br /><br /> There are proven processes and techniques for navigating each of these fundamental shifts, but that is the subject for a future article on implementing Critical Chain in organizations. If you are interested in receiving this article, please send a request for “Critical Chain Implementation” to <a href="mailto:info@tocc.com">info@tocc.com</a>, for examples of results visit <a href="http://www.tocc.com/TOC%20results.htm">www.tocc.com/TOC%20results.htm</a>.Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com1tag:blogger.com,1999:blog-4738285107684892271.post-28503555614259996832007-07-30T15:28:00.000-04:002007-07-30T16:03:36.538-04:00Product Octane: the overlooked lever in TOCIt 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.<br /><br />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:<br /> <br /> Product P Product Q<br />Selling Price $90 $100<br />Raw Material $45 $40<br />Throughput $45 $60<br />Time at Constraint 15min 30min<br />T/ constraint time $3/min $2/min<br /><br />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.<br /><br />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.<br /><br />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 <strong>10 times </strong>the Throughput of the lower octane products.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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...Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com0tag:blogger.com,1999:blog-4738285107684892271.post-86828476064039537242007-07-27T16:37:00.000-04:002007-08-06T16:32:52.637-04:00<div><br /><div><br /><div><br /><div><br /><div><strong>Multi-Tasking: Why projects take so long and still go late</strong><br /><br />In most project environments multi-tasking is a way of life. This seemingly harmless activity, often celebrated as a desirable skill, is one of the biggest culprits in late projects, long project durations, and low project output. At the same time it is one of the least understood factors in managing projects.<br /><br />For companies where projects are of strategic importance, the stakes are very high. Whether it is delivering their product or service, bringing new products to market, or expanding/ upgrading their operations with new facilities, systems, or capabilities, the financial impact of being able to reduce project durations and costs, increase the volume of completed projects, or simply deliver more projects on-time is enormous. So understanding how this often overlooked practice of multi-tasking is of critical importance to most companies.<br /><br />Multi-tasking and project performance<br /><br />Multi-tasking is the act of stopping a task before it is completed and shifting to something else; in software development the term “thrashing” is often used to describe this practice. When a task is stopped and started there is the immediate effect of a loss of efficiency. Each time a person has to re-start a task, time is required to become re-familiarized with the work and get re-set in where he was in the process. It is very much like the physical set-ups done on a machine in production. Each time you tear down a machine to do another task, you have to set it up to run the part again.<br /><br />While the loss in efficiency is not insignificant, especially in “knowledge work,” it is far from the most important reason multi-tasking is so damaging. What happens when a task is interrupted mid-stream is that its completion is delayed. Most people in project management will readily agree that it is not important when a task finishes, it is important when the project finishes. The diagram below shows three tasks a given resource must do, related to three different projects, and when they are expected to finish: Task A after 10 days, B after 20, and C after 30. </div><br /><br /><br /><br /><br /><div><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6aY-3nzl5bch-mNQri85BVaTr45fiqMPFWl_hzDaf_1l3paM97SQCZEhmBX6vBe2J15wRvSNSsNLaHeiPamSdYhr8BmE4OaRe5adcRIKcM9CaMJ_Z6sEeDShmCpD1dK4WYntpIcI5d8Y/s1600-h/MT+Diag+1.JPG"><img id="BLOGGER_PHOTO_ID_5091984822095931890" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; CURSOR: hand" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6aY-3nzl5bch-mNQri85BVaTr45fiqMPFWl_hzDaf_1l3paM97SQCZEhmBX6vBe2J15wRvSNSsNLaHeiPamSdYhr8BmE4OaRe5adcRIKcM9CaMJ_Z6sEeDShmCpD1dK4WYntpIcI5d8Y/s200/MT+Diag+1.JPG" border="0" /></a><br />But if the resource has to stop and start the task even just once in the process, the actual completion times of the tasks quickly extends, as shown below. Task A now finishes only after 20 days instead of 10, task B at 25 days rather than at 20 days, and task C may still finish on-time at 30 days, without considering the impact of the loss in efficiency. </div><br /><br /><br /><br /><div><br /><img id="BLOGGER_PHOTO_ID_5091984336764627426" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; CURSOR: hand" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjq8PbNOFguDeHgyB5q2S_YGDkIgo3mmNPTm7iLowvI5JZWQrVSWY4XTItE5Mhb_1Q3nVsbik9r4OjeQNPwYUSoaXXtqRDa9U8Y5RMkOdh3xIbBfnFmBLlbZ7rouOEmHcVh8lju05BLY68/s200/MT+Diag+2.JPG" border="0" /><br />The delays on tasks A and B immediately translates into are delays on the downstream tasks in those projects, who now can only start at Day 20 and 25 respectively. The impact on project A is illustrated below. Even in a very small project like this one with just four tasks, and with only one instance of multi-tasking, the project is delivered almost 30% late. It’s not hard to see how the more likely scenario of having several or many instances of multi-tasking during a project can cause the delays to accumulate considerably and lengthen project durations considerably.<br /><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxPHgPP75xwPdUOXFmH82nTWDIzZCsho2Wqi5AlkdTOFUyqYsyhVQdLXlsHbHJ_sk4IP-JTnWrSraix3yj-CUlS4u6YHlISPYMMC4vGePIcR2l2wBxa-lhhGcjYqT-m0jTtiduCShTnAs/s1600-h/MT+Diag+3.JPG"><img id="BLOGGER_PHOTO_ID_5091986303859649058" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; CURSOR: hand" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxPHgPP75xwPdUOXFmH82nTWDIzZCsho2Wqi5AlkdTOFUyqYsyhVQdLXlsHbHJ_sk4IP-JTnWrSraix3yj-CUlS4u6YHlISPYMMC4vGePIcR2l2wBxa-lhhGcjYqT-m0jTtiduCShTnAs/s320/MT+Diag+3.JPG" border="0" /></a>In many companies the impact of multi-tasking is obscured by the fact that in spite of its prevalence most projects still finish on time. While this reliability is nice, it masks the even more significant opportunity to cut project durations substantially. If projects are being delivered on or close to schedule, and multi-tasking is occurring, it can only mean that the task estimates used in the plan are significantly inflated. In other words, we are planning for the lost time due to multi-tasking, as this is the only way that the time losses could be recovered. In such cases, reducing the multi-tasking offers enormous potential to cut planned project durations substantially, without eroding delivery performance. These companies are in a great position to reap the benefits of delivering more projects faster.<br /><br />For years we have put the project managers, executives, and teams through a simple project simulation game using beads, first with multi-tasking, and then a second time, blocking it. The results are nearly always that the time to complete each of the two projects is cut in half, enabling them to double the output, and cut individual durations in half, simply by eliminating multi-tasking. And the same happens when companies drive out the multi-tasking in their own projects.<br /><br />Is Multi-tasking really so prevalent?<br /><br />Given the substantial negative impact on durations and project volume, it makes sense to explore just how common multi-tasking is. Since multi-tasking is difficult to see or measure precisely, we need to look at some other things to answer this question. The first issue is to understand the opportunity to multi-task. The way to see if your organization has the “opportunity” to do bad multi-tasking is ask how many jobs/ tasks an individual has on their desk at any given point in time. If there is more than one task that could be worked on a person’s desk then there is the opportunity for multi-tasking. When we ask managers how many tasks are on any given persons desk at one time, the not surprising answer is usually more than five.<br /><br />The next way to check is to ask people how often they get interrupted or asked to work on something else that is “hot”, “urgent”, or “important”. In most companies one need not even ask this as “constantly shifting priorities” is usually one of people’s biggest complaints in projects. Every meeting that shifts or alters the priorities of projects, or adds new important things for someone to do, is a source of multi-tasking. How often does it happen in your organization?<br /><br />Another way to look at it is to recognize that in most organizations where multiple projects are being done simultaneously, the resources who do the work on a project have to serve multiple, different project managers. For these project managers what is most important tends to be their projects. As a result they typically create pressure on resources to do their work first, institutionalizing multi-tasking. And when the multi-tasking starts to creep in, it initiates a negative spiral that only increases the pressure to multi-task. If one resource starts the multi-tasking, it delays the completion of their tasks, putting some projects behind. This increases the pressure on project managers and executives to adjust priorities to compensate, which in turn creates more, bad multi-tasking. It’s not hard to see how this spiral quickly becomes the reality we see in many organizations where managers at all levels are quickly pulled into managing work priorities across the organization on a daily basis.<br /><br />On top of it, many resources who work on projects also support daily operational functions like QA/ QC, production, engineering, customer service. This support role means that they are frequently presented with unexpected, usually urgent things to do which readily drive more multi-tasking. The result is that in the majority of companies there is the opportunity and the pressure to create a significant amount of bad multi-tasking.<br /><br />If it’s so bad, why do we do it?<br /><br />Our experience with hundreds of companies is that there are three central reasons organizations find themselves in the trap of multi-tasking:<br />1. Lack of understanding of the impact of multi-tasking<br />2. Incorrect assumptions<br />3. The desire to do a good job<br /><br />The simple fact is that most people and organizations do not understand how damaging multi-tasking is. Our clients who see the impact illustrated in the bead exercise, mentioned earlier, are stunned and amazed that eliminating the practice results in a doubling of output and a halving of the project durations, with no other improvements. Once people do start to understand how damaging the practice is they become much more conscious of it, and start to change their behavior and the behavior of their organization.<br /><br />But understanding is not enough. The drivers of multi-tasking are built into the processes, measurements, and systems most companies manage their projects. We strive hard to keep people busy all of the time, to maximize the output of all of our resources and be efficient. Performance measures on project managers and executives motivate them to focus on delivering individual projects, without understanding of the impact of their actions on the rest of the pipeline. Conventional scheduling and pipelining tools pay no attention to these factors and routinely overload resources making multi-tasking nearly inevitable.<br /><br />The second reason is ‘incorrect assumptions.’ Chief among these is the belief that “the earlier you start a project, the earlier it will finish.” While this is probably a valid statement in a single project environment where resources do not need to work on multiple projects, starting new projects earlier only increases the work in process in a multi-project environment and with it the likelihood of multi-tasking. People will get out of a building during a fire alarm much faster if they don’t all rush at the door at once. Though it seems counter-intuitive, projects will finish earlier and we will get more of them done, if we start them later.<br /><br />Again here the obstacle for companies in applying these principles is that these erroneous assumptions are built into the processes, measures, and systems we use to manage projects. The pressure from upper management and sales to add more projects or start them earlier can make it virtually impossible for managers below to cope with the pressure to multi-task. Conventional software, nearly all of which is based on Critical Path methodology, fail to provide managers with a way to accurately evaluate task priorities across projects. Critical Path can identify which tasks have priority over others within a given project, but it breaks down when considering tasks on different projects. How many times does it happen that someone works on an urgent task, only to learn later that it ended up sitting a downstream step waiting on something else, or because the priorities shifted again?<br /><br />The final reason for the pervasiveness of multi-tasking is that people want to do a good job. People multi-task in response to a perceived need of the organization: an urgent job, a hot task, a breakdown, a customer complaint, etc. Shifting to work urgent, pressing jobs gives people a chance to be heroes, to save the day, or put out the fire. In fact if you have multi-tasking in your organization, it is an almost sure sign that you have people who care about and are working hard to do a good job for the organization. It is essential to help people to realize the impact of multi-tasking, so they shift their belief of what it means “to do a good job.” But this must be backed by the needed process, measurement, and system changes or their efforts will be overwhelmed by these other forces.<br /><br />Reducing Bad Multi-tasking<br /><br />The impact on project performance from reducing multi-tasking is profound. Without so many interruptions and delays on individual tasks the work flows much more quickly and smoothly. Without adding resources or working people any harder, more projects get completed, faster. And without the constant pressure to re-prioritize work, and with more projects tracking on-time, the organizational climate improves dramatically. With these improvements follow the business results companies in project environments are universally seeking. The typical results we have seen companies achieve are:<br /><br />On-time completions to 95+%<br />Project durations cut by 1/3 or more<br />Project output 25%-100%<br /><br />To learn more about how to reduce multi-tasking and start to put your organization on a path to these kinds of results, read “More projects, faster, with less resources: Critical Chain Project Management.” This article is available free of charge on <a href="http://www.tocc.com/">http://www.tocc.com/</a>, or you can have it emailed to you by requesting it by name from <a href="mailto:info@tocc.com">info@tocc.com</a>.<br /><br /><br /><br /><br />About TOC Center, Inc. The TOC Center works with clients across the full spectrum of project environments to help them create and implement sustainable processes for delivering more projects, faster with the same resources. Over the past 20 years we have worked with such organizations as American Airlines, Bosch, Eircom, First Solar, Genencor, GM, HP, Intel, ITT, Kroger, Pfizer, Stryker, US Navy. For a free webinar for your management on how to accelerate projects, send an email request to <a href="mailto:info@tocc.com">info@tocc.com</a>. More information and actual client results available at <a href="http://www.tocc.com/">http://www.tocc.com/</a>.</div></div></div></div></div>Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com16tag:blogger.com,1999:blog-4738285107684892271.post-80195457595667983662007-06-15T16:29:00.000-04:002007-07-05T18:27:34.362-04:00TOC Stories #2: "Blue Light" creating capacity for nothingThis is one of my favorite stories from all of my years in applying TOC. I use it frequently in my consulting work and again it's totally true. In fact I've told it enough times that I finally came across someone who was in the room who said he used to work at that company and he validated in 100%. And if you were to go into one of the dozens of places where I've told this story, you are likely to find that they still talk about "Blue Light."<br /><br />It illustrates for me the essence of Theory of Constraints as a process for exposing and challenging assumptions that block us from seeing better solutions. Our assumptions cause us to accept things as facts, often without checking them, and limit us to looking for a solution within a false frame that prevents us from seeing a simple way out. If you are familiar with the brain teaser of the nine dots, arranged in a grid 3x3, where you have to connect all the dots with 4 straight lines and without lifting your pen from the paper, you know what I mean. (I think most are familiar with this but if not let me know and I will post it.) I hope you enjoy the story of "Blue Light".<br /><br />I was very young and had only been in consulting for a year or so when a company asked me to see if I could help them with a capacity problem in one of their plants. So one day I went to meet with the plant manager, it's never fun to be sent into "help" a plant by corporate, so I knew it might be difficult.<br /><br />The plant produces heavy metal bumpers for semi-trucks, and they had a major bottleneck in their welding department. Orders were backed up, and they were running at capacity around the clock seven days a week. The space in the plant was already tight, and they had plans to expand the building to add room for 3 more welding bays, doubling the current capacity.<br /><br />The plant manager informed me early on that they were running at 93% efficiency in the department, basically telling me there was no room for me to help them improve. It was my experience that there was <strong>always at least 25% more capacity </strong>that could be exposed in any plant. Moreover, I was young and brash enough to tell this 30-year manufacturing veteran this and that sight unseen it was true in his operation too. He must have thought my math skills were pretty bad because he reiterated that they were already at 93% efficiency, so this wasn't possible.<br /><br />I wasn't fazed and finally convinced him to take me out to at least look at the welding operation, since I had driven out to see them. Whenever I go out to look at an operation I had made the habit of formulating in my mind a simple picture or image of "what good looks like." In other words, what you would expect to see if an operation really was working to its maximum performance capability. As I am a completely non-technical person the image I put in my head as we walked onto the shop-floor was "blue light".<br /><br />I was pretty sure that if the welding torch wasn't turned on, emitting its funky blue light, that the welders couldn't be welding anything. So I decided to look first for how much of the time there was blue light coming from each of the three welding stations. (Yes I know that even this is not yet the indicator of optimal performance, but as you will see, it was way more than good enough in this case.)<br /><br />When we got to the welding area we watched for a few minutes quietly. The first thing I saw was one welder turning off his torch, taking off his protective gear and walking over to his buddy in the next booth. He waited until he got his attention and then he too stopped and took off his gear. Together they went back to the first guy's booth and lifted the heavy finished bumper off the welding table and onto a pallet, and then put a new un-welded one from the queue onto the welding table. The other welder went back to his booth.<br /><br />I then watched the first welder begin to peel the protective plastic coating off the bumper in the places he had to weld. It took a good bit of time picking with his fingernails to get it done. Then he grabbed the parts and clamped the onto the bumper, put on his gear and welder for no more than 30 seconds. before he was done. I looked at my watch, we had been there almost 5 minutes and he had welded for 30 seconds of it.<br /><br />Meanwhile another welder had just returned to his empty booth pushing a trolley, which he used to jack up and move his finished pallet to the next operation. He returned after several more minutes and consulted his schedule to see what job was next for him to do. Of course it turned out to be the skid of bumpers located against the wall blocked in by two other skids he had to move. After finding the right skid he moved the two other pallets out, got his to his booth and then moved the other two back out of the aisle. All this time zero blue light.<br /><br />He disappeared again with the trolley to go and get the parts he had to weld onto the bumpers from the store room, returning only several minutes later with them. Meanwhile the other two welders had repeated several times over the two-man bumper lifting dance described above. Just from this casual observation I estimated that the "blue light time" couldn't have been more than 10% and was probably far lower.<br /><br />As I watched all I could think about was "wow, did I sand bag this guy" (meaning the plant manager), I told him 25% more capacity. I missed it by one or two ZEROES! Just about then the plant manager turned to me and said something I have never forgotten. He said, "you see, they're busy all of the time!" And he was right, the guys were working all of the time and working steadily and hard at that.<br /><br />What amazed me is how the two of us could be looking at exactly the same things and see it entirely different. He had in his head an assumption of what good looked like that was based on the people being busy, whereas I looked at it from the perspective of the operation and the work it did, the blue light. His perspective totally blocked him from seeing any solution other than adding people, which was going to require him to invest in expanding the plant and worse still take months to implement during which they would anger more customers and lose hunderds of thousands in potential profits.<br /><br />To make an already long story a little shorter, we ultimately brought them to implement a very simple solution. They had a summer worker in another department (a non-constraint area of course) who knewnothing about welding, that they moved into the department to be the "helper" for the welders. We gave him a simple image to know if he was doing a good job. We told him we wanted to see more and more blue light from the welders' torches. His job was to lift bumpers with the welder, move pallets of bumpers around, stage the next jobs for each welder, and get all of the parts they needed ready for them. If he had extra time after this (which it turned out he did) he was to peel the plastic for the welder, and do anything else that would generate more blue light time.<br /><br />In less than three weeks they had totally cleared the area of work-in-process. This big backlog shipped out along with the on-going flow that was coming to welding, producing a record shipping month. I don't know how much capacity was actually created but it was more than enough to break the bottleneck, and if more had been needed it could have been generated just as easily.<br /><br />What limits us as individuals and as organizations are the assumptions we hold, and are failure to recognize them as just that "assumptions" and not facts.Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com5tag:blogger.com,1999:blog-4738285107684892271.post-11820207048861273262007-06-14T15:49:00.000-04:002007-06-14T16:09:17.442-04:00TOC Stories: Accelerating ProjectsThe remarkable success of Goldratt's business novel <strong><u>The Goal</u></strong> 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.<br /><br />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.<br /><br /><u>The Story<br /></u>“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.<br /><br />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.”<br /><br />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.<br /><br /><u>The Obstacles</u><br />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.<br /><br />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.<br /><br /><u>The Opportunity<br /></u>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:<br /><br />Projects were consistently behind schedule or late<br />Resources were not available when needed, even if promised<br />There was constant firefighting, with priorities shifting continually<br />There were too many changes and too much re-work<br />Necessary things (specifications, approvals, documentation) were not available when needed<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />Applying the methodology with the support of Concerto® software, the clinical pharmacy made the three fundamental changes for Critical Chain:<br /><br />· 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.<br />· 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.<br />· 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.<br /><br />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.<br /><br /><u>The Results</u><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br /><em>To comment on this story or to inquire about other stories you'd like to see, e-mail me at <a href="mailto:kfox@tocc.com">kfox@tocc.com</a></em>Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com2tag:blogger.com,1999:blog-4738285107684892271.post-88243881272356662622007-06-14T15:20:00.000-04:002007-06-14T15:49:03.569-04:00Why 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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.Kevin Foxhttp://www.blogger.com/profile/14436190226535806010noreply@blogger.com0