Congratulations to Christophe Lambert, winner of Eli's 5th Riddle!
A discussion area has been setup in the TOCICO forums pertaining to boundaries with CCPM, which fits in nicely with this riddle. To post in the forum area click on the following link: http://www.tocico.org/forums/topics.asp?forum=119139&.
You must be signed in to a member account to post in the forums! Once signed in to the forums, click on Post New Topic to start a discussion!
What Can One Learn from a Very Bizarre Project? OR Learning the Boundaries of CCPM
A Riddle by Eli Schragenheim
RIDDLE: When Knowledge and Innovation Inc. asked Aaron to implement
the TOC methodology for running projects at the company he was very
pleased. The company, whom he got to
know from the two workshops on CCPM he delivered to two different groups of
engineers, seemed to be mature and ready to take the next step and implement
the change. The workshops were well
received and top management were truly enthusiastic as lateness of projects had
been a major problem for the otherwise successful company.
Aaron started the CCPM strategic process according to the
book: two projects were stopped and
another three were frozen. The five remaining
projects were carefully planned according to the 50% cut of the planned task
times and inserting the appropriate buffers.
From the start it was clear that a specific ambitious project,
entitled "ONE”, took the most managerial attention and very high budget. It also took most of Aaron’s time and a lot
of nerves. The unique feature of "ONE”
was that all the work was done by people fully dedicated to the project. The official start of the project took place
two months after Aaron started the CCPM implementation. The planned duration time was 16 months. Three months after the official kickoff of
project, the progress along the CC was only 4% and the penetration into the
buffer 35%. In spite of these facts Dr.
Randolph Duncan, the most reputable scientist in Knowledge and Innovation who
served as the project leader, seemed to be very satisfied. "Everything is going well”, he told Aaron
trying to get some sensible explanations for the huge delay.
Dr. Duncan showed just a little more concern when, after ten
months of running the project, the whole project had to be re-planned. The new completion date came to two years
from that time! Meaning a total delay of
18 months. An urgent top management
meeting was called to deal with the severe situation of the project. The CEO of the company had asked Dr. Duncan
whether the new date was doable. "Of
course” was the answer, "we all work 18 hours every day to make it
happen.” Then the CEO had looked at poor
Aaron and said "I expect you to guide them to materialize that – please, come
to me anytime you need to put extra pressure on those guys – this is a very
important project to the company and every month of delay costs us a fortune.”
In a lot of ways Aaron felt lucky to stay with the company
and got his retainer for the CCPM project.
About a year into the CCPM implementation the status of all other
projects showed great improvement. But,
project "ONE” was still problematic. The
delays in that key project continued.
Two years after its start the calculated remaining time to completion
was still two years from that time!
Certainly all the buffers, feeding as well as the project buffer were
all consumed, even according to the re-planning time table. At that time another re-planning were done –
delaying the due-date to four years after the start of the project. Then after
three years since the official start of the project the status showed only 70%
of completion of the critical chain and 85% of project buffer consumption. At
that time Dr. Duncan suddenly told Aaron that a breakthrough had been achieved
and the completion was expected in merely two months! The big surprise for Aaron was that the
project really finished in just two and a half months after that declaration. The final score was that the project,
originally planned for 16 months, finished after 39 months! Long before the last planned due-date.
In the great party organized by Knowledge and Innovation for
the successful completion of the project, the CEO has publicly announced his
deep appreciation for Dr. Duncan, Aaron and the TOC CCPM approach that were all
so important in achieving the success.
"What can I learn from such a bizarre project?”
thought Aaron. "Does CCPM really add any
value when a project behaves in such a way?”
ELI'S ANSWER: I wrote this riddle in order to demonstrate the boundaries
of the existing TOC methodology of CCPM. I claim that CCPM contains the
following important basic assumption:
We know what is required to achieve the
output of the project!
This assumption is
certainly valid for most projects.
However, there are also several types of projects for which that
assumption is not valid. The case does
not specifies what project ONE is all about, but there are clear signals that
the above assumption is not valid in this particular case.
Vivek Chopra
wrote:
The high component of
"discovery” in project ONE differentiates it from typical projects that we come
across.
Menno Graaf made
the following assumption on what project ONE is:
"More a research than a
development project. Like developing a new, state of the art, system platform.
In such a project, instead of a linear approach, development might be better
modeled by an iterative approach. "
Chrisrophe
Lambert started his excellent answer by:
"The
CCPM body of knowledge is directed towards project execution and not defining
project content. In the case of project "ONE” it appears that the content was a
moving target – perhaps because groundbreaking innovations were required, as
evidenced by the surprising breakthrough at the end, and that a top innovation
scientist was in charge of the project rather than an engineer.”
While Menno
emphasized the possibility of iterations, Christophe highlighted another aspect
of innovative project of frequent significant changes in the content, meaning
that in the initial planning of the project we might not know what tasks are
required. Vivek Chopra also pointed that
the very different nature of uncertainty between regular projects and
innovation projects. In regular project
the uncertainty is about the time required to do a job. Vivek has stated that in "discovery” project "There is uncertainty on ‘What
to change’, ‘What to change to’ and ‘How to bring about the change’”.
Both the existence
of iterations (having to repeat some tasks with somewhat different parameters)
and changing content (new tasks replacing those that were part of the initial
plan), puts us in a state where:
Predicting the time
for completion the project within accepted range of time is an illusion!
Christophe wrote:
"That the CEO still considered the project a success at the
end suggests that he knowingly set deadlines that were more ambitious than his
real expectations.”
I’m not sure the CEO had
clear expectations regarding project ONE.
I’d suggest he had been aware to the risky investment in that project
which could be highly successful but also could become a bitter failure. Setting the managerial expectations in such
projects is certainly different than what the CCPM methodology guides us to do. Also, in such innovative projects the time
estimations one gets from the professionals are clearly too optimistic,
meaning in 90% of the time they are much shorter than the actual time it would
take. In this respect the behavior is
the opposite than in regular routine projects.
What can we do in a case of a
project that lies out of the boundaries of the regular CCPM?
It is evident that some parts
of CCPM are still effective. Buffer
management still yields the right priorities and let you know the current state
versus the reference due-date. But,
there are parts that do not work well.
Menno Graaf’s says that when
such an innovative project is impacted by iterations "…the
number of iterations can be very unclear. In such a case it may be better to
plan and execute one iteration at a time and after each iteration do a lessons learned
& replan.”
I agree that such a project
calls for different sort of planning. My
suggestion is to have a very crude planning of the project output, while
frequently plan in more detail just the next stage.
Christophe comments that "Some
early work in the TOC community suggests that a ‘content strategy and tactics
tree’ may a key tool in augmenting the body of knowledge to address variability
and uncertainty in project content; but at the moment the knowledge is not well
developed.”
I agree we need to develop the content S&T for such a
project, but we also need a methodology on how to execute such a project. What should be the format of the managerial
expectations and what are the rules of judging and prioritizing the content
changes?
I did not intent to develop a full solution for managing "discovery”
projects. I just want to highlight the
need and point to some of the inconsistencies in using the regular methodology
of CCPM when the key assumption concerning knowing what is required to achieve the
output is invalid.
Three answers stand out and I suggest you to read them carefully. The three are by: Menno Graaf, Christophe
Lambert and Vivek Chopra. I think one
can clearly comprehend from those answers the need, and also a certain
direction, for developing a full TOC method for innovative projects. Personally I’d like to give the first prize
to each of them. If I have to choose
just one it is Christophe Lambert with whom I fully agree on every
sentence. But, Menno and Vivek add quite
a few important insights.
Christophe's Answer (winner): The CCPM body of knowledge is directed towards project execution and not
defining project content. In the case of project "ONE” it appears that
the content was a moving target – perhaps because groundbreaking
innovations were required, as evidenced by the surprising breakthrough
at the end, and that a top innovation scientist was in charge of the
project rather than an engineer. Also, that the project was re-planned
twice suggests content changes – not just schedule changes.
It is
troubling that the TOC consultant, Aaron, seems so clueless about what
went on with project "ONE”. No reasons for delay were given in the
riddle, and Aaron seems to be scratching his head over the delays as
well as why his sponsors seemed happy despite the delays. The CCPM POOGI
process should have surfaced reasons for delays in project "ONE”.
Aaron’s lack of understanding over delays suggests to me that the POOGI
process was either not implemented or implemented improperly. That the
CEO still considered the project a success at the end suggests that he
knowingly set deadlines that were more ambitious than his real
expectations. That the project was considered ambitious, that it was
given a fully dedicated team and that top scientist Dr. Duncan seemed
pleased with progress three months in, despite significant buffer
penetration, suggests that significant difficulties were expected. That
is, they probably did not have the content of the project fully scoped –
it had a significant research component with huge uncertainties in
whether, when, and how certain breakthroughs would be achieved. There
must have been significant unforeseen dependencies and contingencies to
have required project re-planning twice.
Some early work in the
TOC community suggests that a "content strategy and tactics tree” may a
key tool in augmenting the body of knowledge to address variability and
uncertainty in project content; but at the moment the knowledge is not
well developed. TOC clearly brought value to the rest of the projects
that presumably did not have substantial problems with content. Did CCPM
bring value for project "ONE”? The focusing efforts of buffer
management may have directed management attention to the most
problematic areas of the project to address content uncertainty, and
certainly it functioned well for execution once the final needed
breakthrough was achieved. CCPM probably also made for more effective
execution on the project parts that were well defined so that they hit
the major innovation obstacles sooner. The CEO publicly declared that
project "ONE” was a success and attributed that success to CCPM. His
expectations had been exceeded – which were different than the deadlines
he had set. Thus even for project "ONE” CCPM delivered better results
than what the company was accustomed to pre-CCPM, despite deficits in
addressing content variability in the body of knowledge.
The rest of the submitted answers are listed below, in alphabetical order by LAST name.
1. Akshay Arya: CCPM Adds value to the project only if CCPM Methodology is adopted while
executing the project. In the above project the Project Manager Dr
Duncan did not seem to be sensitized when the status of the project
after 3 months was only 4% cc completed with 35% Buffer consumed. Uncertainity
is part of any project in Project Management & therefore Buffers
are kept at the end of the Project to ensure that project is completed
on time. If the Project is so important to the company that any delay costs as a fortune. The
Team should have reviewed the project at weekly & check the status
of the project & ensure that the most penetrating task is addressed
on top priority. Also Checking the rate of consumption of the buffer to ensure that project is recovering or not.According
to me If the project was handled as mentioned above with rigor the
project could completed within 16 months of scheduled timeline &
company could leverage the early delivery of the project for getting
further orders which No competitor can complete.
2. Vivek Chopra: Following are my observations based on the case presented:1) The
high component of "discovery” in project ONE differentiates it from
typical projects that we come across. In a typical non-discovery
project, the "constraint” is clear- it is the time on the Critical Chain
which has to be protected against the effects of variation caused by
changing work content, resource dependency and multi-tasking. In such a
non-discovery project, the outcomes of the individual task which form
the CC are largely clear- it is the time required to perform them which
is subject to variability. But in project ONE, the constraint is not
only the variability (some of the major causes of variability- the
resource dependency and multi-tasking may not be present in this project
since all team members are dedicated to this project alone. However
this still doesn’t mean that variability is not present). Variability in
time estimates is still there- since we may be attempting something for
the first time in project ONE, we do not have precedents to fall back
on for estimating task times. However, apart from variability, the path
that has to be followed to move from the current state to the envisioned
future state in project ONE, in order to generate a pre-defined output,
is also not very clear. There is uncertainty on "What to change”, "What
to change to” and "How to bring about the change”. The only way to
manage this constraint, the uncertainty in the path, would have been to
elevate it by finding answers to the 3 questions asked. The Thinking
Process tools should have been used to accomplish this. The Trees should
have been drawn- in a way the trees are still being drawn by Dr Duncan
and team, the only difference being that they are all in their minds-and
that the cause-effect linkages between the various UDEs should have
been established through actual experimentation as would be the case
here. Aaron could have used the Thinking Process tools to guide the
discovery process much better than it was done. This would have served
two purposes: i) It would have kept Dr Duncan and his team of scientists
focused on the goal and identify the few leverage points that could be
used to achieve their goal quickly. As a result, the discovery process
would have been shorter and the "breakthrough” may have been achieved
earlier (ii) the top management, which did not understand the project
technicalities would have been witness to the creation of the tree and
blockages therein. The progressive formation of the tree, including
negations of cause-effect linkages is in itself a "progress” for Dr
Duncan, though there may not be an actual deliverable to share with the
management to show progress- this understanding would have dawned on the
top management and so differing perceptions on whether the project was
moving well or not (as were there in this case) would not have been
there. The second constraint was the usual one in every project
scenario- the variability in time estimates still existed largely since
the project was being done for the first time. This variability in CC
time would have been protected through an overarching CCPM framework.
Once the project was done and the output achieved, it may have been
possible to reduce this variability in achieving the output through
various means and then to transition to S/DBR for mass manufacturing.2) I
am a little skeptical about how dedicated the dedicated resources would
have been with time in this project. Projects with higher upstream
tasks variability as in this case may lead to downstream resources
waiting endlessly for their part of the work to arrive- some would
probably be sitting idle for months for their work to arrive. There
could be a real danger of them getting involved in some other work and
not be available immediately available when their turn arrived, thereby
becoming a constraint.3. Lisa Ferguson: One can learn something from this bizarre project. CCPM does add value
when a project behaves in such a bizarre way. First, we need to
understand that the CCPM solution was first developed for a single
project environment, meaning one in which resources (such as people) are
not shared across projects. Then, that solution was further developed
for a multi-project environment (additional injections were added). The
CCPM solution focuses on the critical chain (CC), the longest sequence
of task and resource dependencies in the project plan. The project
buffer (PB) is the protection (safety time) for the entire project. The
PB is typically half of the safety time removed from the CC tasks.
Comparing the progress on completing the CC to the PB depletion is a
very good measure for determining how well the project is progressing. As
project "One” was progressing, it was clear based on this measure of
performance that the project was in trouble. Several hypotheses can be
generated for testing to determine what the cause or causes of this
project’s troubles were. One hypothesis is that the project plan that
was created in the first place was not realistic. The CCPM solution does
include a process for generating a project plan that does effectively
include all dependencies. We could evaluate whether this was in fact the
case in this project. Another hypothesis is that the times
estimated for the tasks were unrealistic. We know that the estimate for
completing a project task can be just an educated guess – that the
actual distribution of task times for completing a particular task
follows a skewed distribution (one with a long tail). If the project is
not one in which the resources have much experience with doing the
tasks, then the time to do each task can really be just a guess. There
is typically pressure on resources and managers to cut task time and
project lead time estimates as much as possible. Therefore, it is
possible that the task time estimates were too low in this project. Of
course, it is important to ensure that the resources have the correct
behaviors on the project. It is critical to minimize bad multitasking
and focus on delivering tasks with high quality results quickly. This
enables us to have early finishes on some tasks compensate for late
finishes of other tasks.Aaron was surprised that the project was
completed in 39 months, which was 9 months less than the planned
completion of the project. Three years after the project started, Dr.
Duncan pointed out that a breakthrough had been achieved. At that time,
70% of the CC was complete and the PB was 85% depleted. Three months
later, the project finished. In my opinion, this result was not so
surprising. It is not uncommon for a project managed using CCPM to
finish somewhere within the PB (before the estimated project completion
date). It took three years to complete 70% of the project and three
months to complete the other 30% of the project. This is not unusual in
projects with testing at the end of the project, when it is unknown how
much effort will be needed to complete the project based on what results
were actually achieved. It is also not unusual in cases where some
solution or realization for how to more effectively complete the project
task(s) is generated.4. Mark Geschke: Yes, even in this scenario CCPM adds a lot of value. Even though all
project resources were fully dedicated (and we can thus assume they were
not doing bad project multitasking), CCPM still enabled better
prioritisation of scarce management attention, clear understanding of
the importance of the project and continued focus on removing obstacles
(even if it was just by extending the expected due date)What one
can learn from this project is that certain tasks may have incredibly
high variability (such as finding specific R&D breakthroughs) and,
apart from providing the proper focus through CCPM, we have to accept
that some project due date changes are to be expected. We also need to
acknowledge the negative effect the outside pressure has had on Dr
Duncan as he clearly moved away from providing 50% task estimates to
more buffered estimates to "silence the critics", evidenced by the fast
and accurate completion after the critical "breakthrough" was made.
5. Menno Graaf: Yes, as CCPM will still be synchronizing and focusing the team. Or, said
differently, without CCPM the delays would have been much worse. The
question is what was the reason for delay? The story is vague about
this, but I would expect that somewhere in the 39 months of his
involvement, Aaron should have started to get an idea about the problem
driving these huge delays. For the sake of the argument, taking
an assumption, this sounds like a project where technology was not
mature. More a research than a development project. Like developing a
new, state of the art, system platform.In such a project, instead of
a linear approach, development might be better modeled by an iterative
approach. And the number of iterations can be very unclear. In such a
case it may be better to plan and execute one iteration at a time and
after each iteration do a lessons learned & replan for 1) Setting the targets & the plan for the next iteration 2) Coming up with an estimate on the number of remaining iterationsThe
other points of investigation would be to look at the internal WIP of
the project. As the people working on this project were fully dedicated
*and* the project had full management attention, reducing the WIP in
projects overall was not very relevant for the execution of this
project. Relevant for the execution of this project was the organization
of the work and managing the WIP within the project.Another
observation I have is that the story gives me the impression that
top-management was not really involved. If so, I would expect them to
have been on top of this project (and the other projects in the
portfolio) on a more regular basis, so that the project could not have
been out of control for 10 months before a re-planning session was held.
The signs that the project was out of control were already clearly there
within the first three months of the project. Did Aaron roll-out the
full Strategy & Tactics tree in this company?The note that
the Feeding Buffers were all consumed is not very helpful. Depending on
the modeling of the Feeding Buffers (were they getting re-aligned with
the delays on the longest chain?) this might be something that either is
to be expected (no re-alignment) or may point to a problem in the
planning (too many chains all comparable in duration to the longest
chain).I do hope that the company survived. I have seen a
company eventually being killed by such delays on a really critical
project. Next time it might not be a bad idea for Aaron to call in the
help of Eli or other TOC friends if he finds himself in such a
situation.
6. Kevin Kohls: The project, from a conventional perspective, was not that bizarre – it
was just being run using traditional methods, under the guise of CCPM. A
Hansei at the end of project would probably confirm these assumptions:•
Dr. Duncan did not get past the first part of the layer of resistance –
Agreement that there was a problem. Traditional measures probably
showed him that he was reaching expectations. The Red status was not
really indicative of a problem; there was plenty of time. Besides,
ambitious projects are always late. That’s reflective of his comments
that everything was fine, and the reluctance to talk about specific
problems that needed to be addressed.• If there was no agreement
that a problem existed, Dr. Duncan mostly likely used traditional
project management methods to evaluate his engineers, creating a
conflict for them. Since Dr. Duncan is the boss, and Aaron the
consultant, the engineers did what Duncan wanted. They used the CCPM
methods for reporting, in order to prevent push back from the CEO, but
did not change their behaviors based on these measures.• If
traditional measures and project management process was being used by
Dr. Duncan, then his people were going by the "never finish early” and
"never finish late” mentality that is prevalent in large companies. •
The dedicated resources felt pressure to make it look like Dr. Duncan’s
team was working efficiently, especially since the 18-hour target was
set. With that in mind, they pulled ahead work to look busy, and then
reworked those tasks once the previous task was completed. This delayed
the project, but made them look like they were working hard, to meet
Duncan’s expectations. • It’s clear that Dr. Duncan is well respected – perhaps too much so. Several things support that:o
Only one urgent meeting was held between the CEO and Dr. Duncan. A
weekly meeting should have been scheduled by the CEO until the project
got out of the Red. A PDCA should have been generated to make sure
countermeasures where getting done. o The CEO put the responsibility of "telling” on Aaron, instead of stepping up for that task himself, based on the fever chart.o
Dr. Duncan should not have been praised at the party, but chastised at
the end of the project review for poor results. This only reinforces
Dr. Duncan’s belief that a problem does NOT exist. o The CEO
probably did not want to anger Dr. Duncan, and risk losing a resource
that could bring in future business. Did the amount of money lost
exceed the benefit of keeping Dr. Duncan?o It begs the question if Dr. Duncan attended the (whole) CCPM training class.•
Was the organization really aware of the cost of being late? Aaron
should consider a financial impact measure, perhaps on a weekly basis,
to make sure Dr. Duncan and the CEO understand the bottom line impact of
the project being late. That may have challenged Dr. Duncan’s
perception that a problem did exist. • Dr. Duncan was also smart enough to know what it would take to look like a hero towards the end of the project. o Pad the project so much at the end that he would finish early to that date.o
Since being called "on the carpet”, Dr. Duncan make have reacted to
that feedback by telling his engineers to report tasks were incomplete
to Aaron when they were really done. When everything finished suddenly,
Dr. Duncan looked like he had reached a "break through”. So the
Hansei should make it clear that this project was not bizarre; it was
just a traditional project being run under the guise of CCPM. That must
be avoided in the future. Some specific actions plans should be
address, if the Hansei is valid:• The CEO needs to evaluate if
Dr. Duncan should be in charge of the next project, based upon the
profit lost and the future potential.• Aaron must ensure that the
CEO understands that praising the performance of a poor project manager
will influence future project managers’ behavior. • Aaron should
ensure that the CEO understands the layers of resistance and what it
takes to overcome that resistance. He then must work with the CEO and
other future project managers to overcome these obstacles at the
beginning of the project. • Aaron needs to make sure the right
behaviors are being generated by the CCPM measures. He must make sure
two sets of measures are not used on future projects, especially any
that involve Dr. Duncan. • Aaron should also challenge the need for dedicated resources on future projects. •
Aaron may want to consider measures for the CEO, if that is feasible.
Are countermeasure meetings being held on Red projects? Are PDCA’s being
generated? Are those tasks getting done by the promise dates?7. Grant Lindsay: It appears that the "One" project was constrained by a research and
development task. It is often difficult to estimate the expected
completion of such tasks. There may be a known process to follow in
pursuit of the results, but the timing and arrival of the results is
largely unknown. CCPM still adds value in such cases because it provides
focus on the critical task. We may not know the remaining duration, but
we do know it is the constraint and thus we are better able to exploit
it and subordniate others to it.8. Nicola Nabacino: Given the partial information provided (e.g. why did other projects proceed well?) different answers are possible.I
think the most likely is that project ONE It looks like a project with
high degree of innovation. People had to invent ("discover") something
new, which is not so predictable. Under these circustamces, the
"standard" rule for buffer sizing may be inappropriate. This rule was
derived mainly under assumptions of multitasking and student's syndrome,
that seem not so applicable to project ONE (at least multitasking). The
degree of uncertainty taken by venturing in unchartered waters should
be buffered in a different way (i.e. longer buffer).9. Tulasi Ramachandran: Inferences:1.In Knowledge & innovation segment, inherent
variability could be very high; there could also be iterations;
re-planning should be expected. 2.There is unlikely to be anything
wrong with the company’s understanding or ability to implement CCPM as
they did get results in other projects.3.It can also be assumed that
the project was not starved of resources as it was perhaps the highest
priority project; No shared resources with other projects means no
pressures for bad multi-tasking.4.It can be assumed that priorities were stable since this was the highest priority project with dedicated resources.5.The
project might be making progress along the feeding chains in the
initial period – giving an illusion of progress by the more traditional
measures of progress. This shows inadequate understanding/ buy-in on
part of the project leader.6.Extra pressure does not help – real
help is much more useful; can come by participating in the planning
process; Working 18-hours a day (planned?) => no scope for
recovering?Q) What can I learn from such a bizarre project?Ans)
In such projects where there is high variability and unknowns,
replanning should be a regular feature; at least once in 3 months. A
full understanding of CCPM would have elicited a much different response
and re-planning might have been undertaken at that point itself.Q) Does CCPM really add any value when a project behaves in such a way?Ans)
CCPM adds the value of measuring the project status by progress along
critical chain. This would certainly have helped in creating a sense of
urgency earlier than what might have happened otherwise. In this case,
Dr. Duncan would have continued with the false perception of progress
had it not been for the warnings given by CCPM. CCPM enabled him to go
for the replanning at least after 10 months.it could be safely said that
his behaviour was impacted – in a way that could only help the project
progress towards completion.It is quite likely that after 10 months
the project team became wiser, better understood the activities, and
interdependencies within the project. So re-planning helped in
formalizing that understanding and coming up with what could perhaps be
the best possible option at that point in time. CCPM way of planning
would have certainly helped by tackling students’ syndrome, Parkinson's
law, formalizing the priorities and aggressively shortening the length
of the critical chain.10. Justin Roff-Marsh: In retrospect, It appears that project lead-time for ONE was heavily
dependent upon the resolution of a single technical problem. Aaron
should have discovered this and planned separately for the components
of the project that had such radically different risk profiles. It
may well be that CCPM adds limited value to the technical problem when
viewed in isolation -- however CCPM can (and should) still be used to
manage the balance of the project environment. Perhaps it would
have made more sense (for example) to create a number of CCPM models --
based on various scenarios relating to the resolution of the technical
problem -- and then switch between these models as information became
available? Sadly, Aaron's failure to understand and plan
appropriately, eliminated open and honest communication between him and
Dr Duncan, rendering effective planning impossible once the project was
underway.11. Guillermo (Bill) Taylor: A breakthrough requires a "Eureka" moment. There is no telling when
Archimedes will have an epiphany during his monthly bath. It could be
one month or five years. What Critical Chain does is keep the
pressure on the critical task at which the break though is required.
After the project has been running a while, all feeder chains leading
upto the critical task are completed, and all the succeeding tasks are
primed to take off after the breakthrough. Dr. Duncan is
obviously a perennial optimist with a big ego. That's why his supreme
confidence was maintained even after more than three years of "failures"
(or, as Eli Goldratt would say "partially successful prototypes"), and
he still underestimated the critical chain remaining with 2 - 4 months
left to complete.
12. Kobus van der Zel: To understand a bizarre situation I find it helps by looking who would be hurt and who would benefit from a project delay. If
this project was paid for by some external customer on a
time-and-meterials basis or from some "head office" budget the Project
Manager, Dr. Duncan and his CEO could politically survive and even be
seen as a heroes for extending the project for this long. If
their own business unit was responsible for the project budget, then
this case study highlights the fact that there is a serious
misalignment in the measurements by which people are being held
accountable in this K&I Inc. business unit - including not holding
contractors like Aaron accountable by allowing retainers to continue
despite this project's delay. If you held any shares in this
company you should sell it and short the stock. Like Warren Buffer told
us "in the short term the stock market is a voting machine, but in the
long term it is a weighing machine". So at some future point the market
forces will force this bizarre behavior to end.13. Sheri Zukin: Project one was the system constraint.
Print Page
