DOC

Implementation Details

By Herman Stephens,2014-12-01 16:17
9 views 0
Implementation Details

    A Guide to Implementing the Theory of Constraints (TOC)

PowerPoints Preface Introduction Site Map Contents Next Step

Bottom Line Production Supply Chain Tool Box Strategy Projects & More ... Healthcare

Project Buffers Critical Chain Implementation Multi-Project

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

The Good, The Bad, And The Ugly

    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.

Basic Project Plans

    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.

    A Simple Project

    Task 4 Task 5

    Task 1 Task 2 Task 3Task 6

    The result is, as we have said, an “A” plant tipped on its side. Curiously, this is also Goldratt’s

Thinking Process logic diagram for pre-requisite trees;PRT tipped on its side as well. A

    pre-requisite tree deals with necessity-based logic a tree with a trunk and main branches but not

    with the sufficiency of all the sub branches and leaves, or a stick figure rather than something that is fully fleshed out (2). A discussion of these logical tools can be found in the section called Tool

    Box.

    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;

    Automatically Wherever Feasible

     Task 2

    Task 1 Task 2

     Task 1

    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.

Task Resourcing

    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.

Reduce Multi-Tasking

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.

Reduce The Number Of Open Projects Freeze, Reduce, Maintain

    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.

    Freeze/Unfreeze Period 1

     Project & Status

    1 CompletedFinishStart

    2 Current

    3 Current

    4 Current

    5 Current

    Current 8 Projects

    6 Current

    7 Current

    8 Current

    9 Current

    10 PendingStartFinish

    Current Period

Here we have an idealized production operation, too good to be true for sure; but good enough to

    help convey the mechanics of what we must do. There are 8 projects open at any one time in this process. They take 16 periods to complete and one ends and another starts every 2 periods.

    We can see that in the next period project 2 will finish and project 10 will start.

    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.

    Freeze/Unfreeze Period 2

     Project & Status

    1 CompletedOld Tasking

    2 CompletedOld Tasking

    3 CurrentTransition

    4 CurrentTransition

     Focus 4 Projects

    5 CurrentTransition

    6 CurrentTransition

    7 Frozen

    8 Frozen

    Frozen 4 Projects

    9 Frozen

    10 Frozen

    11 PendingNew

    Current Period

    Projects 1 & 2 are completed. Projects 3, 4, 5, & 6, are current. Projects 7, 8, 9, & 10 are frozen. We have one new project, project 11 that is now pending.

    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.

    Freeze/Unfreeze Period 3

     Project & Status

1 CompletedOld Tasking

2 CompletedOld Tasking

3 CompletedTransition

4 CurrentTransition

5 CurrentTransition

     Focus 4 Projects

    6 CurrentTransition

7 Unfrozen/Current

8 Frozen

    9 FrozenFrozen 3 Projects

10 Frozen

11 PendingNew

    12 PendingNew

    Current Period

Project 3 is complete, and project 7 is unfrozen and work has recommenced on it. A new project,

    project 12 is waiting in queue. No new work has been admitted and 4 projects remain current.

    Let’s look out a period

    Freeze/Unfreeze Period 4

     Project & Status

1 CompletedOld Tasking

2 CompletedOld Tasking

3 CompletedTransition

4 CompletedTransition

    5 CurrentTransition

    6 CurrentTransition

     Focus 4 Projects

    7 Unfrozen/Current

8 Unfrozen/Current

9 Frozen

    Frozen 2 Projects

    10 Frozen

    11 PendingNew

    12 PendingNew

    13 PendingNew

    Current Period

    Project 4 is now complete and project 8 has been unfrozen. Four projects remain current. Two

    projects remain frozen.

    Let’s step out a period.

    Freeze/Unfreeze Period 5

     Project & Status

1 CompletedOld Tasking

2 CompletedOld Tasking

3 CompletedTransition

4 CompletedTransition

5 CompletedTransition

    6 CurrentTransition

7 Unfrozen/Current

     Focus 4 Projects

    8 Unfrozen/Current

9 Unfrozen/Current

10 FrozenFrozen 1 Project

    11 PendingNew

    12 PendingNew

    13 PendingNew

    14 PendingNew

    Current Period

    Project 5 has been completed and project 9 has been unfrozen. There are 4 current projects and

    one frozen project remains.

    Let’s see what happens.

Report this document

For any questions or suggestions please email
cust-service@docsford.com