Using Theory of Constraints in Services

Business901 Podcast Transcription
Implementing Lean Marketing Systems

Using the Theory of Constraints
in Services
Guest was Dr. John Ricketts, author of
Reaching the Goal

Related Podcast:
Using the Theory of Constraints in Services

Copyright Business901


Dr. Ricketts is an IBM distinguished engineer.
Formerly a consulting partner in IBM Global
Services, John is currently a technical executive
in the IBM CIO’s office, but will soon move to
IBM Software Group. His prior experience
includes manufacturing operations, business
school professor, director of software
engineering, executive consultant, director of
professional development, and national service
delivery executive.

John’s doctorate is in Information Systems, Computer Science,
and Behavioral Science. He has received awards for his research
and teaching from the Decision Sciences Institute and the
Association to Advance Collegiate Schools of Business, as well as
IBM.

John is also a practitioner and innovator in the
field of Theory of Constraints. His book,
Reaching the Goal: HowManagers Improve a
Services Business Using Goldratt’s Theory of
Constraints, was published in 2008 by IBM
Press. Reviewers on Amazon.com soon gave it a
five-star rating. And Dr. Eli Goldratt, founder of
the Theory of Constraints, said it’s one of the
best books ever written on TOC.

John is also the author of “Theory of Constraints for Professional,
Scientific, and Technical Services,” a chapter in the Theory of
Constraints Handbook published in 2010.


Joe Dager: Thanks, everyone, for joining us. This is Joe Dager,
the host of the Business901 podcast. Today, I have Dr. John
Ricketts, an IBM distinguished engineer, and former consulting
partner in IBM Global Services. John is currently a technical
executive in the IBM CIO's office, and wrote a chapter in the
recent "TOC Handbook." John also authored the book "Reaching
The Goal: How Managers Improve a Services Business Using
Goldratt's Theory of Constraints." John, I'd like to welcome you,
and could you give me a brief outline about your writing so far?
Dr. John Ricketts: Good day, Joe. Thanks for having me on
today. As you just indicated, the first really public publication that
I did on Theory of Constraints was my book, "Reaching The
Goal." Prior to that, though, I did a number of publications that
were used internally at IBM, and we reached a point where we
felt like we had enough information that it was worth sharing with
the world, and that's what led to the book. Of course, we've
continued to work in this area since then, and the chapter in the
TOC Handbook -- that's the "Theory of Constraints
Handbook" -- is one of the more recent manifestations of
additional publishing work that we're doing. In parallel with that,
there's another chapter coming out in another book in a field
called Services Science, which is our contribution to Theory of
Constraints in that domain.
Joe: Is there a big difference between the chapter that you
wrote and the book?
John: Well, the core content is the same, but just due to the
size limitations, there's necessarily some difference. There's also
a difference in emphasis. What I mean by that is that the book
that I wrote a couple years ago goes into a fair amount of detail
on the problems that are faced by practitioners in the
professional, scientific, and technical services sector, and then
how traditional TOC applications don't really work as well in that
sector as they do in the industrial sector or the distribution sector

where they originated. It tells the story of how we came to
modify those applications so that they're still recognizable, but
they're much more adapted and workable in this new services
sector.
What the chapter in the TOC Handbook does is it talks a lot more
about principles behind TOC, to help people understand the
essence of why TOC is different from conventional wisdom. So
there are less of the nuts and bolts of how to do it, and more of
an explanation of why it really matters.

Joe: You made a great comparison chart in the book, where you
had TOC for goods and TOC for services in two separate columns
there. There is really a difference, a big difference, which that
page outlines on there, because to apply TOC there's a lot more
external work than internal work, is it not?
John: That can be true. I'm glad you picked that example,
because that arena is where we actually started our serious work
on TOC some years ago. What I'm referring to is: for those
people who know what theory of constraints is about, they'll
recognize that Joe and I are talking about something called
"replenishment" here. Replenishment is, in a nutshell... ...the
TOC application for dealing with distribution and distribution of
goods, predominantly. We attempted to use that in our services
business, and as you correctly perceived, Joe, we ran into the
problem almost immediately, because one of the fundamental
assumptions on how you do distribution in a goods environment
is: you have goods produced by a manufacturer, and then they
go into a distribution chain, which is, in a sense, kind of the flip
side of a supply chain, when viewed from the provider
perspective, and the goods move from there through a series of
distributors and warehouses and ultimately wind up in retail
establishments where they can be purchased by consumers.


The notion of a one-way flow through that process is really
central to the replenishment solution, because, essentially, once
the goods flow out to the retail location, they very rarely come
back. They don't flow the opposite way. As you correctly
perceived, Joe, in the services business and not just professional,
scientific, and technical services, but in any services
business -- whatever you're using to provide the service doesn't
necessarily get consumed in the course of delivering that service.
Now, in the case of professional services, we're talking about
people like lawyers or accountants or consultants who get
assigned to a customer engagement, deliver their service, and
once they've completed that work, then they -- to use the lingo
that we use in the services business -- they come back to the
bench, which simply is slang for: they sit there waiting for
another assignment.

In fact, they may not actually sit on a bench at all. There may be
another assignment waiting, in which case they go directly from
client A to client B, but that doesn't invalidate the notion that
people return from whatever assignment they've been given and
they need to be reassigned.
Given that that's the way services work, we couldn't really apply
the original replenishment application without some modification.
One of the modifications has to do with how you manage the
buffer. In theory of constraints, a buffer is some spare capacity
that you have specifically to manage the availability of whatever
resource it is you're trying to manage.

In the case of professional services, when a customer signs a
contract, what they don't want to hear from the service provider
is, "We'll be happy to start work on this in three months." What
they really want to hear is, "We'll have somebody on a plane or a
train or in an automobile, and they'll be at your site on Monday,
and we'll get this project going."


Well, that means that the service provider typically has to have
some spare capacity to be able to deploy resources that quickly. I
mean, it's not practical to go out and hire somebody on less than
a week's notice, and get them trained and onboard and out at a
client site.
So, it's fairly natural in the professional services business to have
a bench of some amount, and one of the struggles that
professional services organizations have perennially is: do they
have too big a bench or too small a bench? As you saw in the
book, Joe, the two pulls in this classic struggle are: "Well, we
won't have a bench at all, we'll just go find people when we sell a
new engagement, and we hope that customers don't notice the
delayed start." At the other end of the spectrum, there's a
situation where the provider has a huge bench, which is itself a
significant cost, because when people are on the bench they're
not bringing in revenue for the provider.
What we did with TOC in the replenishment solution is we
implemented a third solution that is at neither end of that
spectrum. It does use a bench, or a buffer, but it sizes it based
on the actual demand that the enterprise is experiencing. It
makes the enterprise much more responsive to customers, while
at the same time reducing the size of the bench that they
typically have to have.
Now, having said all that, one of the things that came to light
after the book was published is that this problem of having
enough spare resources to satisfy a request for services on
demand is not really limited to professional, scientific, and
technical services. It has equal applicability in some other arenas
where there's inventory that you might think would make that
enterprise able to use the original TOC replenishment application,
when in fact they can't.


Joe: When you apply TOC to professional services, it's still about
managing the buffer, and you have to build a flexible buffer to
handle that. Correct?
John: Anytime you're talking about a TOC application, you're
talking about some form of buffer management. One of the things
that makes the buffer in this replenishment for services
application different, however, is it's explicitly a bidirectional
buffer. And for that statement to make sense, let me explain
what the traditional TOC buffer would look like in a replenishment
arena.
Conventionally, the buffer, and you could think of this as a
product sitting on a shelf in a warehouse. The buffer is expressed
in the computer somewhere and its color coded based on the
number of items sitting on the shelf. If the number of items
sitting on the shelf is so few that you're likely to sell out before
you can get another shipment from the manufacturer, then the
buffer level is said to be low or in the red zone. The typical
management action would be to reach out to the manufacturer to
expedite delivery of more of that product so that you don't run
out.
If you have somewhat more inventory than what I just described,
you've got enough that you probably won't run out but you can't
really be sure, there's still a little risk there, it would be said that
that buffer is in the yellow zone. You would not take explicit
action there. You would simply watch it and if it strayed down
into the red zone, you would expedite. Otherwise, you just simply
continue to monitor any buffer that's in the yellow zone.
The third and final level in the conventional replenishment
application is the green level. Essentially, green means you've got
more than enough product to handle the next few days worth of
sales, or few weeks worth of sales. There's really no action
required. For most of the products that would exist in the


warehouse you would find that they would be in the green zone,
some in the yellow zone and relatively few in the red zone.

One of the important contributions that TOC makes is it focuses
management attention on those aspects that really require their
attention, i.e. the products with buffer levels down in the red
zone.
What's unstated in that conventional view of a buffer is there
really is a downside to having too many instances of the product
in the green zone. In other words, if for some reason the
manufacturer shipped you twice as much as you had ordered and
you accepted that order and you had just mountains of that
product sitting in your warehouse and you had paid the
manufacturer for that, that would be a situation where you really
had too much of a good thing because as you implement TOC, it
drives inventory levels down to help make the enterprise leaner
and not tie up so much of its capital in unneeded inventory.
So, I don't want to leave anybody with the idea that just because
you're in the green zone there's no problem. If you truly have
excess inventory, it's a problem. However, when we switch over
to the services side of implementing replenishment, and I'm
getting back now to what I was saying before about this being a
bidirectional buffer, the color coding in the buffer for a services
buffer in this arena is red, green, red, which means if you have
too few people on the bench, you may sell an engagement that
you can't staff and therefore, you have customer dissatisfaction
because you have a delayed start.

If you have just enough consultants on the bench ready to be
deployed or accountants or whatever the service provider's core
skill is, if you've got enough of them, it's in the green zone. But if
you happen to be in, let's say a seasonal business, and you've got
more resources coming back from engagements than being
deployed onto engagements, or if you're in an era where the


overall economy is sliding into recession and you're not selling
work quite at the same rate that you did before, here again, the
number of people coming back for reassignment exceeds the
number going out, and that can tip the buffer level into the red
zone on the excess end of that scale.
So what I'm saying is that in TOC for services, we have an
explicit bidirectional buffer and you want either too few or too
many instances of whatever it is you're trying to manage in the
buffer. And, that really is, because it's explicit, that's different
from the original incarnation of replenishment buffer for goods.
Joe: I think that's a great explanation of it. You could even have
five sections. You could have red, yellow, green, yellow, red. You
could look at where you're kind of in danger if you wanted to
really complicate things?
John: Well you know, I'm glad you brought that up because we
toyed with a five level buffer and we backed off that and stuck
with the red, green, red taxonomy because it's sufficient. What
we found was that the five level taxonomy was more complicated
than we really needed for it to be. One of the principals that you
see talked about in the chapter that I wrote for the TOC
Handbook -- and a very endearing characteristic of Theory of
Constraints -- is we make things no more complicated than they
have to be. Just enough to get the management decisions going
in the right direction. That's what we did here with the three level
buffer.
Joe: It allows you visually to see it. How do you take the next
step to do something good for your business out of this
visualization?

John: What we haven't talked about yet is service delivery.
That's where there is a project manager or project executive and
people with various skills being deployed out onto a project to
help customers. Typically, there's another role that has affect

here and that's the resource manager. The resource manager
basically manages the resource and watches those buffer levels.
When the buffer gets too low, they go out and hire more people
or acquire people from subcontracting firms. When the buffer
gets too high, then they look hard for other places to deploy
those resources or if it's the case of subcontractors, then they
may release them back to their parent organization.

But, they're basically trying to... The analogy that I use in the
book is that it's like driving down a winding road where you're
trying to avoid running off the cliff into the chasm on one side or
crashing into the sheer rock face on the other side. So, the
resource manager is watching these buffers and making sure that
they have the right number of people available for engagements
as they come along. The resource manager then works with the
project manager to get those people onto the right tasks on their
projects.
There's a separate TOC application for project management. It
goes by the name of critical chain. Just as there was a difference
between how replenishment works in a goods environment versus
how replenishment works in a services environment, we also
found that we needed to make some changes on how we would
employ critical chain.
Joe: When you applied critical chain to that process, what did
you find out?
John: Well, the conventional approach to critical chain project
management works one project at a time in the sense that you
use it to solve some of the big project management problems
that are endemic throughout our industry. The original critical
chain application on an individual project level worked OK for us.
We couldn't find anything that needed to be changed or improved
there to make it work for professional, scientific or technical
services. That said, however, when you begin to scale up and you


look at how this applies across multiple projects, then we ran into
some difficulty. And let me just pause and say, when I say
multiple projects, IBM in its consulting business does about
10,000 projects per year. That's globally. Just in one part of our
consulting business. So, I'm not talking about a handful of
projects here. I'm not talking about a dozen or two. The problem
that we ran into was: how do you manage this when you've got
huge numbers of projects going on and likewise, huge numbers of
people?
For our replenishment solution, we have hundreds of skill groups.
So those buffers that I was describing earlier -- representing
people on the bench or not -- apply to each one of those
individual skill groups. Where we have people that have multiple
skills, then they're assigned to a primary skill group, but we can
also see their secondary skills in other skill groups. If it's the case
that we're sold out on the people who have a particular skill as
their primary skill, the odds are pretty good that we can find
somebody in another skill group who has the skill that we're short
on as, at least, a secondary skill.
That's good for the employees because it gives them diversity in
their experience. It's good for customers because we can be
responsive to their needs. It's also good for how we manage
projects, because it gives us flexibility in how we can assign
people onto those projects.
Now, in a conventional TOC-for-goods kind of application of
critical chain, it's being used in an environment where the activity
that's being managed is fundamentally something like product
development. Or it could be product maintenance. In fact, let's
take the example of product maintenance, because it's easy for
people to visualize.

If you can visualize an airplane depot, where the service being
provided is aircraft maintenance, and they have a hangar that


can accommodate one airplane at a time, then you could view the
work done on an individual airplane as being a project, meaning
there's a specific sequence of tasks that have to be undertaken to
complete the service on that aircraft.
Some of those steps might be accomplished outdoors, but as
soon as you begin taking off cowlings and so forth, and you
expose the insides of the airplane to the weather, that's not
something that you would want to do outside. Not only is it prone
to dust and contaminants like that, it's also prone to insect
infestation and birds and so forth, so there's a certain amount of
work that really is best done inside the hangar.
If that hangar accommodates one plane at a time, and each
plane's maintenance is an individual project, then the
multi-project view of how all that works essentially looks like a
stair step when you lay out those projects, because as you move
from plane A to plane B to C to D to E and so forth, you'll be able
to see in the project plan the specific intervals of time when those
particular aircrafts will occupy the hangar and get that portion of
their maintenance.
That stair step pattern to multi-project critical chain is sort of a
TOC classic way to handle multiple projects, and it makes a great
deal of sense if you have a single constrained resource like I just
described. I just used the example of airplane hangar, but the
same example applies if you've got a person who's a key skill.
In our business, for instance, where we're delivering information
technology services, oftentimes our constrained resource is an IT
architect, who's a very experienced, senior person who basically
has the overarching view of what needs to be accomplished in the
project, and everybody else needs to subordinate, or make sure
that they don't waste any of the IT architect's time, because that
person is really key to the project.


So it's conceivable that when we have multiple projects, you
could tie them together in a stair step fashion using the IT
architect as the constrained resource. I say it's conceivable. In
practice, it turns out to be really difficult to do that, because of
the dynamic nature of the projects that we provide. Not only do
we provide IT implementation services, but we also provide
research services, and we also provide technical services: things
like building data centers, or doing maintenance on equipment,
and so forth.
When you have projects that require a lot of diversity in the
skills, it's difficult to pick just one skill and say, "This is the skill
around which I'm going to organize thousands of projects." So
the solution that we came around to was not to use the stair step
pattern, but instead to find a way to improve our flexibility so
that we could start projects on demand, or finish them on
demand, depending on which end of the project the customer
was really most focused on.
To get that flexibility, what we had to do was marry the
replenishment solution that I described earlier with this critical
chain solution, so that whenever a project manager says that
they need another person with a particular skill, the resource
manager can look at their buffer level, and find somebody that
can be assigned with that skill to keep a project on schedule.
Joe: When you're looking at developing this type of strategy, is
this overwhelming at first, to someone? I mean, we're talking
project management at a pretty high level.

John: Well, I wouldn't say it's overwhelming. What I would say,
however, is: it requires a different way of thinking. That's a
statement that really applies to all of TOC, because many of
us -- as we've grown up in whatever our career path has taken us
toward -- have learned from others, we've seen best practices,
and in the course of all that learning, what we tend to do is


gravitate towards conventional wisdom. That is, the
generally-accepted way to do things. That's both good and bad.
It's good in the sense that it eliminates the search for a lot of
solutions that might prove to be fruitless. On the other hand, it's
bad in the sense that sometimes we get stuck looking at things a
certain way, and when another alternative comes along, it can be
hard to get unstuck.

So with TOC, a large part of the implementation actually starts
with the buy-in process, wherein you have to help people
understand what their core problem is, and then understand what
could be done to remedy that core problem.
One of the things that I love about TOC is: unlike other
approaches to continuous improvement, which tend to pursue a
boil-the-ocean approach, and by that I mean: we go look for pain
points. We'll go interview customers, and we'll talk to their
managers, and their managers have long, long lists of places
where they feel pain. But if you get under the covers of all that,
and you look at how their processes work, typically a lot of those
pain points are the result of just one, maybe two core problems.
If you can use TOC to have sort of a laser-like focus on the core
problems, in the course of addressing those core problems, you
alleviate a lot of pain points.
It's that ability to focus and to get leverage that really
distinguishes TOC from some other very well-known approaches
to continuous improvement. I'm referring to things like Lean and
Six Sigma, which are very commendable approaches. They have
lots of good things to offer, but one of the things that have given
me a little heartburn with them over the years is they tend not to
be focused. They tend to strive to create performance
improvements everywhere, including places where the
improvements don't move the needle at the enterprise level.


So, one of the criteria that we use for TOC implementations is,
"Are we making a change that's really going to have beneficial,
measurable impact at the enterprise level? And are we avoiding
instances of improvement that really aren't going to have
measurable benefit?"
Joe: I'm always frustrated when I hear the words of "the
low-hanging fruit." Low-hanging fruit can hang low if everybody's
a midget. I mean, if it isn't going to resolve anything, why go
around picking it?

John: We sometimes speak of forbidden fruit because it gets
you into exactly the situation you described, Joe. Just because its
low hanging doesn't mean you should pick it.
Joe: Sometimes that low hanging fruit does serve a purpose
somewhere and if it's not bothering anything, just leave it alone.
You raise an interesting thing is that: are you using TOC then in
marketing and sales and is it something that can be used there?

John: We have used TOC for marketing and sales. We've used it
for measurements. We've used it for process improvement. So
yes, we do use TOC. As a TOC advocate, I'll have to be honest
with you and tell you that its penetration isn't anywhere near
what I would like for it to be. We continue to push on that and
continue to gain ground.
Joe: I think there's a deeper meaning in sales and marketing
arena for TOC when you're talking about matching to the
customer needs are pretty imperative in today's world, isn't it?
John: In fact, if you look at the traditional way that TOC has
been applied to marketing and sales -- which by the way is very
effective -- fundamentally what you have to do is help your
customer identify their core problem and solve their core
problem. If you can help them do that, then you've become their
business partner in improving their business. Let's take the

examples of hospitals. I've been using examples from
professional scientific and technical services because that's where
I happen to work. A lot of these TOC principles apply equally well
in other services business and hospitals are a handy example.
If you conceive of the treatment for an individual patient as a
project, and I think, at least in some arenas that's a very, very
valid approach, what you wind up with is a series of actions that
have to be undertaken, i.e. tasks in the project, to be able to
produce a desired output, i.e. health of the patient. It’s not a big
stretch to view patient treatment as a form of project
management.
If, as a service provider, I can go to a hospital administrator and
the doctors that practice in that hospital and show them ways to
modify their business process to cut significant time out of that
project which represents patient treatment, they get higher
throughput through their enterprise, meaning they can treat
more patients with the same doctors, the same clinical facilities,
the same technical staff that they have today.
There have been some recent cases published of work done in the
hospital arena where there have been just astounding
improvements in the throughput through hospitals by applying
TOC principals.
Joe: Is TOC a problem solving solution?
John: It's that and more. As we were saying moments ago,
buy-in is a key element of TOC. Because TOC doesn't really fit
conventional wisdom, nobody is going to willingly sign up for it
until they understand how it's going to make their world better.
That's the challenge that we all face no matter what kind of
process improvement we're trying to help our customers or our
colleagues within our own enterprise adopt. It's getting people to
buy in and understand how whatever you're proposing is going to
make things better.

Once you can do that, then things slide along pretty well.

Joe: You discussed the pain points before, and you talked about
that there was a conventional way to doing it. UDEs, or
undesirable effects, is the conventional TOC way to do it?

John: Right. There are some diagramming techniques in TOC,
and given that this is an audio podcast and I can't draw you a
picture, we won't go too far down that path, but let me just
suffice it to say that there are existing diagramming techniques
and those techniques do, indeed, begin with what you referred to
as UDEs, or that's initials UDE for undesirable effect. That is the
place that the creation of the current reality tree begins.
Ultimately, though, what we want to do is create a different
version of that tree, the future reality tree that shows how we're
going to go from the current state of affairs that contains those
undesirable effects to the future state that contains desirable
effects.
Part of the difference in mapping from the first one to the second
one is to figure out where to do something different. In our case,
the something different was adopt replenishments for services
instead of hiring to deal or hiring to forecast.
Another part of our solution was to adopt critical chain for
multi-projects instead of continuing to do critical path projects
with hire to deal kinds of resource reaction.
Joe: Was that a difficult concept for you to teach in your
organization or to get people familiar with using logic trees?
John: Well, it depends. Creating these trees is a lot harder than
reading them. So what we have are some people who are skilled
at creating the trees and then a lot of other people who are
certainly able to read the trees but wouldn't necessarily be able
to draw one on their own. It is a learned skill. Like most
consulting engagements, it's one of the tools that our consultants

carry around in their kit bag. Often times the production of a new
diagram is a collaborative process. I have seen, for instance...
Well let me give you a specific example.
Almost 10 years ago when we got involved with Theory of
Constraints, Eliyahu Goldratt came to an IBM location and we
were trying to decide whether to sponsor one of his seminar
series at the time. About a dozen of us sat around a conference
table and we actually built the current reality tree and the future
reality tree collaboratively with Eliyahu himself.

Joe: Has that been applied throughout IBM? I mean, would you
call IBM a Theory of Constraints company?
John: I would say that IBM has been on the forefront of some
innovations of TOC. But, there are lots of people in IBM who do
not practice TOC, to be honest. That's why I said earlier that we
continue to work on the buy-in process and we continue to get
some additional adoptions. But, it would not be correct to say
that IBM is fundamentally a TOC company, yet.
Joe: What has been the difficulty of getting people to buy in to
TOC?
John: Well, the difficulties that we face are the same difficulties
that any multinational corporation faces. We have 400,000 people
operating in 150 different countries. We have 15,000 hardware
products, 800 software products in about 8,000 different
configurations. And to be honest, I don't know how many service
offerings we have but I'm sure it's in the thousands, as well. Just
the sheer size and complexity of that means that it is difficult to
go out and reach everyone at once. The typical rule of thumb
that's used for TOC implementation is when you get to about 15
percent buy-in amongst the employees; you've reached the
tipping point where TOC can take off. It's been a long road. We
haven't quite reached that point yet, but we continue to work on
it.

Joe: Practical experience, it is so important. One of the things,
when someone gets it and that light bulb comes on for them,
where is that tipping point for a person? Where have you seen
that where someone kind of finally sits back and says, "TOC is,
I'm buying into it, this is a good thing." Is there a certain tipping
point? Is there a certain time that a light bulb comes on for
someone?

John: It comes on in a lot of different ways. We did Jonah
classes. For those of your listeners that might not be familiar, if
you go all the way back to one of the original TOC books, it's
entitled "The Goal", it's written by Eliyahu Goldratt, it's a business
novel that tells the story of a beleaguered factory manager who is
really facing oblivion and he figures out how to apply TOC in his
organization and basically saves the day. It's a fun read as well
as an educational read. One of the central characters in that book
is named Jonah. He's essentially the TOC expert that whispers in
the ear of this factory manager and guides him. Ever since the
publication of that book, people who have been trained in TOC
and are avid practitioners of it are known as Jonahs and we held
a Jonah class and, of course, for people in that class the light
bulb went on during the first couple of weeks.
Then most people became emissaries and began working on
finding ways to apply TOC elsewhere. And they were working with
people who were not Jonahs.
We used a variety of ways to get people to buy-in to TOC. In the
case of the resource managers, we actually built a simulator that
showed them, that allowed them to look at how replenishing
resources would work under TOC versus how it would work if
done conventionally. And they were actually able to see how the
process was going to be improved and their life was going to
better, their work life was going to be better, when they adopted
this new approach.


As I said earlier, the key part of getting buy-in is to help people
understand what the core conflict is and then understand what
needs to change to move from the current to the future reality.
That's the point and time when the light bulb goes on and when
they can see the benefits and taste the benefits, then we get
buy-in.
A third way that the light bulb goes on for people is more and
more nowadays, people are being exposed to TOC in their college
curriculum. So we actually have college graduates or people
coming with Master's degrees out of universities who have been
exposed to TOC and are hungry to apply it and unfortunately they
tend to run headlong into conventional wisdoms. So, when we
can find instances of people who are actively interested into apply
TOC, we may mentor them and give them opportunities to apply
that.

So, that's just three ways, Joe.
Joe: When you learn something in continuous improvement, you
seem to struggle or go even backwards a little bit, then at once,
everything clicks and everything starts working. To get past that
point, to get to that plateau, is a struggle because it's seems like
you're not getting anywhere till you get there and all of the
sudden it clicks and it happens. That's why people give up, I think
a lot of times, on continuous improvement.
John: Backsliding is a problem. We've seen instances amongst
our customers where are better solution was implemented but
then the manager who was the advocate of the better solution
gets promoted or moves to another position somewhere else.
When the successor comes in, if they're not taken through
fundamentally the same buy-in process, they're confronted with a
new solution that doesn't fit their conventional wisdom headset,
and they may be inclined to rip it out just because they don't


understand it. So, it's important to have a transition there to
maintain the continuity so that you don't slide backwards.

Joe: When you write a book, you learn so much from, I think,
afterwards, from the comments about it and the application of
the things in the book that the people comment back to you.
What have you learned from writing a book?
John: Well, one of the pleasures from writing a book is you get
to read chapters to friends and acquaintances and pick their
brains on a variety of topics. One of the resources that I had was,
of course, other “IBMers.” But another important resources was
people out in industry or in academia who are members of an
organization called The Theory of Constraints International
Certification Organization, or TOCICO for short. Nearly ten years
ago, IBM was the host for the founders' conference of TOCICO.
So we have some history going back with that organization and
as its name applies it's an organization that has tests, has
education, and they certify people in the practice of TOC. I was
able to pick the brains of some of the best-known minds on TOC
in the world, who are also members of TOCICO, and we
maintained those relationships over the years.
In fact, the next international TOCICO conference, which will be
held in 2011, will be held in an IBM site we have in Palisades,
New York. The TOCICO has basically rented the entire facility
which is a relatively sizable facility that has a hotel attached to a
conference center. And I think the reason that that site appeals
to the TOCICO that it's fairly academic and collegial in its feel
even though it's a facility that's owned and run by a major
corporate entity.
Joe: There have been a lot of inroads outside of industry with
Theory of Constraints and in Academia. Do you see that as a
positive outcome of TOC?


John: I do. In fact, IBM has a strategic initiative called Services
Science, Management & Engineering or SSME for short. It's an
attempt to achieve for the services factors what was achieved
decades ago for computer science. I don't know if you're familiar
or not, but if you look back at what was happening in the
computer field back in the '50s and '60s, there really wasn't any
academic program for what we now view as computer science. So
there was an initiative undertaken to increase awareness and it
eventually led to the professionalization of that as a legitimate
academic field. Ironically, you know, nowadays here we are in the
21st century. We live in a world where over 70% of the
developed world economies are in services factors, and yet we go
to universities and you look at their curricula, and you look at the
training they're providing their students, it tends to be oriented
towards careers that are really 20th century careers.
So we're working with universities to help them turn that corner,
update their curricula, and one of the options that we offer them
is help with theory of constraints as a way of getting into a
services sciences mindset.
Joe: IBM is, of course, a huge software company. I am familiar
with the Agile Movement and Scrum is part of my background in
software development. Does IBM use other disciplines like that
within their software development to your knowledge?
John: We do make extensive use of Agile, yes. We do not only
do that on internal development projects, but we also do that in
engaging with customers. If you look at IBM's business
nowadays, the business model has changed dramatically over the
decade in a sense that if we had to go back 50 years, the bulk of
the business was hardware and software came along with the
hardware and services was something that we did but we didn't
really talk about it as separate. That model is completely turned
around now in that services are more than half of IBM's revenue.


Software is a very, very large share. Hardware is still important,
but percentage-wise it's down from what it was decades ago. We
do use Agile methods in not only in our internal projects, but also
external projects with customers, wherever we're dealing with
software or hardware.
By the way, we used TOC in our manufacturing environment as
well. I didn't explicitly acknowledge that earlier, but we have used
the very conventional approaches to TOC for goods in our
hardware business.

Joe: Using Agile methods does that meld with TOC or have you
experienced that all?
John: Well, it can, but it doesn't necessarily. What I mean by
that is if you look at how TOC does its critical chain application, it
changes how projects are estimated. Conventionally -- and this is
true even with some implementations of Agile -- you wind up with
contingency in every one of the tasks in the project plan. So
people tend to want to take exactly the amount of time to
perform that task that they estimated, and that's true regardless
of whether you're doing a conventional approach to project
management or an Agile method. TOC takes a different approach
to that altogether. It says, "Let's do task-level estimates that are
at the 50% confidence level and let's build a buffer at the end of
the project that basically brings together that entire contingency
in one place so that we can manage it in such a way that it
protects the overall project.
You can do that with Agile or you can do that with conventional
project management. But you have to have that project level
buffer to really be legitimately doing critical chain, and the way
you get the project buffer is to change how you do the task-level
estimates.
Another area, though, where I think the thinking behind critical
chain and TOC, and the thinking behind Agile is completely

aligned what TOC calls the roadrunner mentality. Roadrunner
means when you start a task you focus on that one task; you go
as fast as you can to get it done, you don't get distracted by
multitasking on multiple tasks within the project or multiple tasks
that cross projects. That latter point is one where the people who
are performing the task, I think, can buy into it pretty easy.
But you also have to get buy-in from the project executive and
from the partner who has sold the engagement and from the
client and from a lot of other people who, with the best of
intentions, may take you down the wrong path in the sense that
they view multitasking as a way to get higher productivity.
That is the trap, because multitasking has been shown, I think
pretty definitively, to not improve productivity, but to actually
decrease productivity. So, the second thing that you need to do
to implement TOC -- be it an Agile environment or in a
conventional environment -- is the roadrunner approach. Drive
out the bad multitasking and allow people to go as fast as
possible when they have work to do.
Joe: In the same idea of Agile and TOC is there Six Sigma and
Lean incorporated at IBM at all?
John: Yes, in fact, we have practices that do that kind of
consulting. We have Black Belts.
Joe: Do they incorporate TOC as part of their process?
John: Well, if I'm involved, they sure do. But for the reasons
that we talked about earlier, it gives you that focus and gets you
away from boiling the ocean.

Joe: I think very few Lean Six Sigma practitioners would not
adhere to TOC. I think it does require that they just use it as
underneath their umbrella rather than TOC being the umbrella for
them.


John: Right, fair enough. One of the things that can actually
turn people off to TOC is that word "theory". That's unfortunate,
because it's oftentimes misunderstood. When managers hear the
word "theory", they oftentimes think, "Well, this is just a bunch of
idle thoughts of someone who's in an ivory tower somewhere,
and really doesn't connect to my world." So, in those instances
where people are going to be put off by the word "theory" and
"theory of constraints", we often times just leave the word out.
We talk about constraints management. That seems to resonate a
lot better with managers.
Joe: One of the things that you talked about is the book "The
Goal". It was such a good novel, and an easy read for people that
it also, branded TOC unfairly. It limited its scope to operations
and constraint management, versus really the different thinking
processes and the different ways the Theory of Constraints can
be applied, and I think the TOC handbook has helped that.
John: Right. You know, the TOC handbook that you referred to,
is actually, I think, a landmark publication. In the sense, that it
brings together the writings of 44 experts from around the world,
including Eliyahu Goldratt himself. The work that Jim Cox and
John Schleier did in finding those authors and then shaping them
so that they would have consistent messages, I think is a real
achievement, and it's a landmark, because it really... It's
evidence of a certain level of maturity in the theory of constraints
community. Those people who are close to the community could
feel it, but now that this book is out in the public domain, a lot of
other people, I think, are going to picking up this book, and
reading a chapter or two, and realizing that...
When they read "The Goal", they got an introduction and a little
exposure to TOC, but there's this huge world out there of
additional applications and additional domains to which those
applications can be applied. So, I think for people that pick up the
handbook, they're going to be pleasantly surprised, because

there's a lot of new information that's been published in this
handbook that has never before been in print.

I mean, it's been talked about from expert to expert, but it's
never actually been in print. So, if you look at the level of
knowledge per page that is being provided in a book nowadays, I
think, the TOC Handbook really pretty much floats to the top of
that list in terms of bang to the buck.
Joe: I have to be honest with you, John. It's not a good airplane
book. I don't recommend it for that?
John: There is an alternative for those people who have a
Kindle. You can get individual chapters, and I think that makes it
much more amenable for airplane reading.
Joe: Where do you think TOC is going at IBM?
John: I continue to be a TOC focal point. We continue to do
publication there. We continue to educate internally so that they
can in turn work with our customers. So, I think it's following a
relatively conventional path in the sense that we continue to add
converts both from our university hires, and also from our
internal work. Hopefully one of these days we will reach that
tipping point where you and I can do another podcast and I can
proclaim that IBM is a TOC company through and through.
Joe: I wish you the best of luck in doing that, John. I want to
thank you very much for being on the podcast. This podcast will
be available on the Business901 blog site and the Business901
iTunes store. So, thank you very much, John.

John: Thanks, Joe. Enjoyed it.



Joseph T. Dager
Lean Six Sigma Black Belt
Ph: 260-438-0411 Fax: 260-818-2022
Email: jtdager@business901.com
Web/Blog: http://www.business901.com
Twitter: @business901
What others say: In the past 20 years, Joe and I
have collaborated on many difficult issues. Joe's
ability to combine his expertise with "out of the
box" thinking is unsurpassed. He has always
delivered quickly, cost effectively and with
ingenuity. A brilliant mind that is always a pleasure to work with." James R.

Joe Dager is President of Business901, a progressive company providing
direction in areas such as Lean Marketing, Product Marketing, Product
Launches and Re-Launches. As a Lean Six Sigma Black Belt,
Business901 provides and implements marketing, project and performance
planning methodologies in small businesses. The simplicity of a single
flexible model will create clarity for your staff and as a result better
execution. My goal is to allow you spend your time on the need versus the
plan.

An example of how we may work: Business901 could start with a
consulting style utilizing an individual from your organization or a virtual
assistance that is well versed in our principles. We have capabilities to
plug virtually any marketing function into your process immediately. As
proficiencies develop, Business901 moves into a coach’s role supporting the
process as needed. The goal of implementing a system is that the processes
will become a habit and not an event.

Business901 Podcast Opportunity Expert Status


Using Theory of Constraints in Services

More Related Content

What's hot (20)

Viewers also liked (14)

Similar to Using Theory of Constraints in Services (20)

More from Business901 (20)

Recently uploaded (20)

Using Theory of Constraints in Services