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!
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.
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.