Embed Size (px)
Citation preview
Goldratt’s TOC Golden Nugget #15Eliyahu M. Goldratt © 2009
Freezing in projects
The significance of freeze:
As we all are very well aware, bad-multitasking is a big sore evil that has major negative effects on performances in any environment, and in particular in projects environment. To diminish bad-multitasking in projects environment we use, as an integral part of the Critical Chain Project Management (CCPM) solution, the freeze mechanism. This is the hardest step to get collaboration for. If we wish to get the full collaboration of all relevant functions on the freeze - and at the same time to accelerate performance - it behooves us to sharpen our understanding regarding the freeze mechanism.
To freeze projects, the two main functions whose collaboration we seek are the project manager and the resource manager. In choosing to stress only the impact of bad-multitasking on lead time, as we have mistakenly done so far (see nugget #16 that discusses bad-multitasking), we are not addressing a real concern of the resource managers; a resource manager is focused on making a good job on his team’s tasks, and is naturally less concerned about the total time it takes to complete a project. This point of reducing project lead time is much more relevant to the project managers who have the responsibility of finishing their projects on time; but even they are not hurrying to agree to freeze projects, because of the fear from damaging the progress of the projects which will be frozen. Therefore, a normal respond of project managers is: “reducing bad-multitasking through freezing is great, as long as you are freezing someone else’s projects and not touching mine”.
It stand to reason that explicitly stressing the fact that bad multitasking devours capacity would lead to getting the active support of the resource managers, and reduce the resistance of the
The TOC Golden Nuggets are being created as part of Goldratt Consulting’s implementation experience. As such their intended use is to share TOC implementation insights. Their content cannot be altered, posted or copied by any means or form without an explicit authorization from the copyright owner.
www.goldrattconsulting.com Eliyahu M. Goldratt © 2009 [email protected]
project managers. For starters, the resource managers’ demand for more people is prevalent in almost every department in multi-projects environment. Therefore when they realize that if we would only diminish bad-multitasking, the impact is the same as adding considerable number of people (without the need to introduce them into the projects) they are more than likely to push for the actions that will reduce bad-multitasking. It will also have an effect on the project managers, especially in multi projects environments, where they are constantly fighting for allocating the recourses to work on their projects. Once a project manager understands that reducing bad-multitasking means a large increase in the availability of the resources, he is more inclined to accept that he will enjoy the benefits - even if his project is initially frozen. In summary, stressing the benefits of the freeze in terms of gaining capacity has a much higher chance of turning the resource managers, and many of the project managers, to collaborators that are keen to reduce bad-multitasking.
The freeze mechanism:
We tend to regard the freeze mechanism as the action of freezing projects. This view is too narrow. In order to clarify the broader picture, it might help to inspect an environment that has one big single project. No one would suspect that such environment is free from bad-multitasking - after all, most resources have to work on more than one task in the project. Here, too, we wish to diminish bad-multitasking; but clearly, the mechanism of freezing projects is not suitable here. So are we left without any mechanism for reducing bad-multitasking? Actually we do have such mechanism that is in use as an integral part of CCPM, only we did not title it ‘freeze’.
In a big project there is one critical path and many non-critical paths (legs). A non-critical path has, by definition, a slack of time in which it can start - between its “early start” and “late start”. In the literature on the subject, the described damage of starting later than the late start is, of course, jeopardizing the project completion on time. What about the damage of starting sooner (closer to the early start)? According to the literature, the only downside in starting early is that it necessitates an earlier investment. The natural practice stemming from this conventional view is that unless early investment is a big concern (which, many times, is not the case) it is
The TOC Golden Nuggets are being created as part of Goldratt Consulting’s implementation experience. As such their intended use is to share TOC implementation insights. Their content cannot be altered, posted or copied by any means or form without an explicit authorization from the copyright owner.
www.goldrattconsulting.com Eliyahu M. Goldratt © 2009 [email protected]
considered better and safer to start close to the point of early start (especially when we take into account that as a result, “better progress” on the project can be reported).
But there is a much bigger risk in starting too early, a crucial downside that this conventional view ignores: an early start leads to many open tasks, resulting in bad-multitasking - and killing capacity. Apparently there is a real conflict regarding the starting point of a leg.
The CCPM solves this problem by taking the available safety time, aggregating it so it will not be wasted, and placing it where it is needed, using project buffer and feeding buffer; then, based on these buffers, CCPM provides (with the help of software) a time schedule for releasing the different project legs. The safety (that is now inherent in the schedule) protects the project from being late, and there is no reason to take more “safety” and release the project legs earlier than is determined according to the buffers. Releasing legs earlier than scheduled would create damage by wasting capacity due to bad-multitasking. Obeying the CCPM release schedule is clearly another way of freezing. This is a second freeze mechanism, a freeze on the project legs level (instead of on the project level). This mechanism obviously has the utmost importance in environments of single or few projects, but it has a major importance also in multi projects environments, affecting bad-multitasking sometimes not less than the freeze on the project level.
But there is a non trivial obstacle in implementing this leg-level freeze mechanism. The leg release schedule is determined in light of both the project buffer and the feeding buffer. Except for very small projects, this scheduling is not a triviality, and it necessitates the use of appropriate software. At the same time, there is a very important guiding rule for designing a project’s PERT - a strict warning not to include more than 300 tasks in a PERT, no matter how big the project is; we have learnt that otherwise the over detailing is in the noise, and causes losing control of the project. This means that in big projects (comprises of more than 300 legs) the allowed level of detailing creates a situation where a single step in a PERT might contain quite a few different legs. This situation prevents us from getting an appropriate release schedule for the project’s legs; hence in big projects we are underutilizing the leg-level freeze mechanism, and thus are likely to still have too much bad-multitasking.
Apperantly, we might still suffer from bad-multitasking even after applying the freeze mechanism both in the project level and in the legs level. In search for a way to further reduce bad-multitasking, an obvious direction of thinking considers whether the concept of freeze is
The TOC Golden Nuggets are being created as part of Goldratt Consulting’s implementation experience. As such their intended use is to share TOC implementation insights. Their content cannot be altered, posted or copied by any means or form without an explicit authorization from the copyright owner.
www.goldrattconsulting.com Eliyahu M. Goldratt © 2009 [email protected]
applicable in yet another level. It is not hard to realize that there is indeed room for a third level of freeze mechanism - freeze in the department level. Freeze in the department level means that even if a leg has been released by the software’s schedule, it does not suggest that the department has to start working on it. This level of freeze is not needed in each and every department; it is necessary only in the departments that still suffer from bad-multitasking (and rest assured, there are quite a few).
How can we locate the departments that suffer from bad-multitasking? Easily; since a part of the definition of bad-multitasking is “being disturbed in the middle of a task in order to go and work on another task”, one can check for bad-multitasking by asking two simple questions: 1. roughly, how much time does it take to complete a task in the department? 2. per worker in the department, how many times a month he is instructed to stop what he is doing and to switch to another, more urgent task? According to the two answers one can tell how often workers are forced to multitask. For example, if the time to complete a task is 4 days and a worker is instructed to switch between tasks 6 times a month, it means that on almost each and every task the worker is forced to multitask at list once. This department definitely suffers from bad-multitasking.
After reaching the conclusion that there is indeed too much bad-multitasking in the department, comes the obvious next step - diminishing the bad-multitasking. This is also quite simple: verify with the resource manager that he has the list of tasks that the department has to do (a list which he surely has). Now, simply inform the resource manager that he has to freeze at least 25% of the tasks under his control, and that he is free to choose which of the tasks to freeze; resource managers have a great intuition regarding the priorities of the different tasks under their supervision - they know very well which tasks, if frozen, would cause someone to raise hell. Be sure to notify that they will be checked every day so they better freeze as required, and stress that if anyone will be found working on one of the tasks that were declared “frozen”, management will not be happy.
You may have noticed that we chose to use here an approach that is not typical to TOC - force the change. Why do we allow such harsh dictation in this case? What happened to communication, to overcoming resistance to change? We do not intend to overshadow neither communication nor the conviction in the taken actions. But they are not mandatory in this unique case, since the one that resist the change is going to enjoy the fruits of the change in no
The TOC Golden Nuggets are being created as part of Goldratt Consulting’s implementation experience. As such their intended use is to share TOC implementation insights. Their content cannot be altered, posted or copied by any means or form without an explicit authorization from the copyright owner.
www.goldrattconsulting.com Eliyahu M. Goldratt © 2009 [email protected]
time: in about a week into the change, the resource manager realizes that suddenly the tasks are running much smoother and faster than before, and many more are rapidly completed. This unavoidably turns the resource manager from an objector into the biggest advocate. Early experience shows that, now when a resource manager had witnessed the benefits of reducing bad-multitasking, he will voluntarily freeze an even bigger portion of his tasks.
Lately this solution was tested in a big engineering company that was using CCPM for years. It was revealed that two thirds of the departments were still suffering from bad-multitasking. At these departments, the resource managers were first forced to freeze 25% of their tasks. Nevertheless, after merely one week, there wasn’t any department with less than 40% frozen tasks, and some went to the extent of freezing 80% of the tasks. This shows how fast the conviction came and how strong it was. And not before long it became clear that the feeling that everything runs smoother was not only an intuitive hunch: the real, amazing evidence for the improvement came to light after two or three weeks, when the data regarding the output of the departments was revealed: the number of tasks a department completes per week has doubled. Within two months the output of that business unit (in terms of projects completed per month) was doubled, and the enthusiasm enabled a re-launch of full proper implementation of the corresponding S&T tree.
In this case, the way of dictation is quicker and requires less hassle than spreading the logic and patiently convincing, but be careful of using it in other situations, for dictation is rarely a good idea.
* * * * *
The following concern might be raised: what happens in case a resource manager, in spite of the good intuition, has frozen an important task that should not have been frozen? A task is important only in perspective of the whole project. An important task that should not be frozen is a task which its delay is reflected in a significant penetration into the project buffer. The solution for projects includes a mechanism to notice such tasks and increase their priority. In short, there is a quick correction mechanism for cases of mistakenly freezing an important task; however, there is no quick mechanism that does the opposite and freezes less important tasks to protect from bad-multitasking. That is why the solution presented here is so important.
The TOC Golden Nuggets are being created as part of Goldratt Consulting’s implementation experience. As such their intended use is to share TOC implementation insights. Their content cannot be altered, posted or copied by any means or form without an explicit authorization from the copyright owner.
www.goldrattconsulting.com Eliyahu M. Goldratt © 2009 [email protected]
And what about cases where the mentioned correction mechanism is not yet in place? Should the freeze in the department level be postponed due to the fear of choosing the wrong task to freeze? The answer is - definitely not! The risk in accidentally freezing an important task is not high, especially when taking into account that such cases are likely to be detected within a reasonable time, even without a proper correction mechanism. Considering that the benefits of this freezing mechanism are so significant, it is imprudent to put it on hold because of such relatively minor concern.
The TOC Golden Nuggets are being created as part of Goldratt Consulting’s implementation experience. As such their intended use is to share TOC implementation insights. Their content cannot be altered, posted or copied by any means or form without an explicit authorization from the copyright owner.
www.goldrattconsulting.com Eliyahu M. Goldratt © 2009 [email protected]
TOC Tools for Project ManagementThe Goldratt Strategy & Tactics for Project Management - GST CCPMA step-by-step resource on How To implement CCPM. As Strategy and Tactic was created to show all necessary steps along the process, it presents the implementation in a logical, common sense way such as found in The Goal. Meant to address any concerns, the logic presented by Dr. Eli Goldratt is thorough and leaves little room for misunderstanding. Formats: DVD or Online Streaming.Languages: English, Spanish and Portuguese.http://www.toc-goldratt.com/gst/ccpm
GSP on Project Management and Engineering - Critical Chain (CCPM) and Product DevelopmentProjects (especially in multi-project environments) have characteristics which drastically differentiate them from production. Listen in 2.5 hours as Dr. Goldratt presents what to change (the problem) and what to change to (the solution) in order to finish projects ahead of time, within the allotted budget and without compromising on the content. This tool is ideal for a company implementation and can be used for an unlimited number of users and viewing.Formats: DVD or Online StreamingLanguages: English, Spanish, Czech, Portuguese, Russian, Estonian, Chinese Simplified and Chinese Traditional.http://www.toc-goldratt.com/gsp/3
TOC - Self Learning Program on Project Management and Engineering This tool is designed for a single-user, it allows the individual to learn about CCPM and study the material over and over at their own speed. Dr. Goldratt explains the core conflict in project management, being caught between a rock and a hard place, and then he reveals the TOC solution, providing ways to stop bad multi-tasking, and how to schedule and set priorities with Critical Chain and buffer management.Format: CD-Rom Languages: English, Spanish, Czech and Portuguese.http://www.toc-goldratt.com/slp/3
TOC Insights into Project ManagementThis session will deepen your understanding of Critical Chain Project Management. Created by Dr. Goldratt and Rami Goldratt, the TOC Insights program is organized to answer in sequence the following five questions:Why to change?, What needs to be changed?, What to change it to?, How to cause the required change? , and How to keep it as a Process of Ongoing Improvement (POOGI)? This tool is ideal for individuals and/or groups, and can work independent of or in tandom with the accompanying TOC Self Learning Program sessions.Formats: Download, Online, Client-Server Languages: English, Spanish, Chinese, Czech, German, Hebrew, Japanese, Korean, Portuguese, Polish, Russianhttp://www.toc-goldratt.com/toc-insights/3
More about Project Management in https://www.toc-goldratt.com/category/Project-Management
