Dr. John Ricketts is a practitioner and innovator in the field of Theory of Constraints. His book, Reaching The Goal: How Managers 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.
Related Podcast: Using the Theory of Constraints in Services
Download PDF Transcript of Podcast
Note: This is a transcription of a podcast. It has not gone through a professional editing process and may contain grammatical errors or incorrect formatting.
Transcription of the Podcast
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 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 the 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 service’s 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 the 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 service’s 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: Any time 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 day’s 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 service’s 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 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 are 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 affected 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 the 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 the 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 the sort of 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 the 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 a 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.
The 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 a 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 a 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 were 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 the 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 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 all together. 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 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. 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 pick 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 a 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.
Lean Sales and Marketing: Learn about using CAP-Do
Special Marketing with Lean Book and Program offers on Facebook