- About TOC
- Learn TOC
|Submissions to Eli's 5th Riddle (with comments from Eli)|
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 CCPMRIDDLE: 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.
A Riddle by Eli Schragenheim
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!
"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 iterations
The 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.