A business novel focusing on project management. The novel aims to provoke readers to examine and reassess their business practices and transform the thinking and actions of managers.
Eliyahu M. Goldratt was an educator, author, physicist, philosopher and business leader, but first and foremost, he was a thinker who provoked others to think. Often characterized as unconventional, stimulating, and “a slayer of sacred cows,” he urged his audience to examine and reassess their business practices with a fresh, new vision.
Dr. Goldratt is best known as the father of the Theory of Constraints (TOC), a process of ongoing improvement that identifies and leverages a system’s constraints in order to achieve the system’s goals. He introduced TOC’s underlying concepts in his business novel, The Goal: A Process of Ongoing Improvement, which has been recognized as one of the best-selling business books of all time. First published in 1984, The Goal has been updated three times and sold more than 7 million copies worldwide. It has been translated into 35 languages.
Heralded as a “guru to industry” by Fortune magazine and “a genius” by Business Week, Dr. Goldratt continued to advance the TOC body of knowledge throughout his life, building on the Five Focusing Steps (the process of ongoing improvement, known as POOGI) with TOC-derived tools such as Drum-Buffer-Rope, Critical Chain Project Management (CCPM) and the Thinking Processes. He authored ten other TOC-related books, including four business novels: It’s Not Luck (the sequel to The Goal), Critical Chain, Necessary but Not Sufficient and Isn’t It Obvious? His last book, The Choice, was co-authored by his daughter Efrat Ashlang-Goldratt.
Born in Israel on March 31, 1947, Dr. Goldratt earned a Bachelor of Science degree from Tel Aviv University and a Master of Science and Doctor of Philosophy from Bar-Ilan University. He is the founder of TOC for Education, a nonprofit organization dedicated to bringing TOC Thinking and TOC tools to teachers and their students, and Goldratt Consulting. In addition to his pioneering work in business management and education, Dr. Goldratt holds patents in a number of areas ranging from medical devices to drip irrigation to temperature sensors. He died on June 11, 2011, at the age of 64.
This book is really hard to evaluate for me. Probably due to my background in agile software development. I secretly hoped the Critical Chain method to provide logical proof to the agile community's intuitive findings. But it didn't.
Critical Chain covers a few important topics: fallacies of estimation, ways to create safety buffers, ways those buffers can fail, danger of multitasking, importance of optimizing for the lead time. It puts a firm nail into the coffin of more traditional project management approaches, that's for sure. It also highlights (and overcomes) the business schools' inability to teach relevant management know-how, applicable in the industry.
Speaking of the narrower field of software development, Critical Chain missed a huge opportunity that agile movement has demonstrated: Delivering value in small regular increments and by doing that allow the investment decision be incorporated into the development cycle itself. In the ToC lingo, agile questioned the assumption that the value of the project can only be delivered as a whole.
This assumption may still be valid in some domains, where Critical Chain will be tremendously helpful. One won't probably want to build a huge car park far away from a city without committing to build a whole airport.
As an Engineer I am used to reading highly structured texts where the content is clearly partitioned into numbered sections with a series of formulas and figures to present the theory. After reading the theory in each section, I’ll typically find a number of problems designed to test and enrich my understanding before proceeding to the next topic.
Eliyahu Goldratt, who is a physicist turned business consultant, chose to break from this conventional writing style by presenting his ideas in the form of business novels. Goldratt’s most famous novel is called The Goal – A Process of Ongoing Improvement. Critical Chain applies the Theory of Constraint principals presented in The Goal to Project Management. If you have not read The Goal, I highly recommend you read it, however it is not a prerequisite to understand the book Critical Chain.
Goldratt’s novels begin by introducing a lead character and then a number of additional characters that tie into the lead’s personal and professional lives. As the characters are presented, the reader learns about their various problems and their need for finding solutions. The reader then follows the characters through their journey of defining the problem and learning new ways to look at the problem along with demonstrations of how the conventional views of the problem unexpectedly lead to solutions with less than desirable results. The journey then continues with the characters finding and implementing successful solutions to their problems. Interestingly, some of the subplots in the lead’s personal life foreshadow lessons to be learned in his professional life. And often after solving the business problem, the character learns to apply the new techniques back to his person life and other problems he had not expected.
The Critical Chain revisits the Theory of Constraints principles from The Goal and applies them to problems in Project Management. As an example, the reality of uncertainty in time estimates for an activity is presented. Usually ‘safety’ is added to the estimate to ensure enough time is allocated. However this can lead to the ‘student syndrome’ where an activity will be left to the last minute if given the opportunity. This ‘student syndrome’ is not always bad and in particular cases should be encouraged. If you are familiar with The Goal and its definition of the concepts of throughput, inventory and operating expense, you may be able to anticipate how these concepts, which were applied to the manufacturing plant, should be applied to Project Management. However some of the relationships are subtle and the differences are important. To me, applying the Theory of Constraints to Project Management is analogous to applying vibration theory of a mechanical system (mass, damper and spring) to an electrical system (inductance, resistance and capacitance). If you are familiar with these physics concepts, you know that it is useful to apply your experiences with a dynamic electrical system to your experiences with a dynamic mechanical system and vise versa. But you must be careful in your comparisons if you want to derive meaningful results. The same can be said when comparing the flow of material through a manufacturing plant and the flow of completed milestones in a project plan. I encourage you to read the book to fully appreciate this.
Goldratt’s approach of telling a story to teach his audience is not new. However, it is not common in my experience. His style is a welcomed change to conventional textbooks and is effective. Later after being sold on Goldratt’s techniques you can refer to one of the many conventional texts that were written after The Goal and Critical Chain to enrich your understanding. (For example Synchronous Manufacturing: Principles for World Class Excellence by Umble and Srikanth or Project Management in the Fast Lane by Robert C. Newbold)
I was introduced to his writing in the Process Fundamentals course, which I did two summers back, through his seminal work 'The Goal'.
'The Goal' is a must read for business professionals working in Production, Process Improvement, Operations, and Supply Chain Management.
Having enjoyed his writing style so much, I started reading his other business novel 'Critical Chain' and much like 'The Goal' it is refreshing and stimulating in all the wonderful ways!
What The Goal does for Production via Theory of Constraints (TOC), Critical Chain does for Project Management via Critical Path and Safety Time.
The #production application of TOC is dictated by 5 steps: Identify constraint, Exploit it, Subordinate everything else to it, Elevate it, and Repeat.
The project management application is similar to that except how the bottleneck is defined.
In production, bottleneck is a resource with capacity that is not sufficient to produce as the market demands; in project management, 'critical path' is the bottleneck of the project.
What inventory does to protect the bottleneck resource, safety time does for critical path.
Inventory and time are contextually different but conceptually same.
I just love a good business novel. I read The Goal back in the late '90s and that is one book I reference to this day. So I was excited to see what Goldratt does in Critical Chain. I really enjoyed how he focused on both business and academia to solve the project management question that seemed to be popping up in industry. How to manage project management constraints is pretty straight forward when you only have one project but if multiple projects, things become exponentially more difficult. In this story a group of executive MBA students and professors discover together a method to approach the critical chain when multiples projects are involved. The dialogue between the industry leaders and professors is very engaging, informative, and relevant even today. However, as in most business novels the attempt to integrate the personal lives into the story was a big failure. The storyline with one of the characters and his concern with his materialistic wife was laughable at best.
Several of my engineering co-workers recommended Goldratt to me so I could understand their job better. While I'm still a bit confused about some of the things put forth in the book, I must say that this is easily the best format I have ever read for a business book. The book reads like a fiction novel, with characters, dialogue, and internal monologues. It's fabulous! And I've heard that Goldratt's other books are the same so I will definitely be reading those as well.
I'm taking Project Mgmnt courses right now and I can assure you that this book is far more interesting than anything I've read on the subject. It reads like fiction, minus the sex and psychological struggles. Good overview of how to chart a successful project, sure you're missing all of the details for the procedures and techniques used and computer programs definitely simplify the procedure but the overview of delivering a project on time, is bang on..follow the critical path!
It's been longer than I thought since I've read this. The story line is different from what I remember. And the way CCPM is developed in the book takes some interesting turns. It has me wondering about how to introduce things. Of course there are also things in here that aren't in use anymore.
Key points that I learned (or reviewed) from this book:
4 Steps of Theory of Constraints (TOC)
Identify the constraint
Exploit “ “ (i.e. use it to full capacity)
Subordinate the rest of the system
Elevate (i.e. if possible, relieve the constraint)
Typical Failure of Classic Project Management
p152 “1. We are accustomed to believing that the only way to protect the whole is through protecting the completion date of each step.
As a result,
2. We pad each step with a lot of safety time.
3. We are suffering from three mechanisms which, when combined, waste most of the safety time:
a. student syndrom
b. multi-tasking
c. delays accumulate and advances do not”
Recommended way to approach Project Management (using TOC)
Identify the constraint - in a project the constraint is the “critical path” (i.e. the longest series of events for finishing a project); if there are multiple projects that share resources, it is likely that the constraint is actually the “critical chain”(i.e. the longest chain of dependent steps, which can go through steps from other projects if those steps must be done before your resource is available)
Exploit the constraint - schedule the sequence of work for the bottleneck (whether that’s the critical path or critical chain). Note that only the constraint’s work is scheduled. Nothing else is given due dates, as this leads to procrastination. Instead everyone is expected to start work when the previous step is complete, and to do the work as quickly as is prudent.
Subordinate all other resources to it - create buffers. In production a buffer is built-up inventory. In a project the buffer is time. Time buffers belong: (1) between the end of the critical path and the project’s due date (“project buffer”); (2) at the end of any path that feeds into the critical path, between the end of the feeder path and the critical path (“feeding buffer”); (3) between the step prior to one done by a scarce resource and the scarce resource’s step (“resource buffer”); and (4) before a step processed by the organization’s bottleneck (“bottleneck buffer”). The purpose of the bottleneck buffer is to protect the overall performance of the organization instead of just focusing on a single project. To create the buffer for a project that has already been scheduled, instead of giving estimates for the duration of each step that correspond to 90% confidence that you will complete the step in that amount of time, review the critical path and change the estimated duration of each step to correspond to there being a 50% chance of the step being done. The time remaining becomes your project buffer. Do the same for all paths that feed into the critical path.
Elevate - see what you can do to make the constraint not as constrained. Can you add additional resources to the project? Is there work that has been batched together that can actually be split up, only part of which needs to be done before the next step can proceed?If you find a way to elevate, you should see positive change in the system’s performance. If not, you may have elevated enough that it is no longer the constraint, and you need to go back to step 1, identify.
Progress Reports
In classic program management, progress is reported on all efforts, thus it can seem like the project is progressing smoothly even if the critical path (or critical chain) is stalled. This type of reporting motivates project managers to ignore the biggest issues until the very end.
Instead, progress reports should only state progress on the critical path/chain + the whether the buffers have decreased/increased.
Win-Win Situations
According to TOC, there are no win-lose situations, therefore compromises/optimization problems are unnecessary. Instead, what you want to do is reveal the underlying assumptions of a conflict and figure out which assumptions can be falsified. This is done through a diagram called the “evaporating cloud”.
General impressions about the book: I am new to the genre of business novel. If it were not for trying to glean the business concepts discussed, I would not have finished this book, as I was not held by the plot or the character development. On the one hand, reading a novel is more enjoyable than reading textbook. On the other hand, I feel like the essential points could have been given over as a series of blog posts, that would be shorter better written and more engaging. Given that the book was written before the days of blog posts, however this is not truly a fair criticism.
Companies are so immersed in the mentality of saving money that they forget that the whole intention of a project is not to save money, but to make money.
I found it to be an interesting read, even if sometimes clumsily written. It tries to explain/teach about the Theory of Constraints (ToC) in a novel form, which explains the clumsiness.
ToC is also less relevant in the age of Agile/Lean. Companies focus on delivering the value faster and often to the customer. In this context, there's less need for system optimization and finding constraints.
Just read it, whether you’re in project management, tech or industry, so many great wisdoms and help in everyday management as well as bigger projects.
Este libro mantiene la misma línea de pensamiento del uso de las Teoría de las Restricciones en diversos ámbitos de procesos industriales y gerenciales. En este caso Goldratt lo enfoca en la administración de proyectos.
Es un libro novelado, en el que un profesor contratado de una carrera de Maestría de Administración de Negocios (MBA) decide dictar una materia de Administración de Proyectos porque un colega lo convence de que es necesario para su carrera porque debe publicar más artículos técnicos y optar por la plaza permanente en la facultad de negocios como profesor dedicado.
El profesor descubre los conceptos de Teoría de las Restricciones (TOC) en una clase magistral que dicta un colega suyo a distintos presidentes de empresas, y éste a su vez lo aprende de una experiencia de consultoría que practicó en una empresa, en la cual el jefe máximo funge como principal propulsor de que estas ideas se dicten en las academias de pre grado y posgrado de las universidades.
Desde el punto de vista literario, el libro maneja varios hilos o historias que lo hacen bien ameno:
1. El descubrimiento de cómo las TOC se van acoplando a la administración de proyectos en el salón de clases, con casos reales de problemas de proyectos y las posibles soluciones. 2. El problema que tienen las escuelas que dictan MBA con el valor que ofrecen a las empresas, la baja en las matrículas y cómo esta universidad entiende que debe ofrecer contenido que aporte realmente a resolver casos prácticos de sus alumnos gerentes. 3. El drama del profesor protagonista, que está peleando por una plaza de profesor a tiempo completo, que está económicamente frustrado y descubre a lo largo de su clase que las empresas pudiesen pagar muy bien sus servicios de consultor especializado. 4. La construcción de una estrategia entre varios profesores de la escuela del MBA, que al contagiarse se los contenidos y maneras en las que son aplicadas las TOC, deciden aplicarlos en sus ramas de: sistemas, contabilidad, producción, etc.
Entrando en materia, el libro sirve para introducir conceptos nuevos en el ámbito de la administración de proyectos, vinculados con conceptos clásicos como Ruta Crítica, diagrama PERT, competencia de recursos, tasa de recuperación, valor presente neto, entre otros.
Como datos concluyentes a partir de ejemplos duros y prácticos nos deja:
- Cuando se hacen estimaciones con la seguridad de terminar con un 80% de certeza, la banda de protección que agregamos muchas veces ronda el 200% de lo que realmente toma. - La incertidumbre existente en todo proyecto es la principal causa subyacente de la mayoría de los problemas que surgen. - Desde el punto de vista financiero, los excesos en gastos impactan mucho menos que los plazos de tiempos excedidos. - En muchos casos al tratar de disminuir el presupuesto del proyecto, por ejemplo en las procuras, los tiempos de recuperación de la inversión del proyecto se extienden, debido a los retrasos en tiempo causados por desempeño de proveedores baratos. - No existe compromiso posible entre el mundo de los costos y el mundo del throughput. Esto es el desarrollo de buena parte del libro. - No es factible aplicar el principio de Pareto en los proyectos, ya que hay muchas variables dependientes. Pareto funciona mejor cuando las variables analizadas son independientes. - Un problema no se define con precisión hasta que lo vemos como un conflicto entre dos condiciones necesarias. Para resolver el problema, hay que resolver el conflicto, y para resolver el conflicto hay que encontrar y resolver los supuestos incorrectos en alguna de las condiciones. Como práctica, empezamos por analizar la condición que más nos disguste. - En los proyectos tienes tres tipos de mecanismos que están agregando protecciones de tiempo, y que sumándole ocupan la mayor parte del tiempo del proyecto: * Los que añaden protecciones de tiempo basados en sus experiencias negativas. * Los que añaden protecciones de tiempo basado en que alguien ya le puso el suyo. Es decir a nivel gerencial, el gerente le coloca una protección de sobre la protección que ya otro colocó * El tercero es que globalmente, después de las otras dos protecciones, busco protegerme globalmente sobre cualquier recorte que me pidan del gran total, entonces colocó una protección que abarque todo el proyecto.
Llegado este punto, el libro incluye el primer gran dilema:
¿Por qué si hay tantas protecciones incluidas en un proyecto, los proyectos no terminan a tiempo?
Goldratt detalla tres razones que lo pudieran explicar:
1 El síndrome del estudiante: Primero luchas por que te den la protección del tiempo, y cuando la consigues, no empiezas la tarea cuando te toca porque sabes que tienes suficiente tiempo para hacerla. Entonces te comes la protección antes de iniciar la tarea, dejando que Murphy pueda comprometer tus tiempos si llegase a atacar. 2 Tareas múltiples: Cuando una misma área o persona realiza dos tareas de manera simultánea 3 La dependencia entre los pasos: Las dependencias causan que las demoras se acumulen y que los adelantos se desperdicien, porque nadie empieza algo que otro terminó temprano si aún no termina su asignación actual.
Luego el libro nos introduce en las célebres etapas de las TOC con ejemplos prácticos. Estas etapas son: 1 Identificar la restricción del proceso o sistema 2 Explotar la restricción a su máxima capacidad 3 Subordinar todo los demás al rendimiento de la restricción 4 Aumentar la capacidad de la restricción 5 Iniciar de nuevo la búsqueda de nuevas restricciones
He aquí las tres conclusiones principales del libro:
- Analizando un solo proyecto, de forma aislada, la restricción de un Proyecto es su Ruta Crítica, a la cual hay que proteger con amortiguadores de alimentación en los puntos donde las otras rutas confluyen en la Ruta Crítica. Igualmente se debe proteger al final la Ruta Crítica con un amortiguador del proyecto.
- Analizando un grupo de proyectos, la restricción es lo que se define con Cadena Crítica, y es aquella secuencia de actividades que realizan los recursos con competencia a los cuales hay que proteger con un amortiguador de alimentación.
- La Cadena Crítica es igual a la Ruta Crítica siempre que los recursos disponibles al proyecto sean ilimitados. Esto no sucede en la vida real, ya que siempre parte de los recursos están compartidos con otros proyectos y actividades.
Al final del libro el autor deja una idea abierta como para analizar en textos siguientes: El análisis financiero bi-dimensional dinero/tiempo como alternativa a los tradicionales análisis de ROI y Valor Presente Neto para escoger entre opciones de inversión.
I have been talking about Critical Chain in my project management classes for about five years now; however, I have only done so in broad strokes. In my current class, I was asked to expand on it just a bit more. I had never actually read Goldratt's book, but I knew enough about the theory to respond to the kinds of questions I was receiving. Even so, I thought that it was about time for me to read the original. To be honest, I didn't learn anything revolutionary in the book. It may have been a revolution back in 1997 when the book was published, but that is simply no longer the case. Critical Chain still relies on the Critical Path (and I focus a lot of my time in my classes on Critical Path), and it adds to the critical path with the insertion of buffers. I am not a huge fan of buffers; I prefer the use of calculated contingency reserves. I suppose that they're two sides of the same coin. Project management has evolved quite a bit as a profession since 1997, so I don't think I would encourage too many people to rely on this book for new information about managing projects.
This is a book for already competent project managers who want to go to the next level. It doesn't teach the basics at all. But it does have some crucial insights on how to go from mediocre to good.
It's a story of a business professor learning about project management as he teaches--and a good story. And the concepts are really potent--especially for very large projects. For small projects, not as much helpful.
The core idea: there are a few key constraints that the project hinges on. Those need to be watched and helped--including a buffer of safety time. But if that part is done well, all the other parts can drop their need fit safety time as long as there is good communication.
Понравилась и эта книга Голдратта. Как и в других своих книгах автор весьма понятно и доступно доводит до читателей довольно понятные методы и системы управления проектами. Считаю, что концепции решения проблем предлагаемые Голдраттом подойдут практически в любом виде бизнеса, а также и в других видах организаций, даже вплоть до личной жизни. Главное что мне нравиться в книгах автора так это его стиль: просто и доступно о сложном в увлекательной форме. И конечно же рекомендую данную книгу всем управленцам.
Saprast pamatjēdzienus, tad vēlreiz tos saprast, tad izprast idejas kontekstu un novietot to sev aktuālā vidē, un... atrotīt piedurknes un sākt realizēt. Lūk, mans plāns. Idejas realizēšanai, ne lasīšanai un apbrīnošanai. Esmu iedvesmota.
Well written, easy to understand book on interesting topic. Served with easiness that make you think about the topic. Recommended for anyone who deals with any form of project management.
True to style, Goldratt takes his theory of constraints (ToC) and applies it to project management, with some interesting and revealing insights, while taking the reader on a journey of exploration and discovery. He's a master of business novels and he shows it in this case.
This is the third in the 4 main business novels Goldratt wrote. The first introduced ToC, focusing mainly on controlling throughput by controlling bottlenecks and reducing dependence on cost-based efficiency measurements. The second was on logical trees, introducing the idea of the "evaporating cloud" using current and future reality trees to demonstrate that all compromises and dilemmas are logical fallacies and are usually built on false assumptions. This third book was on project management. Here, he introduces the notion of critical chain project management (CCPM), while taking aim at business schools and their overly academic focus, and teaching methodologies, positing instead a social constructionist view.
Quite similar to his style, he made his protagonist's wife (Judith) quite awful and poorly dated. She's quite a horrible character, actually, demanding money and whining incessantly at the character's frugality, while immediately spending thousands on Persian rugs and antique tea sets as soon as she was given half an opportunity. Ugh! But, maybe some people like that...? (Emoji shrug).
The boss, B.J. (there's a name that ages well), was either fair and stuck in a dilemma herself, or a complete savage bitch, depending on the POV. A bit more consistency and balance would have provided a more relatable character there.
However, the idea of CCPM was interesting and fits well with common project management methods, such as PERT and critical path analysis.
Cuốn này mình mua hôm đi đường sách Nguyễn Văn Bình hôm trước; sách cũ mà đắt dễ sợ luôn 😅.
Nói về tác giả Goldratt, ổng thường được biết đến qua "Theory of constraints" (TOC), và các cuốn sách của ông nói về việc áp dụng TOC vào các mảng khác nhau của kinh doanh. Cuốn "Critical Chain" này nói về áp dụng TOC trong quản lý dự án, các cuốn khác như "The Goal" nói về TOC trong quản lý quy trình, còn "It's Not Luck" nói về TOC trong tiếp thị và phân phối.
Sách được đề tựa là "business novel", chính là điểm độc đáo của Goldratt. Các cuốn sách của ông nói về việc áp dụng TOC trong một mặt nào đó của kinh doanh, nhưng luôn được viết dưới hình thức một cuốn tiểu thuyết. Các nhân vật trong "Critical Chain" đến từ nhiều vị trí khác nhau với mục đích khác nhau; có những người đến một công ty công nghệ gặp khó khăn trong việc giữ tiến độ ra mắt sản phẩm mới, có một giáo sư khoa MBA của một trường đại học nhỏ muốn đưa lý thuyết TOC vào thực tế, cũng có những lãnh đạo khoa kinh doanh (business school) của trường đại học trăn trở tìm cách đổi mới chương trình để bắt kịp với nhu cầu thực tế của doanh nghiệp ..v.v. Tất cả tập trung lại trong một chương trình học và cùng nhau thảo luận những kinh nghiệm thực tế về các dự án mà họ đã tham gia, cũng như những khó khăn mà họ gặp phải để giữ cho dự án hoàn thành đúng tiến độ.
Cá nhân mình cũng có thể được tính là làm quản lý dự án (PM). Mình với vài người anh em nhận tư vấn và nhận thầu các dự án nhỏ trong lĩnh vực CNTT và phần mềm, và tình trạng dự án bị chậm thường xuyên xảy ra. Không chỉ mình và các bạn mình mà hầu như ở đâu bạn cũng sẽ nghe nói đến việc dự án bị chậm và quá budget, câu hỏi chỉ là chậm bao nhiêu và quá budget bao nhiêu thôi. Trong cuốn sách tác giả đã nêu ra những vấn đề thường thấy trong quản lý và ước tính cho dự án mà theo kinh nghiệm của mình thì quá chuẩn. Chẳng hạn như để tránh rủi ro, PM thường buffer 200%, ấy thế nhưng dự án cũng vẫn cứ bị chậm, anh em vẫn cứ phải làm thêm giờ (OT). Một trong những nguyên nhân được tác giả chỉ ra trong cuốn sách là "student syndrome", đầu tiên mọi người luôn sợ bị lố nên đòi thương lượng cho thời gian dài ra cho an toàn, thế nhưng an toàn rồi thì mọi người lại không làm hết sức, dẫn đến cuối cùng thì vẫn hụt. Và còn nhiều nhiều ví dụ tương tự nữa.
Chốt lại ai làm PM không đọc sách này quá phí, cá nhân mình thấy bổ ích hơn mấy sách PMP với leadership quá nhiều. Sách tiếng Anh khá dễ đọc, các bạn có thể tìm được ebook trên mạng khá dễ tuy nhiên bạn nên có một chút background về vấn đề sách nói tới (Project Management) thì đọc sẽ thấm hơn rất nhiều.
Подход к управлению проектами на основе TOC описывается достаточно поверхностно. И это поверхностное описание размазано по достаточно скучному сюжету. А концовка, где студенты MBA рассуждают о том, что всё-таки измерять — время или деньги, — вообще неожиданно обрывается. «Измеряйте в долларо-днях», — говорит нам Голдратт.
Вся книга написана ради нескольких простых мыслей:
— Вместо того, чтобы закладывать запасы по времени в каждый этап работ, закладывайте буфер в конце. Как его посчитать — не понятно.
— Вместо управления сроками на каждом участке управляйте конечным сроком и контролируйте запас. Отсутствие локальных сроков сводит влияние «синдрома студента» (откладывание до последнего момента).
— Если у вас есть влияющие работы — аналогично создавайте для них питающий буфер.
— Считайте доходы и расходы проекта. Если надо «ускорить» субподрядчиков — платите им больше.
— Если узким местом является какой-то ресурс, который участвует во многих задачах — выстраивайте весь график работ от загрузки этого буфера. Видимо, если узкое место поменяется, потребуется повторить перепланирование.
Таким образом, PERT-диаграммы для управления проектами не очень подходят (они позволяют видеть зависимости и длительности работ). Диаграммы Ганта, похоже, тоже не очень подходят.
К сожалению, в книге нет ни слова о том, с помощью какого инструмента можно реализовать метод управления с помощью критической цепи или как такой инструмент создать самому. :(
This is a cheesy novel but a nice way to explain the Critial Chain Project Management, which is the transposition of the Theory of Constraints method from manufacturing to project management.
The result is interesting because it's not obvious at all how to translate from the flow of raw materials and pieces going throw a factory to a project that is a process with a finite duration and in which controlling times and costs are paramount.
However, the resulting method, despite being ingenuous seems based on Eliyahu's hunches (e.g. how much the Parkinson Law and the Student Effect are really impacting projects?) and there are some holes like:
* It's not really clear what to do about multiples projects in parallel. There is like a paragraph or two at the end and it's not really well explained * The possibility of the critical path/chain changing during the project is dismissed as something is not normally happening * Resource buffers as explained in the book look difficult to adapt to the case of having multiple interchageable resources
However, I think the book is a nice read because it demonstrated that you can explore ways to manage projects in which there is a chance to hit the delivery date while really managing uncertainty and having feedback to react. I keep wondering what's the right way to manage projects in which you have target completion dates like the ones described in this book while keeping as much of agile methodologies as possible.
Wow, maybe it was because I didn't have any expectations when I started this book that I was so blown away. I didn't go to business school but I have a deep need to improve our production development cycles and a better framework on how to plan and manage our production team. Goldratt provides almost parable-like teaching that we have to analyze and extrapolate for our own purposes. The main thesis for this book in my opinion is that Project management is a blend of both Art and Science, that it doesn't have to be one or the other. In fact, finding this compromise is very much the foundation for the Theory of Constraints (TOC) method that this book is built upon. The layers of character development and relationships seem like they're superfluous but I believe that I will remember the principles of this book even moreso because of the investment Goldratt made into creating these characters. He has a delightful humor as well. I assume that most managers could find someone they could relate to in the book, but the star is still absolutely clear, the professor Richard Silver whom I wouldn't doubt is derived a lot from Goldratt's own life and experiences.
I wish I had someone to discuss the applications of this book for my business but perhaps that's simply reading it with my operations manager.
Bravo and I will definitely be checking out Goldratt's other books.
Mam poczucie, że jestem za słaby to książkę Goldratta. Choć została podana w prosty sposób, niczym thiller psychologiczny w świecie kierowników projektów, to jednak mnóstwo elementów było dla mnie niezrozumiałe i nieoczywiste a forma zaczęła męczyć.
Sam koncept zarządczy autora opiera się na teorii ograniczeń: naukowego podejścia do zarządzania produkcją. Teoria w założeniu jest prosta, bo opiera się na oczywistym założeniu: łańcuch jest tak silny jak jego najsłabsze ogniwo. Jeśli przeniesiemy ideę na proces powstawania produktu to szybko zauważamy, gdzie jest wąskie gardło w scieżce krytycznej produkcji.
Jednak to co się dzieje dalej jest niezwykle ciekawe: jak identyfikować ograniczenia (wąskie gardła), jak je „wyzyskiwać” i jak uzależniać produkcję właśnie od najwęższego gardła. Oprócz tego niezwykle zmyślny sposób budowania buforów w oparciu o poziomy prawdopodobieństwa terminu realizacji zadań i strategię tworzenia i lokowania buforów.
Osobiście jednak brakowało mi podsumowania, które zebrałoby na końcu wszystkie te taktyki w jednym miejscu, wykrystalizowane jak chociażby Agile Manifesto. Bez tego mam problem, żeby w pełni zrozumieć doniosłość tej teorii i praktyki choć (chyba) rozumiem dlaczego było odkryciem w prowadzeniu nietechnologicznych projektów.
Jeszcze nie wiem, co myśleć. Metoda łańcucha krytycznego i poprawy zarządzania projektami wydaje się bardzo logiczna i genialna w swojej prostocie. Chciałbym ją jeszcze skonfrontować ze specami od agile - czy te podejścia się wykluczają, czy może świetnie uzupełniają?
Styl książki początkowo bardzo mi się podobał, ale niestety niedługo później zaczął irytować. Całość - co jest nietypowe dla biznesowego poradnika - napisana jest jako powieść. Zaletą takiej narracji jest większe zaangażowanie czytelnika i naturalność coraz głębszego wprowadzania go w zawiłości sytuacji bohaterów i ich problemów biznesowych. Wadą jest realizacja koncepcji przez autora - niektóre wątki kompletnie nic nie wnoszą, jeśli chodzi o wiedzę biznesową, a styl dialogów niepotrzebnie wszystko komplikuje.
Gdyby z tej książki wydestylować kluczowe założenia metody łańcucha krytycznego, zmieściłyby się one pewnie na mniej niż 10 stronach. Ale takiej książki nikt by nie kupił.