Reaching the Goal
I was given a complimentary copy of Reaching The Goal: How Managers Improve a Services Business Using Goldratt's Theory of Constraints 
The book organization is fairly standard. Ricketts provides background on Theory of Constraints and on Services. He describes each of the core TOC applications as they are traditionally defined. (And he does a good job of describing them in about five pages each.) Then he goes through each of the TOC applications and describes how they can be applied to a services business: why there are differences and how the applications can be adjusted. This is the core part of the book. Then he spends a couple chapters discussing implementation, including the kind of technology that would be appropriate to support a TOC for Services implementation. Ricketts provides a number of examples where the TOC applications are played out in more detail. Sometimes these contain too much information, but it is helpful to see the ideas built into these examples.
The main idea behind the book is to apply Theory of Constraints to the Professional, Scientific and Technical Services businesses, which is about as far removed from TOC's manufacturing origins as possible. My reading of the book leads me to believe that the key difference with services businesses is that the constraint really is the people who provide the services. It is not machines or the distribution system or project sequencing. As a result, the TOC applications need to be modified to take this into account.
The biggest change has to do with the definition of "services" as being those that customers typically want immediately and can frequently get from competing businesses. In other words IBM's mantra: services on demand. Where TOC traditionally looks at capacity being relatively fixed and delivery times being negotiable, TOC for Services (on Demand) changes the equation to flexible capacity a delivery as required by the customer. This is my biggest quibble (or misunderstanding) with the book. My understanding of the TOC approach is to do everything to make it possible to deliver to the customer within their "tolerance time" (the time they are willing to wait for a product or service). All of the operational improvement efforts in TOC are geared around reducing cycle time and speeding delivery. TOC for Services does this too, but Ricketts takes it another step further with the On Demand viewpoint.
This creates the other big change: since the "product" service businesses supplies (expertise) isn't consumed at the end of the job, it returns to the business ready to work on the next assignment. As a result, TOC guidelines that are based upon consumption and replenishment need to be modified to account for the return of resources.
Here is my attempt at describing how each of the TOC applications changes.
| Application | Traditional TOC | TOC for Services |
|---|---|---|
| Replenishment | Used to replenish supply chains through distribution networks. The main idea is to shift from push to pull to aggregate variation in a central location. | Replenishment for people resources needs to account for the fact that people come back from their assignments, so the mechanisms around replenishment need to buffer around demand for given roles. Ricketts introduces the idea of buffers which can be approached from two directions, rather than just one, which I find intriguing. |
| Critical Chain | Project management. Protects the entire project by moving task-level slack into a project buffer. | To offer projects on demand, this must be integrated with the replenishment solution. Otherwise, Critical Chain operates essentially the same. |
| Drum-Buffer-Rope | Used in manufacturing to pace the flow of work through the system, based on the capacity of the constraint. When there isn't an internal constraint (because the market demand is lower than what the facility can produce), DBR is still used to provide a due-date quoting mechanism and to monitor capacity. | Used to manage service contracts, such as for operating a call center or being the IT support function for a company. The difference here has to do with metrics around service levels and how that ties back to the TOC metrics. |
| Throughput Accounting | Beyond the basic measures for Throughput, Operating Expense and Investment, Throughput Accounting gives a number of calculations and recommendations for decision-making with TOC in mind. | Ricketts keeps most of the Throughput Accounting concepts, but makes a big change with the concept of Resource Dollar Days to be used as the key effectiveness measure (parallel to Throughput Dollar Days). I don't fully understand RDD, but it keeps bothering me that it can be greater than zero where a non-zero TDD signals that something is going wrong. |
| Sales and Marketing | It seemed like the solutions here were very similar between traditional and services-based TOC. In both cases, it is important to use a pull methodology, rather than push. With services, you have to be more cognizant of the resources constraint, but good TOC sales & marketing approaches are always built with the constraint in mind. | |
| Strategy and Change | This is another area that feels similar to standard TOC. Strategy is set at a high enough level, that I don't see why there should be a significant difference between the traditional TOC targets and service-based businesses. | |
Along with the changes to the specific applications, the other thing that becomes clear is that to get the most benefit out of TOC for Services, it makes sense to implement all of these applications of TOC. Traditional TOC, at least non-strategic implementations, are just fine with implementing one of the applications areas. Strategic TOC implements the core applications, which usually encompasses almost all of the TOC applications.
I also love this catch in the Implementation and Technology chapter (p. 274):
TOC also supports an empirical approach to identifying best practices.... Best practices are activities that enable the enterprise as a whole to reach its goal via continuous improvement at constraints. It can't be a best practice if it doesn't move the needle.
6 Comment(s)
Interesting post. Great feedback from Henrik.
I see Critical Chain as a methodology for projects. Not strictly a "critical chain" of events scheduling tool.
First, eliminate "bad multitasking" from your organization. At least for those on the "hot seat". The weakest link.
Second, build better project plans with Tony Rizzo's TMx.
Third, implement Spherical Angle's cc-Pulse and cc-MPulse.
But use Dettmer's "Strategic Navigation" (SNAV) as the guiding force. You need Boyd's OODA Loop to make it happen... and make it happen faster than your competition. It is all in SNAV. Skip the first 26 pages if you are not a military history fan.
-ski
said:
Thanks both Ski and Henrick for your comments.
CCPM is an interesting case. You are absolutely correct that poor management around the projects will cause as many (or more) problems as poor management during projects (aka "execution").
What I've discovered is that a good implementation of CCPM covers many of the issues that Henrick raises. In fact, just the work of defining what it means to run a project surfaces a lot of these issues, and you have the opportunity to correct them. Then during execution, you see a lot less of this arising.
With respect to Ricketts' book, he doesn't spend a lot of time discussing how to implement individual aspects of the solutions. He talks about it in general terms, leaving it to the reader to find expert consultants and other books to guide them through the work.
said:
Thanks for summarizing key points from my book. I appreciate it, and I bet your readers do too. I may be able to help with some clarifications.
First, while it's true that single-project Critical Chain is unchanged in TOC for Services, multi-project CC (MPCC) is changed quite a bit. Traditional MPCC assumes the enterprise has an internal resource constraint around which projects must be scheduled. In contrast, TOC for Services assumes the enterprise has an external market constraint. Replenishment for Services is what enables a service provider to schedule multiple projects around customer due dates instead of resources.
Second, in TOC for Services, Project Dollar Days and Process Dollar Days are analogous to Throughput Dollar Days in traditional TOC. Resource Dollar Days are analogous to Inventory Dollar Days. If PDD and RDD both indicate something is wrong, they're saying projects or business processes are not performing well because the enterprise doesn't have enough of the necessary skilled resources.
Good suggestions! Good points from all of you guys. I also want to purchase that book, Reaching The Goal: How Managers Improve a Services Business Using Goldratt's Theory of Constraints by John Ricketts, for that will add awareness to me.
said:
I'm a long-standing proponent of TOC, and have used it to great advantage with numerous clients on numerous projects, almost all within the service sector. I'm not at all ambivalent about John Ricketts's book Reaching the Goal. It's great. Not the last word perhaps, but certainly a significant advancement.
Leave a comment
KJolt Memberships
Thanks for the review. I still don't know if I'm going to buy the book though. Every review I've read so far has been rather ambivalent.
Still, TOC must be developed quite a bit to be really useful outside manufacturing.
One thing that has been bugging me lately is that the Critical Chain is assumed to be the constraint of all projects. This is based on the assumption that scheduling is what limits all projects abilities to reach their goals.
I do not believe that. There are plenty of things that may constrain a project. For starters:
1. False goals. That is, setting project goals that are not in line with organizational goals. Very common. Suppose the goal of the organization is maximum ROI now and in the future. Then set project goals like "deliver the contracted scope in the specified time, at the specified cost, with maximum quality". It is easy to show that the project goal and the corporate goal are contradictory in projects with a lot of common cause variation.
2. Competence. For example, software development project costs may be driven through the roof, and Throughput may trickle down to nothing because of a lack of competence in requirements analysis, development, or management.
3. Technology. Again, in software development, there is rarely any brain power expended in choosing the right language and tools for the job. Rather, people tend to use what they used the last time, regardless of whether it is a good idea or not.
4. Organizational problems. There is no end to all the ways organizations keep asking for trouble: matrix organization, multitasking, outsourcing the wrong things, hare-brained compensation schemes, arbitrary reward and punishment systems, etc. All of these can and do affect projects.
5. Poor project start-up procedures. There are plenty of ill conceived projects that are completed "successfully", but bring no benefits to anyone. And of course, many projects that would really be needed never get off the ground.
I am not saying that Critical Chain scheduling should not be used. On the contrary. I am just arguing that there are often worse problems, that should be dealt with first.
Does Rickets have anything to say about this? My experience is primarily from software development, technical writing and information analysis projects, but I believe it is reasonable to assume the same type of problems can and do pop up in the service sector. (For example, which is worse: patients at a hospital having to wait a few hours extra, or patients getting the wrong treatment?)