So before I begin this posting, let’s do a process check on what we
learned on my last posting. We learned
that task time estimates for tasks are artificially lengthened as a protective
measure against Murphy and all of the negative baggage he brings to the party. We also learned that even though this safety
is built in, it is wasted many times because of two behaviors, the Student
Syndrome and Parkinson’s Law. With the
Student Syndrome we put off work until the last minute (we procrastinate),
while Parkinson’s Law says that if we’re given ten days to complete a task,
that’s how long it will take, even if it is completed earlier. We also learned
that delays are passed on while early finishes are not. Finally we’ve learned how devastating bad
multitasking can be to the completion rate of projects and if we could
eliminate it, we know our on-time completion rates would improve. Although eliminating bad multitasking
improves our on-time completion rate, are there other things that can be done
to improve these rates even more? Let’s
take a look.
As we’ve just discussed, in CPM we know that
our task durations are inflated so that we can protect our projects against the
negative effects of Murphy. The question
becomes one of, what if we could significantly reduce these built-in safety
times and still be able to provide the project protection that we need? In our example from Figure 1 in my last
posting, suppose we were able to reduce the estimated duration by 50 % and
still protect against Murphy? In other
words, if we could complete the tasks in 5 days instead of 10 days, wouldn’t
this be a quantum leap in project completion time reduction? Figure 1 depicts this 50% reduction in
durations of each project. We have just
reduced the time to complete these three projects from 30 days to 15 days, but
can we realistically do this and still guard against the uncertainty that
Murphy brings to the table? The answer
is yes we can!
Figure 1
We’ll
come back to this figure and explain how we can reduce our estimates by 50% and
still meet the new project end dates, but remember we still have to deal with
the Student Syndrome, Parkinson’s Law plus bad multitasking. Before we explain how to counter these
behaviors, let’s talk about (or re-introduce to some of you) the Theory of
Constraints (TOC).
TOC
came on the scene in the mid-1980’s through the late, Dr. Eli Goldratt the man who
conceived it. Goldratt explained that no
matter what the system is, it will have a constraint that prevents an
organization from moving closer to its goal, whatever the goal may be. For profit based companies the goal is to
make money both now and in the future.
So if your company makes its money by completing projects on time, then
following Goldratt’s logic, you must first identify what’s constraining
it. Goldratt used the analogy of the
strength of a chain being dictated by its weakest link to demonstrate the
concept of the constraint. Let’s take a
look at a simple example to demonstrate a physical constraint.
Figure 2
Suppose
you have a process consisting of five individual processing steps with the
average individual processing times for each step listed in each box (Figure 2). Step 1 requires, on average, 2 days to
complete, while Steps 2, 3, 4 and 5 require 3, 7, 2 and 3 days on average
respectively to complete. Because step 3
takes the longest to complete, it is identified as the constraint in this
process. Because it is the constraint,
it dictates the rate at which products are produced using this process. And
until its processing time is reduced, your throughput will remain at one part
every 7 days. Even if you could
magically remove a full day from each of the other steps (i.e the
non-constraints 1, 2, 4 and 5), the throughput would remain the same at 1 part
every 7 days.
There are two important points that we need to reinforce:
- Attempts to reduce the cycle times of non-constraint process steps that either feed or receive the output of the constraint do nothing to improve the overall output of the total process or system. Only improvements to the constraint positively impact the output of the process.
- Because the constraint dictates the system throughput, the focus must be on protecting the constraint from starvation because any time lost at the constraint is lost to the entire process.
You will recall from other postings here that Goldratt’s 5 focusing steps (or his process of on-going improvement) are as follows:
- Identify the system constraint.
- Decide how to exploit the constraint.
- Subordinate everything else to the constraint.
- If necessary, elevate the constraint.
- Return to step 1, but don’t let inertia create a new constraint.
So
why do I bring up the Theory of Constraints and a physical process like the
5-step process we just looked at, when we’re here to talk about projects and
project management? Good question and in
my next posting, we’ll answer that question.
Bob
Sproull
No comments:
Post a Comment