Today's multiple project environments
generate multiple priorities for project resources and
managers. These competing priorities cause a loss of focus
and contribute to the inability to complete tasks (and
projects) on schedule. The Theory of Constraints (TOC) is a
philosophy of management and improvement characterized by
its recognition of the interdependent nature of complex
systems like organizations and projects. Applying TOC to
project management has resulted in the methodology known as
Critical Chain Scheduling and Buffer Management and its
extension to program and multi-project management. This
program will discuss project management solutions based on
these concepts.
Additional Answers to questions from the meeting:
>* Sure wish I could have had my question answered.
How do you prevent initial tasks from using up the entire
available buffer?
You manage the project by managing the buffer. The
buffer is not only a static demonstration of the health of
the project; it is used during project execution to
highlight that attention must be paid to a project that
might be in jeopardy. If you still have the handout (If not,
check out
<http://www.focusedperformance.com/articles/multipm.html>),
look at the slide on buffer management where you can find a
paper related to the presentation), showing the breakdown of
the buffer to OK, Watch & Plan, and Act sections.
If the buffer starts to get consumed in the early going, you
would rightfully be concerned if it were allowed to be 33%
consumed with only 10% of the critical chain completed. I
like to advise my clients that in the early going, buffer
management be used almost like an SPC (statistical process
control) control chart. If the project buffer is
consistently being consumed at a faster rate than critical
chain is being completed, that trend can also be an
indication that a corrective action or "proactive reaction"
be developed to replenish buffer.
If frequently and regularly updated and reviewed, buffer
tracking allows visibility to trending situation, heading
off surprises (allowing one to "panic early," as I mentioned
in the presentation), and planning corrective actions in an
environment that is not characterized by crisis.
>* Good topic but difficult to implement
>* Seems like a very difficult paradigm shift
>* Good point about the need to get top down buy
in to approach, to make it work
These comments were all concerns about buy-in to the ideas
and obstacles to implementation. With a carefully designed
program of leadership buy-in, just-in-time education,
development of internal expertise, and phased roll-out, it
is usually implemented with all current projects re-planned
for the process in about 3-4 months.
It involves not insignificant attention, but I wouldn't call
it difficult.
>* Unfortunately I doubt my [company name deleted]
management would ever embrace such a great concept as
this.
This is a very common obstacle -- not management, but the
convinced PM's doubt that they would be receptive. Not all
management are like the pointy-haired boss in Dilbert. Many
people like the writer can often be pleasantly surprised by
management's response to a presentation of the concepts, as
long as that presentation is put forth in terms of problems
that management identifies with. Actually, when it comes to
multi-project environments, management usually has the best
big-picture view and understanding of the impact on the
larger organization's ability to get more throughput. PM's
usually focus on their own project and resources usually
focus on the technical aspects of their tasks. Management is
usually given insufficient credit for the ability to
recognize common sense. If you don't ask them to consider
something that makes sense, you're not giving them a chance
to surprise you.
>* I do not have any control over resources on who
works on what task
What PM really does? As a matter of fact, the PM shouldn't
have such "control" where resource managers have the best
perspective on capability and availability of resources. If
there is concern on the part of a PM on this issue, I would
think that the recognition of potential variability in the
scheduling process and the robustness of the use of buffers
for real and visible management of the project promise will
help in environments where the PM doesn't "control"
resources.
>* What type of projects would this work on. Need
example to understand
>* TOC is difficult and requires a better build
up. More specific real life examples should be added. The
other discussion would be how much is TOC validated by
actual projects? (2)
More and more companies are starting to be willing to talk
about their success in implementation of critical chain and
critical chain-based multi-project management.the following
list should provide a sense of the type of projects to which
this has been applied:
- Reflectone/British Aerospace - Commercial/military
aircraft simulation systems (flight simulators)
- Lucent Technologies - Product development in a variety
of business units (One unit went public at a
presentation at a recent Management Roundtable
conference on product development)
- Seagate - Computer storage systems (also a recent
Management Roundtable)
- Synergis Technologies - Automotive sheet metal
stamping die design, development, and manufacturing
- Elbit Systems - Israeli developer and integrator of
"high-tech" military system upgrades
- Seabridge/Siemens - telecomm switches
- Lord Corporation - Internal business IS services
- Balfour Beatty - UK Civil engineering, road building
- Harris Semiconductor - Single Project for construction
of a semiconductor fab facility, multi-projects in
development
- ITT NightVision - Product development, in effort to
shift from military focus to more commercial
applications
- Better Online Systems - Israeli software developer for
mid-range IBM systems
Details on most of these are available either on videotape
or online in the "Success Story" portion of the Goldratt
Institute website, found at
www.goldratt.com
>* Feel that it really not appropriate to project with
controlled due date
If I'm interpreting "controlled due date" correctly, I'm not
sure where the concern is. In the Critical Chain
methodology, there is a solid due date at the end of the
project buffer -- one that is rational, yet is usually
10-35% closer to today than in a traditional schedule where
safety is spread out among the tasks. As the schedule chains
complete in more or less time than originally modelled
(which we expect to happen), the buffer is consumed or
replenished at the front end. The buffer is solidly anchored
at the due-date end. The buffer flexes like a shock absorber
so the due date doesn't have to move.
>* I anticipated that there would be more
sophisticated examples of critical chain concepts (but
maybe it would have been too difficult to comprehend).
>* Would have benefited from clearer examples.
More contrasts of standard scheduling & resourcing
would have been helpful.
With only about an hour for the presentation, and with an
audience with various levels of familiarity with the topic,
the objective was to introduce the concepts. More difficult
examples would raise more noise in such a presentation than
would be worth the effort to get around. If anyone is
interested, there are half-day and 2-day presentations
(including the one mentioned in the "filler text" on the
multi-tasking exercise handout) available that include
considerably more complex examples, simulations, and
exercises.
