Minimal Planning

96-10-24 elyakim@netvision.net.il (Eli S)

Why so many managers do NOT Forecast-Plan-Execute? And instead need to expedite.
Some people may like the activity and excitement associated with the expediting efforts. I don't think they are the majority of the managers.
Planning certainly takes time, especially where projects are involved, and it may look as unnecessary delays - as Tony Rizzo has commented. However, if the value of planning would have been really obvious I dare say that a significant amount of managers were still devote time to planning.
My main argument is: too many managers see no real value in planning.
I speculate that the reason is that planning fails too many times. What's the point of planning ahead of time if the uncertain environment, which includes our mistakes and incompetence to foresee certain events, forces us to deviate from the original plan - ALL THE TIME!
Let me first try to define what I mean by "planning": Planning is making a set of decisions, concerning future actions, ahead of time.
This conflict can be easily shown as a cloud:
A. Objective: To maintain excellent performance
Requirements:
B: Ensuring that all the needed activities will be done according to the required sequence and on-time.
C: Enabling appropriate response to last minute changes and dynamic situations.
The prerequisites for the above requirements are:
D: Plan all the activities.
D': Don't plan, rely on your ability to decide and act on the spot.
Within the procedures of DBR - the TOC methodology for planning the activity at the shop floor - lies an injection to the conflict above. The injection is: Plan only what you really must. Usually it is beneficial to make decisions at the very last minute - so your data is the best you can have. There are two categories of decisions, associated with planning, that I have to make them ahead of time:

When the planning is complex enough - so, if not done ahead of time, it may cause crucial mistakes. Specifying all the necessary conditions falls in that category.
When the decision involves some actions that need to done NOW in order to support the future action. Purchasing decisions generated by the decision to deliver a product/project sometime in the future is such a decision.

That means that effective planning is based on MINIMAL DECISIONS, leaving enough flexibility to face changes and Murphy. Only decisions that have to be made ahead of time need to be taken.
In DBR the planning is focused on only three areas:

The master-production-schedule: when are the deliveries due.
The internal constraint schedule.
The release of materials.

What is NOT included are the non-constraint schedules. That type of decisions are better made on the spot. These decisions are not particularly complex, because you have excess capacity to cover most "sub-optimal" decisions.
In a way, this is the most radical idea in DBR. I think it is more radical than the notion of bottleneck. When a schedule is produced, it seems to shock people who expect to have very detailed schedules for all work-centers.
The principle of MINIMAL PLANNING is more generic than DBR for the shop floor. I have the impression that in project-management the perception is that either you plan the project in detail and have difficult time in updating the plan every week, or, have only a very generic view and start working without a fixed plan and risk delays and high costs. That conflict needs to be solved by defining what decisions really need to be taken early in the process - and what should be left to be decided in real-time. Managing the uncertainty, in this case, means to maintain protection-mechanisms (buffers) to protect the proper execution of the minimal planning.
An over-detailed planning should be regarded as evil as excess inventory. DBR has shown it for the shop floor. A too-detailed budgeting that allocates the exact budget for every clause is damaging in the same way.

96-10-25 YaegerDA.CE.USAFA@usafa.af.mil (CIV Daniel A. Yaeger, 472-4101)

Eli, Great Post!!! I have long suspected that the value of planning lay not in the plan but in what you learned as you went through the process. However, I never truly understood the reason that was so and you have layed it out quite clearly.
If anyone out there has thoughts to contribute to the "principle of MINIMAL PLANNING" I would love to hear them. I would also appreciate a reference if one exists.

96-10-25 rizzo@hogpa.ho.att.com (Anthony R Rizzo)

I too enjoyed reading Eli's thoughts on the subject of planning. I also appreciated the concept of planning what's necessary and not planning what is not necessary. But I feel the strong need to express a negative branch associated with the "principle of MINIMAL PLANNING."
First, I have to draw a distinction between planning and scheduling. Let me provide the following clarity: Planning includes scheduling. But it also includes determining what needs to be done and the sequence in which those things need to be done. After these are at hand, then an appropriate schedule is possible, minimal or otherwise.
In his article, Eli S. made the observation that trying to plan everything in extreme detail is a futile exercise. Eli, did you mean plan or did you mean schedule? To me, these are not the same. Therefore, I would ask you for some clarity.
Now for that negative branch.... In my world (R&D), the levels of uncertainty that we face when trying to create project plans are at least two orders of magnitude greater than anything that exists in manufacturing. Virtually always, there is huge uncertainty in the estimates of task durations. Often, there is uncertainty as to what tasks are even needed.
The response of many engineers and project managers, to this huge uncertainty, has been to PLAN MINIMALLY or not at all. The effects of this approach to planning are not desirable.
I have seen exceptions to the rule. At least one project manager with whom I've worked makes it a point to have the best plan of which he and his team are capable, before the project is begun. On the one occasion when I was a part of his team, we created a plan and a schedule that had only 10 days of buffer for an eight-month project. That happened to be a real R&D project, during which new knowledge was sought and acquired. The project was deemed successful, having finished within two weeks of the planned due-date and having reached its R&D objectives. This was not a critical chain project schedule, since it took place before I even knew of TOC.
My negative branch is that many individuals, who currently use the inevitable uncertainty in all aspects of R&D planning as an excuse to avoid planning altogether, will use this principle of minimal planning as further justification for avoiding much of the planning effort than can bear fruit.
I cannot divulge the benchmarking data that rests next to my keyboard as I type this, because it is proprietary information. But I can say this. A concerted effort to plan projects as well as possible before they are begun can have astoundingly positive effects, even without the TOC paradigm. Again, by planning I mean trying to determine what things need to happen and in what sequence those things need to happen. This is entirely consistent with Eli S' thoughts on planning (or scheduling) only what needs to be scheduled.
The biggest hurdle that most people face, when trying to create a project plan, is that they can't figure out what needs to get done. They have great difficulty in achieving sufficiency with their plans. Often they cannot properly identify the necessities. As a result, many do their best to avoid the planning process completely.
Unfortunately, this has devastating effects. In an organization, the capacity of which continues to be adjusted to match projected needs, it is crucial that the influx of work not exceed the capacity of the organization to do the work. We, TOCers, know that this translates to limiting the influx of work to the rate that the constraint can handle. Project plans that are grossly incomplete cause excessive amounts of work to enter the system, undetected. These undetected tasks create WIP. They choke the R&D system every bit as effectively as physical WIP chokes a factory.
But all hope is not lost. We are fortunate to possess powerful tools with which we can create project plans. Then, we can exploit our TOC scheduling paradigm, to achieve even greater effect.

96-10-25 elyakim@netvision.net.il (Eli S)

I think Tony Rizzo and myself agree about the subject matter of the need to include within the scope of a plan only those decisions that are really needed to be taken at that time frame. Tony says "But the plan and the schedule are not the same things. While the schedule can be all over the map, the plan rarely changes". I think that a schedule is a certain type of a plan. A budget is another type. And there are other types of plans. When Tony says "the plan rarely changes" he means that kind of plan that we both think is necessary. It seems to me that too many people think that the more detailed a plan the better it is. These kind of detailed plans almost never stay fixed. To my view the reason that most plans fail is because the planner had tried to achieve too much and included too many actions that there was no justification to decide upon at that stage. When the plan includes things that can easily change in the future (I call it uncertainty) its inability to materialize becomes apparent and then people say "we told you that it is impossible to plan something like that". What is wrong is the concept of what should be planned and what should not.
In order to eliminate Tony's negative branch, the possibility that people will use the term Minimal Planning to avoid planning the really crucial issues, I suggest to create a format for a project planning. Probably several formats to suit different project management environments. The format should include the decisions that need to be taken - and will clearly state what kind of decisions should be left for later considerations. In other words the plan has to allow for the maximum flexibility that can be maintained without to threaten the objective of the project. I assume Tony has such a format in his mind - for the kind of R&D environment he is linked to. I'm not certain that his colleagues interpret the term 'project plan' in the same way as he does. Implementing a format for a project-plan, coupled with the rationale for such a format (why these decisions are needed and others are better left to later consideration), can force such a planning to be done. If the trouble is that some people are not capable to do proper planning -- then either they could be trained to do that, or you need other people in such a post. When you have a valid format/procedure it is implementable.
A format for project-management planning will have to relate to the time frame. Certain things about the project's final output needs to be specified up-front. No doubt about that. Also, the main milestones and their key outputs. More details need to be specified for the starting period. Later tasks are required to be specified only to the degree that the purchasing activities need to be done soon. The level of detail for the later activities are needed only to verify feasibility and the general assessment of the costs and the key resources needs.
That also means that the planning efforts continues along the project time-frame. This is not the same as "updating the plan". You add to the plan the details for the immediate period.
It is grotesque to see a very detailed Pert for a 5 years project.
These arguments have an impact on the critical-chain method as well. I think the critical-chain is especially valid for multi-projects environment. However, we need to realize that we cannot predict the actual need for resources too far away. The basic logic of TOC leads me to claim that in a multi-project environment only very few resources should be exposed to the possibility of resource contention. These resources are the capacity constraint of such an environment. With some sophistication we can manage projects with 3-4 such critical resources. By the way - these resources need to have some protective capacity, otherwise the total lead-time will be not tolerated by the customers. The rest should have much more excess capacity so the resource contention will cause only very minor delays. The horizon for such multi-project-critical-chain planning should be short enough to be valid most of the time. The mission can be regarded as possible when only the tasks which relate to the 3-4 critical resources are considered.
The wrong concept of detailed planning certainly exists in the software developing area. In many cases the opposite approach of no planning exist is reality - and is wrong in the same way.
A clever plan is one that the execution follows pretty closely. When this is not the case, something is wrong. I suggest to start looking at the possibility of too-detailed and hence redundant planning efforts.

96-10-25 75104.3564@CompuServe.COM (Rob Newbold)

These arguments have an impact on the critical-chain method as well. I think the critical-chain is especially valid for multi-projects environment. However, we need to realize that we cannot predict the actual need for resources too far away. The basic logic of TOC leads me to claim that in a multi-project environment only very few resources should be exposed to the possibility of resource contention. These resources are the capacity constraint of such an environment. With some sophistication we can manage projects with 3-4 such critical resources. By the way - these resources need to have some protective capacity, otherwise the total lead-time will be not tolerated by the customers. The rest should have much more excess capacity so the resource contention will cause only very minor delays. The horizon for such multi-project-critical-chain planning should be short enough to be valid most of the time. The mission an be regarded as possible when only the tasks which relate to the 3-4 critical resources are considered.
For me, the purpose of any project plan is to develop and communicate understanding of the project. When you try to communicate understanding that you don't have, you are communicating misunderstanding, and this is just a bad idea. To arrive at the appropriate level of detail for a plan, you must clarify up front the objectives of both the project and the plan. Even this crucial step is often left out.
I think predicting approximate resource requirements is often quite important, even beyond "valid most of the time." You need to predict them in order to predict project durations. You definitely need them if you wish to ensure that very few resources are exposed to the possibility of resource contention. The key is to remember not just what you do know, but what you don't know. Most people are not very comfortable with that.
Protective capacity is another interesting subject in project environments. I've seen plenty of places where management tries to load key people to 100%, then assumes there will be time for meetings and committees on top of that. If they are willing to put in 60- or 80-hour weeks, that can work, for a while. I agree that it's a good idea to have a policy that no one should be booked to 100% with high priority tasks. It doesn't have to be such a big paradigm shift; there are usually plenty of useful things people can do which not high priority.

96-10-26 LaHir@aol.com

There was a principle used in sociotechnical systems design called "identify the minimum critical specifications" which I think conforms closely to Eli's minimal plan concept
I agree with Eli that the most important contribution of DBR or TOC for that matter is that you have to only plan in reference to the constraint. But it is not always that simple . Perhaps we should distinguish between first and second order planning. Many times individuals and organizations turn to planning (as opposed to scheduling) activities when a) they have yet to define a goal b) the constraint has changed not because it has shifted but rather because the system itself, the relationships that govern when and why a part becomes a constraint are changing or need changing. This is similar to the classic distinction between "risk" and "uncertainty." The former linked to Murphy's law is minimized when DBR is used. For the latter there is no probability distribution that can be a priori known. People however find that planning under conditions of uncertainty, as opposed to risk, is very difficult. No one has really designed good techniques for it (e..g forecasting, scenario planning., prototype design etc.) so they don't really now how to do it.

96-10-26 anders.claesson@mailbox.swipnet.se (Anders Claesson)

First of all I would like to thank Eli S who wrote:
In a way, this is the most radical idea in DBR. I think it is more radical than the notion of bottleneck. When a schedule is produced, it seems to shock people who expect to have very detailed schedules for all work-centers.
I agree, I'm currently involved in an effort trying to re-focus a large scale product development program. One aspect of this is to make use of MINIMAL PLANNING (but I didn't know this name before). One of the reactions we constantly face is the one described above.

Why does this shock people in the work-centers? and
Does anybody have a clue on how to explain the benefits of the new approach to the work-centers?

An over-detailed planning should be regarded as evil as excess inventory. DBR has shown it for the shop floor. A too-detailed budgeting that allocates the exact budget for every clause is damaging in the same way.
I agree and I think we have experienced exactly that. I think that is one of the drivers for our effort to try to re-focus and use minimal planning. The connection to the budget process was new to me but seems to be a very interesting thought.
Thanks also to Tony Rizzo who provided a complementary picture of this from what is also my world (R&D). Tony wrote:
Now for that negative branch.... In my world (R&D), the levels of uncertainty that we face when trying to create project plans are at least two orders of magnitude greater than anything that exists in manufacturing. Virtually always, there is huge uncertainty in the estimates of task durations. Often, there is uncertainty as to what tasks are even needed.
I again agree regarding the possible negative branch. However, to me the crucial issue is to really work through WHAT and IN WHAT SEQUENCE things needs to be done. Also, some mechanisms to account for the uncertainties need to be included.
That seems to be the case in the example that Tony gave regarding a successfully planned and executed project. From what I understand this planning was done as a TEAM EFFORT which included enough competence and experience to in advance figure out the essential steps in that project. In doing so, I guess a lot of the uncertainties were thought about and some of them reduced as well as taken into account in doing the planning.
I guess that the KEY here is to figure out the balance between WHAT to plan in advance and what to leave for later local "planning".
To my mind you could not equal NO PLANNING (or lazy planning) with MINIMAL PLANNING, since in the latter I include that it still have to be validated towards its ability to produce the expected results.
Also Rob Newbold contributed some very insightful comments on this. He wrote:
For me, the purpose of any project plan is to develop and communicate understanding of the project. When you try to communicate understanding that you don't have, you are communicating misunderstanding, and this is just a bad idea. To arrive at the appropriate level of detail for a plan, you must clarify up front the objectives of both the project and the plan. Even this crucial step is often left out.
To me this seem to be an excellent way to obtain a reasonable balance in the plan.
The key is to remember not just what you do know, but what you don't know. Most people are not very comfortable with that.
This is probably a very important key issue to keep in mind. But, how do you account for this in a plan?
This conversation have helped me in two ways:

It brought confidence in that we are addressing the right things and hopefully also in the right way.
It highlighted some more important aspects that I will need to consider further.

My real challenge is to figure out how to plan an execute the plan in an environment with project times >3 yrs, where there are a lot of parallel threads (>50) that need to be synchronized in order to achieve the end results.

96-10-28 lleach@srv.net (Larry Leach)

These arguments have an impact on the critical-chain method as well. I think the critical-chain is especially valid for multi-projects environment.
Clarity reservation?
However, we need to realize that we cannot predict the actual need for resources too far away. The basic logic of TOC leads me to claim that in a multi-project environment only very few resources should be exposed to the possibility of resource contention. These resources are the capacity constraint of such an environment. With some sophistication we can manage projects with 3-4 such critical resources. By the way - these resources need to have some protective capacity, otherwise the total lead-time will be not tolerated by the customers.
Your point on the limited number of constraints is good and interesting. We need to think this through a little more; and understand what to do it about it. I guess the issue really is what kind of commitment do you have from the resource supplier, and how do you get it?
The AGI method includes three schedule buffers:
a) The Critical Chain Completion Buffer (at the end of the project),
b) Critical Chain Feeding Buffers (at the end of paths that feed the critical chain), and
c) Critical Chain Resource Buffers.
Critical Chain Resource Buffers are not 'really' time buffers. That is, they do not take up critical chain time. They are a commitment to provide the resource as soon as demanded, and to work it at full capacity for the activity duration. They are a 'readiness to supply' contract. In some cases, you need to pay for this, which is fine.
One of the changes in Critical-chain project management is that we manage activities to durations, not to milestones. How else do we take advantage of the activities that get done in less duration than estimated?
You also need a $ buffer. Like the Critical Chain Completion Buffer, we need to take this out of the individual activity estimates in order to take advantage of the reduced variance of the sum of variances.
For me, the purpose of any project plan is to develop and communicate understanding of the project.
That is a purpose. There often are others. Such as getting the project approved, identifying long lead time resources, etc.
I think predicting approximate resource requirements is often quite important, even beyond "valid most of the time." You need to predict them in order to predict project durations. You definitely need them if you wish to ensure that very few resources are exposed to the possibility of resource contention. The key is to remember not just what you do know, but what you don't know. Most people are not very comfortable with that.
How do we estimate the cost of a project without 'predicting' the resource needs? How does any manager approve a project without knowing the cost? How do you know the cost without resources?
Protective capacity is another interesting subject in project environments. I've seen plenty of places where management tries to load key people to 100%, then assumes there will be time for meetings and committees on top of that. If they are willing to put in 60- or 80-hour weeks, that can work, for a while. I agree that it's a good idea to have a policy that no one should be booked to 100% with high priority tasks. It doesn't have to be such a big paradigm shift; there are usually plenty of useful things people can do which not high priority.
Just saw a great Dilbert on this. 'Cathy, its our company policy That you have take your vacation." Something like, "But you have me on a seven day per week priority project, and have all year." Anyone want to resolve this cloud?

96-10-31 rizzo@hogpa.ho.att.com (Anthony R Rizzo)

Just saw a great Dilbert on this. 'Cathy, its our company policy That you have take your vacation." Something like, "But you have me on a seven day per week priority project, and have all year." Anyone want to resolve this cloud?
(A) maintain family harmony and family income.
(B) do what's right for the company.
(D) not take vacation
(C) do what's right for me and my family.
(D') take vacation
I've seen examples of this Dilbertesque policy. After a few exposures to such inane policies, most people resolve this conflict in favor of taking the vacation. They recognize that the (A-B) assumption that they'll be fired for doing what they're told to do is false.