We have used the Cloud method to analyze the problem and to come up with a breakthrough solution-the injection. The solution that we constructed for the problem is checked for win-win, which means that we understand and can communicate the logic that supports the claim that the injection will bring the expected results and a higher performance of the system. Now that we have a potentially good solution, we should take another step-checking, addressing, and removing negative ramifications that may arise after the solution is successfully in place.

When presenting the solution to people who are closely involved with the issue, we may be confronted with Layer 4 of buy-in which stems from the fear that this good injection will also have negative side effects. This is called the NBR. As the logic of the solution is presented as a Future Reality Tree (FRT), the potential negative outcome is called a "branch" as if it was a "bad" branch that is growing to the side of the tree and destroys the nice shape of the good solution.

For daily problem solving, the Negative Branch Reservation (NBR) is used for: 1. Strengthening an injection to a Cloud-when you develop the solution and you feel that it may have some negative outcomes in the future.

2. Preparing and handling perceived negative side effects of an injection-one or more people who are directly involved with the problem and the solution may feel that the suggested injection can have a negative effect on them or their ability to perform their jobs.

Dealing with a Half-Baked Solution

When someone reporting to you suggests an improvement idea that you recognize is a half-baked solution, how do you deal with his suggestion?16 You can't say yes as it is not that good, but you can't say no as you do not want to offend a person who wants to contribute and participate in the process of continuous improvement.

The Process of Handling the Negative Branch

Step 1: Write the injection and its identified possible negative outcome in the form of a logical diagram. Place the injection at the bottom of the page and the negative outcome at the top and check the logic by reading up from the injection: "If [injection] then [negative outcome]."

Step 2: Surface the logical arguments supporting your claim why the negative outcome is likely to happen by stating, "If [injection] then [negative outcome] BECAUSE"

Write down what will follow after BECAUSE as separate entities and decide if each new entity is something that exists now in your reality or something that will exist in the future as a result of this injection.

Step 3: If the new entity states something that will happen as a result of the injection, place this entity in between the injection at the bottom and its perceived negative outcome at the top. Now you are developing the "backbone" or "spine" of the branch. If the new entity states something that exists in your environment already, move straight to Step 4.

Step 4: If the new entity states something that currently exists in your environment, place this entity to one side of the diagram, as this will be one of the assumptions that helps explain the logic of the intermediate entity or the perceived negative effect.

Step 5: Check on the "backbone" from bottom up where the positive injection turns into a possible negative effect.

The structure of the NBR is provided in Fig. 24-16a.

Step 6: Develop a supporting injection to trim the negative outcome and insert it into the diagram.

Step 7: Check that the supporting injection removes the negative outcome.

The outcome of the NBR process is shown in Fig. 24-16b.

Example: Continuation of the fire-fighting story discussed in the section on Clouds.

The Customer Service Manager came with an amendment to the procedure that states that whenever shipment on time is at risk from inadequate delivery location information and the Customer Account Manager is not available, then Shipping Clerk has the authority to contact the customer about this information.

FIGURE 24-16 The negative branch and solution structure.

The manager presented the problem and the proposed injection to his team. The Customer Account Manager who was involved in this incident raised his reservation.

"Yes, but . . . if we adopt this amendment, the customer will perceive me (the Customer Account Manager) as irresponsible and unprofessional."

Step 2: Surface logical arguments for the possible negative.

If [Injection] then [The customer will perceive the Customer Account Manager as irresponsible and unprofessional] because . . .

1. The customer will think that the Customer Account Manager did not pass on all necessary information.

2. The Shipping Clerk will tell the customer that they do not have the delivery information.

3. The customer feels that the Customer Account Manager covered all these details.

Step 3: Build the backbone with entities that will happen.

Entities [1] and [2] will happen as an outcome of the injection and hence they belong to the "backbone." Entity [2] will cause [1] and [1] will cause the negative outcome. The logical sequence of cause-and-effect is: [Injection] [2][1] [Negative outcome].

Step 4: Position existing entities on the side of the backbone.

Entity [3] exists in the current reality and therefore it is a supporting assumption for the causality explaining how entity [2] leads to entity [1].

It reads: IF [2] AND [3] THEN [I].

IF [the Shipping Clerk tells the customer that they do not have the delivery information] AND [The customer feels that these details were covered by the Customer Account Manager] THEN [the customer will think that the Customer Account Manager did not pass on all this information].

Step 5: Check where on the backbone it turns into negative.

The backbone turns negative in entity [1]. Entity [2] this is what is expected to be done by the Shipping Clerk when such situation arises. However, this causes [1] the customer will have the wrong perception about the Customer Account Manager and that is already negative for him.

Step 6: Develop the supporting injection to trim the negative outcome.

Supporting Injection: The Shipping Clerk tells the customer that in order to provide the quickest, best service possible they would like to re-check the delivery information.

Step 7: Check that the supporting injection removes the negative outcome.

"The Shipping Clerk tells the customer that in order to provide the quickest, best service possible they would like to re-check the delivery information" is an action that can trim the negative outcome.

The negative branch for the Customer Account Manager with the trimming injection is provided in Fig. 24-17.

However, it still may not be that great as the customer may be caught by surprise by the unexpected call and may react in an unpleasant way.

An alternative supporting injection could be: The customer is advised in advance that on rare occasions, when the shipping instructions are not clear and the Customer Account Manager is not available (sometimes people are sick or have a personal emergency), the Shipping Clerk may call them to recheck the delivery information.

FIGURE 24-17 An example-the negative branch of the account manager with the trimmed negative outcome.

The customer may agree, disagree, or suggest ways to handle such situations. As this is discussed in advance, no harm is done and whatever is agreed with the customer becomes a part of the amended procedure.

In this section, we have seen that the NBR is another managerial tool that enhances the ability of the manager to deal with challenges-especially those that are perceived to be negative.

The issues that are raised while addressing a potential negative outcome as per Layer 4 may make the managers aware of risks that are unknown to them. On the other hand, through applying the process of dealing with NBRs, it may turn out the reservation is not substantiated and the person raising the concern may decide to drop the reservation.

The Intermediate Objective (lO) Map and Implementation Plans

Implementing an Injection-Dealing with an Ambitious Objective

The last tool of daily use of the TOC TP deals with the question of "How to cause the Change?" For daily problems that are solved by using the Cloud method, the solution is implemented mainly by communicating it to the relevant people. When dealing with fire-fighting problems, the implementation contains two stages: buy-in and the actual amendments to the procedures. When we deal with UDEs (single or multiple), the implementation also has two stages: buy-in and the change to the system or to the offering to the customers.

The implementation of an injection is an ambitious target. Therefore, we need a plan to guide us in the implementation.

There are two inputs to the planning process: Necessary deliverables in the course of the injection implementation to make sure that the injection becomes the reality. These entities are usually obtained by you or other people stating that if you want this injection to work you must do . . . This is when experience or logic suggests clear steps for achieving such changes in reality.

Major obstacles are perceived "show stoppers" that might completely block the ability to implement the injection. This input comes from the "Yes, but . . ." statements that indicate why it is going to be difficult to implement the solution in the area that we discuss. These blockages are handled with the TP that is used for building the Prerequisite Tree (PRT), through determining the IOs that overcome the obstacle.

These inputs are used as the building blocks of the implementation plan.

The Difference between an Obstacle and a Negative Branch

Please note that there is a difference between an obstacle that blocks our way to implement an injection and an NBR that may appear as a side result of implementing the injection. Figure 24-18 illustrates the positioning of the obstacle and the NBR on the time axis of the implementation.

The Process of Addressing Obstacles

The process for addressing obstacles includes: Step 1: Write the injection as a clear and concise statement.

Step 2: Record all perceived obstacles.

Step 3: Identify the "show stoppers."

Step 4: Verbalize the deliverables for the obstacles that you know how to overcome.

Step 5: Develop IOs for overcoming "show stoppers."

Step 6: Group lOs.

Step 7: Create the IO Map for implementation.

FIGURE 24-18 The relationships between NBRs and obstacles.

Step 1: Write the injection as a clear and concise statement.

Example: An injection: A new Information System for Radiology is operational as a part of the new paperless hospital.

For Steps 2 to 5, we recommend working with a table (a Word document or an Excel file) with the following columns: Obstacles Show-stopper Deliverable/IO Blocking Factor Step 2: Record all perceived obstacles usually in the format of "we do not have" or "we do not know."

Example: Obstacle list (partial): 1. We do not have the scope of the implementation.

2. We do not know the acceptance criteria.

3. How do we know the system will be acceptable to all parties?

4. We do not know how to judge the quality of the converted data.

5. The existing servers are nearly full.

Step 3: Identify the "Show stoppers".

Split the recorded obstacles into two groups (know/don't know list): Obstacles you know how to overcome.

Obstacles that you do not know how to overcome-these are the "show stoppers." Put those obstacles that you are sure that if they are not handled they will completely block the implementation of the injection in this category. You can indicate these obstacles by putting "X" in the show stopper column.

Example: Obstacle 3 "How do we know the system will be acceptable to all parties?" is noted as a show stopper.

Step 4: For those obstacles that you know how to overcome, write whatever overcomes the obstacle in the format of deliverables (tangible achievements, necessary in the transition from the current situation to the full use of the injection). These tangible deliverables are in fact IOs that we need to achieve in progression to make the injection a reality. An example is provided in Table 24-10.

Step 5: For those obstacles that you do not know how to overcome (the major obstacles or "show stoppers"), develop the IOs that you need to achieve to overcome the obstruction. Most of the time people who raise the show stoppers have ideas of how to overcome them. You need to examine these suggestions to ensure that they help in removing the obstacles. If the IO is not that clear, you may use the intermediate steps: 1. Identify the blocking factor that causes the obstacle.