Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 17

CUIM_MBAI_QBA II_CIA2

Page 1 of 17
CUIM_MBAI_QBA II_CIA2

BOOK REVIEW

OF

Critical Chain
By

Eliyahu M. Goldratt

REVIEWED BY:-
VYOMESH RANJAN

INTRODUCTION

Page 2 of 17
CUIM_MBAI_QBA II_CIA2

The subtitle of this book “A Business Novel” is very true in representing this book as a novel
introducing a theory subject like “Project Management” in a different way. We can say this book as an
innovative way of presenting a subject of this type with lots of conversation and examples instead of
charts, tables and figures. Well when this book was assigned to us for reviewing, we never thought that
a book of a subject like project management will be this much interesting to read and these theoretical
topics will be clarified by presenting in a form of story. This book outlines the complete technical
application of Theory of Constraint to Project Management. This book mainly gives the five steps of
Theories of Constraint.

While reviewing this book we can have two aspects of summarising or reviewing this book i.e.

 Summary of the story part.


 Technical summary.

So first of all I would like to summarise the story of this book “Critical Chain” so called sequel of
“The Goal”.

Page 3 of 17
CUIM_MBAI_QBA II_CIA2

SUMMARY OF THE STORY

The main story in the book is about an associate professor named Rick Silver who is

Struggling to make it in the academic world. He is a very good teacher, but he wants tenure and is
in need of publications. His area is project management and he wants the articles to make a
difference in this field. The fact is that the theories applied to project management are not effective
and projects are running late at high expenses. The work is moving very slow, but he gets the
inspiration when he is assigned to teach a course in an Executive MBA course.

During the course professor Silver and his students develop the concept of the “Critical Chain”. The
teaching style of professor Silver is conversation with the students about different topics. The
students get homework to do and in this course the homework tasks becomes case studies for the
theories that they develop in the classes. He is also helped by the fact that three of his students are
involved in a project at their company to develop a way to cut product development time.

Through out the book the theory is developed, and different concepts of project management are
covered. The inspiration for the critical chain comes from the “Theory of Constraints” (TOC),
which is taught by another professor in production management. TOC identifies the bottleneck or
constraint, exploits it and then subordinates all other activities to that bottleneck.

The same concept is shown throughout the book to apply to project management as well on several
levels.

As mentioned above the teaching and development of the “Critical Chain” theory is the main story.
At the same time small stories about Rick Silvers personal life, problems with economy at the
university and some cases from the companies where the students apply the theory, run in parallel.
The economy problem almost makes the promotion of Rick impossible, but the new discoveries he
makes in the course and the support it gets from the industry, supports his “survival”.

Page 4 of 17
CUIM_MBAI_QBA II_CIA2

REVIEW OF THE BOOK

I will divide the review into three categories review of the form of the book, review of the content.
As I mentioned in the introduction the book is written as a novel with a lot of discussion. This
form makes it very pleasant to read. The topics of the book are presented to the reader through the
conversations and the discussion professor Silver has with his students, colleagues and people
from business. Also the discussions concern a lot of examples and analogies which makes it easy
for the reader to see the application of the theories. The parallel stories make the story more
enjoyable and they do not disturb the “real story”. I also mentioned in the introduction that it was
few figures. The figures that are there are vital, but on some occasions I think there should have
been some more figures.
Concerning the content of the book it is I think, good to have some knowledge about project
management and critical chain theory before reading it. By that I mean that the background from
the Project management course was enough to understand the problems and enjoy the book.
Through the classes of professor Silver and the problems of the students the reader is introduced to
the TOC, critical path and critical chain. Different topics are explained through the answers to
questions that the students address. Other concepts such as the “Triple
Constraint” of project management is covered.
In the lectures the class identifies the problems their projects are having, and from that the theory
is developed. The classes usually end with some consensus about the problems often stated as
professor Silvers summary of the lecture. These statements I think are conceptual errors that occur
in project management and may work as warnings or helpful tips within ones own project if one
bears them in mind. An example is:
“There is no way to achieve good throughput performance through good local performance”
By that one means that one must optimise the system as a whole, which implies identifying the
bottleneck.
The book will not function as a reference book, because of the form of the book, but it serves its
purpose as an inspiration and introduction to the problems and solutions (at least according to this
theory).
How will this affect my work? Well what I can say that it was very inspiring to read after dealing
with the topic in our classes and I look forward to learning more in our coming lectures. The

Page 5 of 17
CUIM_MBAI_QBA II_CIA2

method appears effective and with the additional tools we have learned about on how to discover
when the project is eating into the buffer, it appears even more suitable.
What I also found very interesting was the teaching method of professor Silver in the book.
This discussion forum appealed to us; in the way he was able to include his students into the
lecture. So we can say that this type of teaching methodology can be much more effective than
current pattern and will be more beneficial for all categories of the student.

Page 6 of 17
CUIM_MBAI_QBA II_CIA2

TECHNICAL SUMMARY/REVIEW OF THE BOOK

Prerequisite 1 - Identify the System and its Purpose


Identify the System
As defined in Webster’s New Collegiate Dictionary, a system is “a regularly interacting or
interdependent group of items forming a unified whole”. By definition a project is a set of
interacting and/or interdependent tasks that must be completed according to specific parameters
(e.g. time, budget, etc.) and by the appropriate resources in order to generate the desired result.
Therefore, a project is a system. And with further analysis, it is concluded that a project is a system
that operates and interacts within a larger system. For example, projects (e.g. software,
engineering, new product development, etc.) are being planned and implemented within larger
business systems (e.g. a manufacturing company, software development company, drug producing
company, etc.) everyday.
Define the System’s Purpose
Since a project is a system operating within a larger system, then the purpose of the larger system
needs to be defined before defining the purpose of the project. According to
Stephen Covey, the purpose of a business system (as opposed to non-business systems, such as
churches, fire/police departments, etc.) is “to improve the financial well being and quality of life of
all stakeholders”. A business system with the above purpose will be used as an example of a larger
system, but the concepts outlined in the remainder of the document can be applied to non-business
systems as well.
Now that the purpose for the larger business system has been defined, the purpose of the project
system can be defined.
In the graph below the solid line shows the typical sales cycle of a product, the dashed line
represents the point in which sales would begin if the product were introduced earlier. As this chart
shows, the earlier a product is introduced the sooner and potentially longer you can reap the
benefits of selling that product.

Page 7 of 17
CUIM_MBAI_QBA II_CIA2

Y- Axis money. X-axis- Time

Based on this, it can be concluded that a project contributes to the larger system’s purpose by
completing as early as possible. By combining the key element of project lead time and the stated
purpose of the larger business system, the purpose of a project (in a business system) is to
complete as early as possible so that the financial well being and quality of life of all the
stakeholders is improved quicker.

Prerequisite 2 - Determine the System’s Measures


Based on the purpose of a project, the method for measuring the success of the project should be
based primarily on the ability of the team to meet or beat the schedule (i.e. the sooner completed
the better for all the stakeholders). This is not meant to imply that the cost is not important, but it
does mean that any decisions in spending should be based on the amount of incremental Net Profit
(NP) improvement that would be generated by finishing earlier versus the incremental increase in
Investment (I) required to make that happen (ROI = NP/I).
This method for measuring is in contrast to the more traditional method of measuring a project’s
success according to the team’s ability to manage cost first and time second.

Page 8 of 17
CUIM_MBAI_QBA II_CIA2

Step 1 - Identify the System’s Constraint


A constraint is anything that limits the system from realizing a higher performance relative to the
system’s purpose. Because time is the primary attribute of meeting the purpose of a project (“…
complete as early as possible…improved quicker”), then we must determine what are the tasks
and/or resources that determine when is the earliest a project can complete.
It is widely accepted that the critical path of a project is the longest chain, in terms of time, of
dependent steps. So, if time is the primary measure of a project and the critical path is the longest
chain, in terms of time, of dependent steps, then the constraint of a project is the critical path/s.
The only problem with this conclusion is that there maybe multiple tasks on various non critical
paths which are required to be completed by the same resource. Realistically this resource will
work on these various tasks in one of the two following manners - · at different times until all tasks
are complete (also known as multitasking, which is addressed in the subordination step of this
process), or in some specified sequence (typically of his/her own choosing), thereby completing a
task prior to starting another.
In either case, the longest chain, in terms of time, of dependent steps may not be the critical path.
Therefore dependencies between steps can be a result of a path and/or a common resource. Since
the dependencies between steps are not necessarily a result of a path, then the constraint of a
project is not necessarily the critical path. Therefore the constraint of a project is the longest chain,
in terms of time, of dependent steps (where the dependencies are a result of paths and/or common
resources). Goldratt states this as the definition for critical chain

Step 2 - Decide how to exploit the System’s Constraint


Since the critical chain is the constraint of a project, any time lost on the critical chain is lost
forever. As a result the project will complete later than expected and the stakeholders will not reap
the benefits as quickly as possible. In contrast, any time gained on the critical chain will improve
the chances of the project completing early and the stakeholders will reap the benefits quicker.
Therefore, it is imperative to do everything you can to minimize any lost time on the critical chain,
and take advantage of any gains in time on the critical chain, i.e. exploit the system’s constraint
before defining solutions to minimize impact of lost time on the critical chain and take advantage
of time gained on the critical chain, it would be helpful to understood how projects are
traditionally scheduled and executed. Generally a project manager and team identify the tasks to be
completed and the expected time to complete each task. Then they add up the times on each path,

Page 9 of 17
CUIM_MBAI_QBA II_CIA2

identify the critical path, and add the critical path time to the expected start date to determine the
expected complete date.
The problem begins with the determination of expected time for completing each task.
Each resource is typically asked to define how long it will take to complete their specified task/s.
The resource estimates the time based on his/her last bad experience, thereby injecting safety time
to insure completing the task/s on time. If a particular resource’s boss is responsible for several
tasks, this boss will inject another level of safety to insure the task/s will complete on time based
on his/her last bad experience. After all the expected task completion times are collected by the
project team, then they inflate the estimates by another factor. The reason for this is that it is their
experience that management will cut the overall project lead time by a similar factor, so the
projects will be scheduled to complete sooner. It appears that the higher the uncertainty of anyone
making the estimates the larger the safety time factor. It is speculated that the typical project lead
time includes about 200% safety time (i.e. a project scheduled for 300 days, has about 200 days
safety time estimated).
There are two issues here - first, why do projects still run late using this process, and second, isn’t
this methodology (of adding as much as 200% safety) counter to the purpose of the project?.

Why do projects still run late with all that safety?

The answer is that the safety is wasted. There are three mechanisms for wasting safety:
1. The student syndrome - waiting till the last minute to start because the resource knows he/she
has plenty of time due to all the safety he/she included
2. Multitasking - a resource has several tasks for various projects to complete and attempts to work
on them simultaneously, thereby increasing the lead time for a specific task by the amount he/she
is working on other task; this also requires many “set-ups” (i.e. putting down one task and then
picking up another, remembering where you were and what you were doing)
3. Dependencies between steps - delays accumulate faster over time than the advances; delays are
frequent because of Murphy and the effects of the first two mechanisms, but advances are not
taken advantage of because of built in safety in each task in combination with the behaviours in
mechanisms 1 and 2.

Page 10 of 17
CUIM_MBAI_QBA II_CIA2

Isn’t this traditional methodology counter to the purpose of a project?


The answer is yes; because as shown in the answer to first question, the safety and advances are
wasted, thereby guaranteeing the project will finish either on time late (if “all goes well”), or late.
The primary cause of this behaviour is rooted in how resources are measured. Each resource is
measured according to his/her ability to complete their task on budget and in the time scheduled
(i.e. local optima) versus being measured on the project being finished on time or early (i.e. the
purpose).

Project and Feeding Buffers


In order to exploit the critical chain according to the purpose
1. Strip out from each task time a large percentage of the safety time.
The task time should be reduced to a level where the resource has a 50% chance of
completing on time versus 100% chance of completing on time (as traditionally done). As a
result, the traditional methodology for measuring an individual resource according to their
ability to finish their task in the allotted time (a local optimum measurement) is no longer
valid. A more global measurement system should be used to encourage the behaviour of
individual resources to be more focused on completing the project early or on time (the
purpose of the project). This reduction in task times minimizes the impact of the student
syndrome (i.e. resources have less time to complete their specific tasks, therefore they will
not wait as long to start), thereby reducing the opportunity to waste safety time.
2. Sum the individual safety times on the critical chain and each non-critical chain, reduce the
accumulated safety times of each chain by some factor, and locate these new safety times at the
end of the critical chain and anyplace where the non-critical chains meet the critical chain
· The safety time on the end of the critical chain is called the project buffer (this buffer is
analogous to the shipping buffer in manufacturing Drum- Buffer-Rope implementations). The
project buffer protects the project scheduled completion date from Murphy events on the critical
chain (and non-critical chains where the feeding buffer is used up and causing time to be lost on
the critical chain, feeding buffer is defined in next bullet). By locating the safety time of the
critical chain in one location, the safety time will not be wasted by any specific task that plans for
it but doesn’t use it. · The safety times located where non-critical chains meet the critical chain are
called feeding buffers (these buffers are analogous to constraint and assembly buffers in
manufacturing Drum-Buffer-Rope implementations).The feeding buffers protects the critical chain
from the impact of Murphy on non critical chains.

Page 11 of 17
CUIM_MBAI_QBA II_CIA2

Step 3 - Subordinate everything else to above decision/s

The next step in this process is to subordinate all other activities (decisions, policies, etc.) to the
maintaining and/or improving of the critical chain schedule (i.e. completing the project on time or
early by minimizing the impact of Murphy and taking advantage of gains on the critical chain).
The Golden Rule of Subordination

In order to take advantage of gains made on the critical chain, institute the following rule for
project execution: When a task completes on the critical chain (and non-critical chains, if the
decision does not affect the critical chain), begin the next task as soon as possible.
By adhering to this rule, gains made on the critical chain will not be lost because of the student
syndrome. This will then improve the project’s ability to finish earlier (the purpose), and reduce
even more the potential effects of Murphy occurring in a following critical chain tasks. Gains on
non-critical chains decrease the possibility of non-critical chain Murphy events impacting the
critical chain.
Resource Contention and Resource Buffers

Another issue that can cause a loss of time on the critical chain is resource contention.
Resource contention occurs when everything is ready for a task to be started but the appropriate
resource is working on something else, thereby causing a delay in starting and finishing the task.
In the event of this possibility, locate safety time prior to the tasks this resource is responsible. The
safety time should be large enough to insure the resource has at least a 50% chance of finishing the
specific tasks on time. This safety time is called a resource buffer. A schedule should be created
prioritising the tasks (the tasks included may be on the critical or non-critical chains of various
projects) expected to be in that resource buffer according to the following priority -
Critical chain tasks.
hese tasks should be sorted according to the scheduled project completion dates
asks that are dependent on each other must be sequenced as they are in the project plan
Non-critical chain tasks

Page 12 of 17
CUIM_MBAI_QBA II_CIA2

Each task on the schedule should be completed prior to beginning the next scheduled task (see
exploitation step for discussion of multitasking and its contribution to wasting safety time). In
doing this he problem of multitasking will be resolved.
The project team should frequently notify the resource of the progress of the scheduled tasks, so
that the resource will be prepared when the tasks are available to be started. This notification
should begin no later than the scheduled start date of the resource buffer. The resource can
continue to work on other tasks until the scheduled task appears at which time the resource
immediately starts the scheduled task and completes it before continuing to perform other work.
Now that there is an executable project plan in accordance with the purpose, a methodology to
monitor the project and identify problems which may impact completing the project as planned
must be developed.

Step 4: Elevate the System’s Constraint


The next step in the process is to elevate the constraint, i.e. reduce the length of the critical chain.
Remember that the critical chain is defined as the longest chain, in terms of time, of dependent
steps (where the dependencies are a result of path/s and/or common resource/s). Based on this
definition, you can reduce the time on the critical chain by either reducing the number of
dependent tasks, reducing the time to perform specific tasks, and/or reducing the number
dependencies caused by common resources.
Any opportunity for improvement should be tested using the ROI calculation. Compare the
expected incremental improvement in Net Profit versus the incremental investment required to get
that improvement in Net Profit. For companies who are project dependent, this approach should
take into consideration the impact of this investment not only on the short term of a specific
project or projects but over many future projects (e.g. should you hire additional resources or
utilize subcontractors, make large technology investments or rent, out source or train, etc.). For
companies who are not project dependent, this approach would take into consideration the impact
the investment had on the rare project (e.g. should you contract consultants to manage an ERP
Software System implementation project, out source some/all of the project’s tasks to
subcontractors, etc.).

Reduce the number of dependent tasks

Page 13 of 17
CUIM_MBAI_QBA II_CIA2

It would be expected that every task on any chain or path are necessary to the successful
completion of a project. But, a review of the critical chain tasks may provide opportunities for
eliminating tasks either because they are no longer valid or through some technological advance,
thereby reducing the critical chain of a specific project or projects and/or future projects.
Reduce the time to perform tasks
Assuming that the tasks are necessary, review common critical chain tasks, identify the reasons for
the amount of time required to complete, and implement the appropriate solutions. The solutions
may include technology improvements, policy changes, training, etc..
Reduce number of dependencies caused by common resources
To reduce the number of dependencies caused by common resources, make more available to
perform the tasks. Options to increase the resources available to perform these particular tasks
include - hiring, cross training, and/or outsourcing to subcontractors. Any combination of these
options applied appropriately may reduce the time required on the critical chain.

Step 5: Do not allow Inertia to become the system’s constraint. If in the


previous steps the constraint is broken, go back to Step 1.
Elevating the constraint during an active project could cause the critical chain to move. It is
important to be careful to consider the following: · incremental improvement in Net profit versus
the incremental Investment required to get that profit (ROI = NP/I) · ability of the new non-critical
chain tasks and resources to subordinate to the new critical chain · risks associated with disrupting
the project
If after elevating the critical chain moves, return to step one and follow the process. Be sure a
critical chain is not made longer because of invalid policies, rules or assumptions. If the constraint
is not broken and a satisfactory project plan is developed, implement the plan. As the plan is
executing, utilize the various rules (such as starting tasks on critical chain as soon as possible and
no multitasking), measurements (emphasis on time and overall project completion versus cost and
individual task completion), and buffer management techniques to manage the project.
In the case where elevation is directed at future projects (especially companies who are project
dependent), it must be emphasized - be sure future critical chains are not made longer because of
invalid policies, rules or assumptions.

Page 14 of 17
CUIM_MBAI_QBA II_CIA2

Conclusions
As a summary of my impression I will say that it was fun to read, it covered and explained the
topics in an elegant manner and it was inspiring for future work and also future reading of the
books by Goldratt.
"This book is valuable to two main audiences: project managers and senior managers...useful for
dealing with one of the most difficult and pressing management challenges: developing highly
innovated new products." "Eli Goldratt's first novel, The Goal, shook up the factory
floor...Goldratt essentially adds a discipline for understanding what drives project performance and
therefore what the focus of a project manager's attention should be." —Harvard Business Review

Page 15 of 17
CUIM_MBAI_QBA II_CIA2

BIBLIOGRAPHY

 http://www.goldratt.com/khxc/index.php?
app=ccp0&ns=prodshow&ref=CC&sid=kb8u78g8l99j480n5a9q1hb088paz58l
 http://www.jstor.org/stable/3009987?
&Search=yes&term=critical&term=chain&term=goldratt&list=hide&searchUri=/action/doBasicSea
rch%3FQuery%3Dcritical%2Bchain%2Bby%2Bgoldratt%26gw%3Djtx%26acc%3Don%26prq
%3Dcritical%2Bchain%26hp%3D25%26wc
%3Don&item=2&ttl=28&returnArticleService=showFullText
 http://www.scribd.com/doc/36933684/North-River-Press-Critical-Chain
 http://khup.com/keyword/critical-chain-book-by-goldratt.html
 http://www.studytemple.com/forum/project-management-org-behaviour/774-critical-chain-
business-novel-eliyahu-m-goldratt.html
 36933684-North-River-Press-Critical-Chain-1997-ISBN0884271536.

Page 16 of 17
CUIM_MBAI_QBA II_CIA2

Page 17 of 17

You might also like