|
A Guide to Implementing the Theory of Constraints
(TOC) |
|||||
|
Multi-Project Drums |
|
|
|
Introduction This
page contains some of the “pointers” needed to turn the knowledge in the
preceding pages on Critical Chain Project Management into something that will
produce both action and significant results for a particular case. As you know, people write books on just
this aspect and it is not the intent here to provide yet another. But there are a number of small things,
often very small things, that people who are not so familiar with Theory of
Constraints might find value in.
Things that we might otherwise do that we shouldn’t do, and things
that we might otherwise not do that we should do. It is one of those interesting things in
life to see a “new” approach such as critical chain applied in an “old”
environment with many of the old assumptions and reactions – many of which
are so automatic that we don’t even think about them – and then to hear that
the new approach isn’t working. It’s
not the new approach that is at fault, it is the old thinking of the old
environment. We need to watch for this
constantly. Well, I
don’t know about the good, but I’ve seen a bit of the bad and the just plain
ugly. There are many companies who see
themselves as generalized producers rather than “project” companies. They make things with long touch times, for
example tangible manufacturing or near-intangible software, and yet have
little explicit project management of their operation. Companies that build one-offs, either to a
standard design or customized, tend to use the “last one like that” to
estimate effort in “the next one” and set start and finish dates around
that. They then launch the new project
into the system without due regard to the loading on the system because “the
customer is waiting and every day is a day lost to him.” And so it goes. Where
there is some logistical control, oddly, it seems to be as a material
resource planning system (MRP). I say
oddly, because such systems depend upon queuing for their functionality and
as we know there are no explicit queues in projects. Oddly too, because such companies may see
the age of their MRP system as the cause of their problems and embark on
expensive and time consuming upgrades to let them know more quickly how fast
they are losing money. They have
addressed an effect rather than the underlying cause. Maybe people use MRP systems because they do know
how damn difficult it is to organize anything around one of the Critical Path
Method (CPM) software approaches, a difficulty brought about by the close
coupled dependencies (tasks) and localized safety. Replacing
MRP with Critical Chain Project Management is a fundamental step
forward. There is a fine example of
this from the United States Marine Corps that you can download (1). We need
to move from the bad to the good. In
order to do so, we must do things that currently we do not do. We now know the logistical direction of the
solution and most of the detail – Critical Chain. Here, let’s examine a few more of the
important implementation details, some of the things that other people might
forget to tell us about. Many
manufacturing/service projects that are to some extent repetitive – the same
or similar type of thing is produced each time – have sort of “evolved.” Often no one has ever sat down and asked the critical question about what needs to
be done and when, and which parts must
be done in sequence and which parts can
be done in parallel. People are far
more likely to do this for “unique” projects or very large projects, but when
we have a significant number of apparently simple and mundane or repetitive
projects we often don’t do it at all.
Of course if we sit down and redo this plan from scratch, then once it
is done, we may not need to revisit it again; we have a template, but it will
be a vastly improved template compared to the one that we previously carried
around in our heads. We need
to sit down and take a long hard look at devising the minimal PERT chart that
we need to implement the project.
Something like this.
Using a
pre-requisite tree approach it is possible to build the logic needed for the PERT
diagram. If we do so, then the
following will occur;
Tasks that
are not true predecessors will be resolved out of the critical chain into
parallel feeding chains where they belong.
The overall length of the Critical Chain is therefore reduced before
we even start. This is already a
significant competitive advantage. Don’t
fall into the trap of providing sufficiency, that is, breaking the basic
tasks down into further detail. The
people who are directly involved know what is required. A common enough problem once a proper project plan has
been produced is to try and resource it fully. Once again, we don’t need to do this. We only need to resource the tasks that we have to. These are tasks where structural or
resource dependency may mean we overload a resource for a time, or where there
is a resource or a group of resources who might, if not well managed,
constitute an internal constraint. Recent work by Ricketts (3), especially the concept
of resource management and resource buffering in service-type operations,
including projects, is important and deserves widespread understanding. It is a significant move forward in Theory
of Constraints knowledge. Reducing
multi-tasking in projects is akin to reducing work-in-process in
manufacturing operations. Although in manufacturing
operations we certainly can increase the output of the constraint
independently of the work-in-process, at least in the short term, ultimately
failure to reduce work-in-process, and thus manufacturing lead time, will
cause such an implementation to stagnate far short of its real potential, or
more likely it will cause the implementation to fail. In
project operations we too can increase the output of the constraint, time, by
reducing the critical chain, but not independently of the work-in-process in
multi-projects. Because the touch time
is so much higher in project operations compared to production operations we
can’t even implement Critical Chain Project Management unless we reduce
multi-tasking. Although
I have tried to keep things simple and focus on single project
implementations, the real world almost always forces multi-project conditions
upon us – even if it is a single project – by virtue of “other things” that
must be done, as well as the project.
And if you think avoiding multi-project is a cop-out, then just
consider how many Critical Path Method explanations don’t even go near
multi-project. There
are two aspects to multi-tasking.
Goldratt makes them explicit (4, 5) but my experience is that people
confuse the two issues almost immediately. 1.
In any multi-tasking multi-project environment there
is a proportionate increase in individual project elapsed time with
increase in total number of projects.
Simply stated, double the number of open projects, double the length
of any individual project. 2.
Lack of a clear priority system between projects and
tasks in a multi-tasking multi-project environment means that there is a disproportionate
increase in elapsed time with the increase in total number of projects. Double the number of open projects and the
length of any individual project will more than double. The
consequence of this disproportionate increase in duration is that the
reduction in touch time for any one project in such a multi-tasking
multi-project environment will be much greater than the 25% reduction in
touch time that we can obtain for a single project in a single project
environment. Why is
this? Most people ascribe it to “complexity.”
But that is akin to saying “we don’t really know.” The disproportionate
increase arises from the added uncertainty caused by what Goldratt terms
“bad-multi-tasking.” Bad-multi-tasking results from a lack
of clear priority in multi-project environments (6). As we said on the page on project buffers,
people are very good at estimating the impact of uncertainty of resource
availability and will build additional safety into the touch time estimate to
compensate for this (and then we go and waste it for all the mechanistic and
psychological reasons that we dealt with on the same page). We saw
the priority rules to avoid this situation in the buffer status section of
the previous page. In fact without
buffer management this would be impossible to achieve. This is why Critical Path Method is careful
to avoid addressing multi-project environments where there is resource
commonality between projects. So
let’s now look at how to reduce multi-tasking in the simplest case assuming
for the moment that there is no confounding caused by lack of clear priority
signals amongst the various tasks and projects. The
surest way to improve the flow of work through production operations is to
reduce the amount of work-in-process.
Really we are taking away the unnecessary waiting from the process –
or unnecessary delay while waiting. We
have no choice but to reduce the number of open projects on the books. The
first thing that has to be done is to stop new projects from entering. Stopping new projects from entering the system
has manifestly positive results.
However, despite the logic, it is not within people’s experience to
have projects taking a shorter duration. The
second thing to do is to help “flush” existing projects out the door by
concentrating more upon those that are closest to completion. Concentrating on projects in such a way
will cause them to finish sooner and clear the number of existing projects
faster – so we can continue to admit new projects sooner. Goldratt
suggests freezing half of the open projects (4, 5). Let’s investigate this in detail.
However,
we are going to stop all new projects from entering and freeze half of the
current projects. Projects 3, 4, 5,
& 6 will continue to be worked upon while projects 7, 8, 9, & 10 will
be frozen. Let’s
see how this looks.
Note
that the 4 current projects will all be completed in less than their original
estimate. This is because the
resources assigned to multi-task on the frozen projects are free to
concentrate on the remaining current projects. The current projects will take half the
time to complete the remaining work because twice as much effort is being
expended upon them. The
same logic applies in the future to the 4 frozen projects. We can taken this into account
already. Project 10 which was due to
start the period that we imposed the freeze will take half of the original
time to complete. Any new projects
will also be scheduled for the same duration – because by the time that they
start there will be only half the work-in-process present and therefore twice
as much effort can be expended upon them. Projects
7, 8, 9, & 10 are off-set from the period that they “froze” until the
period that they are scheduled to be unfrozen. Let’s
have a look at the next period.
Let’s
look out a period
Let’s
step out a period.
Let’s
see what happens.
What
happens in the next period?
Next
period.
We have
successfully transitioned from 8 projects open at the same time to 4 projects
open at the same time. Projects that
use to take 16 periods to complete now take 8 periods to complete. We achieved this by freezing half the open
projects, then unfreezing and maintaining the level of “work-in-process.” Well a
caveat or two. I know real life does
not present boringly uniform projects, but without showing the mechanics is
such a boring way, I don’t know how otherwise to get the message across. Regardless the principle remains the
same. And note that we did make an
assumption that staff are sufficiently resourceful that they could always
find work of the type for which they are suited even when half the projects
were frozen. In the
simple case above, the duration for a single project has halved from 16
periods to 8 periods. The total effort
however remains unchanged. Before we had 0.5 effort by 1 lot of 8
projects of 16 periods = 64 units After we have 1.0 effort 2 lots of 4 projects
of 8 periods = 64 units All we
did was take out the gaps caused by our multi-tasking slice and dice that we addressed on the previous page. The touch time remains unchanged! Now the important part. If we
approached such a multi-tasking multi-project environment with the assumption
that implementing Critical Chain Project Management would yield a reduction
in touch time of 25%, we would be right.
But we would also be wrong and not know about it. The potential reduction is much greater (4,
5). We have
assumed in our simple model some sort of perfect multi-tasking where resources
can flip effortlessly between different tasks. And we have assumed that we have
some sort of knowledge of which tasks to flip to and when. Reality is vastly different. As we have already noted, Goldratt coined
the term bad-multi-tasking to describe the current (CPM) situation where
there is no clear priorities of which tasks we should flip to and when. The consequence is that multi-tasking chews
up touch time when chopping and changing between jobs by not having the right
resources available on the right jobs at the right time. If a
single project can be implemented in 75% of the time by addressing the
mechanistic aspects of resource and structural dependencies as well as the
psychological aspects of procrastination, then the benefits of addressing the
same issues over multiple projects is much greater. We have the priority rules from buffer
status to guide us. Reductions of 50%
of the touch time rather than 75% of the touch time are in order. The Marine Corps example (1) shows a
reduction in cycle time (duration) to 1/3rd of initial and an increase in
output rate of 100% (= 50% reduction in touch time). People
can and do make accurate allowances for resource non-instant availability in
current multi-projects environments.
With buffer status we can largely negate this confounding issue. There
is a challenging notion to install in people-led project management, and that
is that in the absence of an internal drum, all personnel should have
unassigned capacity. Even in the
presence of a drum, only the drum has fully assigned capacity, everyone else
still has unassigned capacity. In most
project organizations project personal tend to be “bread-winners” and are
expected to be on project work most of the time, and as most project
organizations like to account for their costs this is reinforced by time
sheet form filling. We tend to find
people who are expected to be busy will in fact support that with their time
sheet billing. The time sheets at as a
“chock” that reinforces some of the psychological factors that we examined on
the page on project buffers, and which cause safety to be wasted. Let’s
look at this another way. You can have
100% resource utilization and your current profitability or you can have
considerably more profitability and not know your resource utilization. How much more profit? Take your annual throughput (revenue less
any 1:1 totally variable costs such as project specific consumables) and
subtract your operating expenses (all the unavoidable period expenses such as
staff, rent, and so forth). The
remainder is your operating profit.
Now take a quarter of your annual throughput and add that to your
annual operating profit, this is your new operating profit. It is substantially increased because you
don’t pay for your operating expenses twice . Now
let’s ask ourselves again, do we want to know how every minute of every day
is spent and have last years operating profit again, or do we want to do
something different instead? Measure your projects not your people! And
by-the-way, how do we measure projects?
Buffers status of course. Now
at least we can understand why time sheets were so important in the past. They were a proxy for project control. We
presented one approach to buffer status on the Critical Chain page although
we did not subdivide the buffer into zones.
In the production operations application, drum-buffer-rope, the buffer
is divided into three zones. Working
out from the “thing” that we want to protect, the delivery date, the latest
zone, zone 1, is called the red zone.
The next zone, zone 2, is called the yellow zone, and the earliest
zone, zone 3, is called the green zone.
We can also do this for our critical chain plan. Let’s have a look.
Goldratt
is emphatic that whatever the task size, the buffer should be equal to half
the lead time of the unbuffered but trimmed plan or 1/3rd of the whole but
trimmed plan (4, 5). It doesn’t take too
long to recognize why such a generalized rule should be used. People when first faced with the concepts
of Critical Chain Project Management are quite likely to decide that some
individual tasks are well known and that others are not, therefore they will
argue that the safety in each is different.
You may have to see this to believe it, you may not do it yourself,
but everyone else does. We are
then about 2 seconds away from an infinite and un-resolvable discussion as to
the “appropriate” level of buffering in each (and therefore every) task. I view this as a stalling tactic. It can stall the process dead; maybe that
is the true intent. In seeking to
simplify the dynamic complexity of project management some are only too
willing to dive into the underlying detail complexity from which they will
fail to surface. Having
said that, there are a number of other approaches that do recognize that
different tasks have different levels of safety; two of which warrant
mention. The first of these belong to
the “quants.” Newbold (7) and Leach
(8) both give numeric solutions to task sizing. This approach is also available as a choice
in a number of the Critical Chain Project Management software packages. It avoids the detail complexity
hair-splitting by applying one rule – albeit a numeric rule – to all tasks in
the plan. Just because it is numerical
does not mean that it is more accurate or more precise, it is just another
way to skin a cat. The
diametrically opposite approach is that of Buckridge (9). For each major task ask for two task
estimates. The first estimate is for
the case where everything goes “swimmingly well,” the second estimate is for
the case where “things turn to custard.”
The first estimate becomes the task estimate and the difference between
the two yields the safety for each task and is aggregated into the respective
buffers (but is not reduced at all).
Such an approach will still have oodles of safety embedded within it,
but at least it will be completed on time.
This is an approach best reserved for recalcitrant players. It is a first step to building trust in
critical chain so that more realistic buffering can be established in the
future. Previously
on the page on Leadership and Learning we discussed the reality of
unintentional punishment of positive actions and the unintentional reward of
negative actions. We discussed this in
light of the changes brought about by implementing drum-buffer-rope, the
production operations logistical solution.
Basically this is a clash of the old with the new, the conundrum being
that it is driven by the best of intents.
There is a way out of this conundrum, it requires restraint on the
behalf of managers more than anything else.
Let’s investigate this a little more for project operations. On the
Critical Chain page we used the words, “incorrect” and “correct” behavior,
this may sound very deterministic, however, that is not the intent. Let’s look first and the unintended reward
of incorrect behavior in project environments. We spent a great deal of time (a whole
webpage) discussing buffering in project environments. One of the key findings was that not only
are there mechanistic factors operating, such as task and resource
dependencies, but also psychological factors operating in positive response
to our working environment – the need to start tasks late and the need to
finish tasks late. In most
environments there is also multi-tasking going on, either between different
projects or between project and non-project work. Even if the environment is changed
tomorrow, the feelings will still linger, that is the behaviour will still
linger. Individuals
or groups assigned to a task who have fallen behind, will, based upon
previous experience, expect management to step in and provide more resources
– or more time. Managers, based upon
previous experience, may respond by doing exactly what is expected of
them. This, after all, is how it
always worked before. However, doing
so after beginning to use Critical Chain Project Management will have a
negative consequence unless it can be shown by buffer management that
absence of such a response will endanger the whole project. In other words we have to move past
reacting to squeaky wheels. Rewarding
such actions will only cause such circumstances to continue. Failing to reward such actions will cause
those involved to look for ways – solutions – to their own problems rather
than receive additional help. If we
don’t do that we will short-circuit any process of on-going improvement. In fact we doubly short-circuit it because
those that have done the correct behaviour will feel demotivated. What then of the opposite case; punishing correct
behaviour? Individuals or groups assigned
to a task who have finished early, will, based upon previous experience,
expect to pad the job out. Sure, in
the past people have been reassigned, but usually from one late task to
another even later task. Making honest
task estimates and finishing early – that is with buffer capacity to spare,
puts these people “at risk” of reassignment.
Managers doing their best might well be reluctant to leave people
“sitting” “unproductively,” but that is exactly what we should do unless
buffer status tells us to do otherwise.
Punishing prompt completion by reassigning people will only cause the
old circumstances to continue. Not
punishing such actions will begin to reinforce to everyone that fundamental
changes are afoot. The exception to
this (apart from when buffer status tells us that we must do something) is if the people concerned make the
offer. That is, if people who have
time on their hands make the offer, then it should be accepted. They won’t do this unless they believe the
cause is real. It may not happen the
first time, but it will happen. We can
be proactive due to our buffer feedback, we don’t need to be reactive anymore
– but old habits are sometimes hard to break.
These are powerful and interrelated reinforcing actions. The unintentional punishment causes a
positive action to cease and is very difficult to restart; the unintentional
reward causes a negative action to carry on and is very difficult to stop. We need to be
seen to be managing. And managing
usually means taking action. We will
find that quite often in this new environment managing will mean not taking
an action. Goldratt quite rightly points out that many project
management organizations operate as “matrix organizations,” organizations in
which managerial authority (but not responsibility) is vested in the
personnel’s technical or substantive “resource” manager while responsibility
(but not authority) for project delivery is vested in a separate project
manager. The project manager being
devoid of the authority to man the project. This creates a perfect dichotomy where project
delivery responsibility and authority are misaligned. The solution to the problem, for which
Critical Chain Project Management then “rides to the rescue,” is to use
buffer management to address the real priorities between conflicting project
managers, resource managers, and the very people – the resources – who are
caught in the middle. Of course, this
is in the context of proper staggering of individual project plans and the
consequent reduction in reactionary multi-tasking. People are well aware, also, that matrix
organizations aren’t the preserve of large firms, even small “boutique”
professional firms seem able to create considerable havoc with as few as a couple
of handfuls of staff (“I can’t come over to talk to you, I am too busy
sending you an e-mail”). As nice as the buffer management solution is to this
problem, it only addresses a symptom.
And we should know much better than that, should we not? Therefore, what about the core problem of
two managers with different or divided responsibility? There is a solution to this. Let’s have a look. Elliott Jaques began studying real living industry
in the form of the Glacier Metal Company in 1947 and continued through to
1977. Single industry longitudinal
studies such as this a very rare but also very rich in their returns. One consequence of the Glacier study was to
formulate an understanding of matrix organization that seems unrivalled
elsewhere. Jaques argues that the real
question is not who resources are accountable to, but rather who is
held accountable for their work (10, 11). “A matrix of people cannot be held
accountable for giving vigorous and creative leadership to anyone. The resulting loss of incisiveness is
grievous.” Project teams are in Jaques language, “attached
subordinate teams,” the resource manager is the home-base manager, the
project manager is the borrowing manager, and the team member is the
subordinate. The borrowing manager
must respect the home-base manager-subordinate relationship, but can; §
Assign tasks
to the team member §
Review and
coach with respect to those tasks §
Report on the
team members effectiveness to the home-base manager for merit review §
Initiate
termination from the team before the stipulated time has elapsed. Where the subordinate is attached temporarily, as on
an ad hoc project team, the home-base manager decides the subordinates merit
review, taking the borrowing manager’s appraisal into account. Its hard to do justice in a paragraph or two on just
one aspect; there is much more. The
material is significant, accessible, and available; it is well worth
investigating if you want to address the core issues of requisite authority
in requisite organizations. Most
organizations are both non-systemic and non-requisite. Having a matrix organization seems more like an
excuse than a solution, however, buffer management and reduced multi-tasking
has been shown to make such organizations significantly easier to manage. Few people seem to venture into the work of Jaques,
although there are exceptions (12, 13), and we are all the poorer for
it. This might simply indicate a lack
of “requisite leadership.” Critical Chain Project Management presents us with
an opportunity to plan projects well for maybe the very first time. We should make sure that we break with our
old traditions of how we have done things in the past and re-plan our
projects from scratch. But planning is
only half the story. The real power of
Critical Chain Project Management comes from the control afforded during the
execution or deployment of the job.
Buffer status and buffer management allows us unprecedented feedback
on the progress of the project and where to focus attention and where
not. And maybe this is the most
important factor in the whole approach.
We have a totally new and systemic way to manage projects. We should make the very most of this
opportunity. (1) Srinivasan, M., Jones,
D., and Miller, A., (2004) Applying Theory of Constraints principles and Lean
Thinking at the Marine Corps maintenance center. Defense Acquisition Review Journal Aug-Nov, pp 134-135. (2) Dettmer, H. W., (2003) Strategic navigation: a systems
approach to business strategy. ASQ
Quality Press, pg 190. (3) Ricketts, J. A., (2008) Reaching the goal:
how managers improve a services business using Goldratt’s Theory of
Constraints. IBM Press, pp 67-89. (4) Goldratt, E. M., (2002) TOC on project
management and engineering: a self learning program. Goldratt’s Marketing Group (video-based
tutorial). (5) Goldratt,
E. M., (2003-2006) TOC insights into project management and engineering. Goldratt’s Marketing Group (software-based
tutorial). (6) Goldratt, E. M., (1998) Project Management the
TOC Way. Avraham Y. Goldratt Institute
Limited, pg 37 onwards. (7) Newbold, R. C., (1998) Project management in the
fast lane: applying the Theory of Constraints. St. Lucie Press, pg 95. (8) Leach, L.P., (2000) Critical chain project
management. Artech House Inc., pp
167-168. (9) Buckridge, K., (2006) personal communication. (10) Jaques, E., (2006) Requisite organization: a
total system for effective managerial organization and managerial leadership
for the 21st century – revised second edition memorial. Cason Hall & Co., page pairs 83, 84,
& 98. (11)
Jaques, E., and Clement, S D., (1991) Executive leadership: a practical guide
to managing complexity. Cason Hall
& Co., pp 107-108 & 233 - 239. (12) H. W. Dettmer (2007) The logical
thinking process: a systems approach to complex problem solving. American Society for Quality, pg 322. (13) This Webpage Copyright © 2008 -
2009 by Dr K. J. Youngman |
