How to Change

Outline the tactics which will clarify what needs to happen to achieve the desired state.

Prerequisite Tree: describes the obstacles faced in a Future Reality Tree, and identifies the intermediate objectives required to overcome the obstacles. This tool allows group members to raise their objections to an injection in the Future Reality Tree but requires that the objection is coupled with a remediating action (i.e., “In order to do X, we must overcome obstacle Y by taking action Z”)

Transition Tree: describes actions in a Prerequisite Tree in terms of the need, rationale, and result (intermediate objective). This tool provides a detailed action plan to transition to the desired solution and explains the line of reasoning behind each step. This is most useful when actions are to be taken by people who did not participate in identifying the core problem and its realized solution in a Future Reality Tree.

 

Prerequisite Tree

In attempting to implement the vision of a Future Reality Tree, you may find it difficult to simply inject the proposed changes in a real system. In this instance, a Prerequisite Tree can identify “yes but” objections — ideas that seem simple but are difficult in practice — and the remediating actions to make the injections work in practice.

The Prerequisite Tree is where responsibilities are outlined for implementing proposed changes. This takes the form of obstacles (the problems we face with implementation of an injection) and intermediate objectives (actions needed to overcome obstacles).

 

 

In the above diagram, we cover an obstacle with its intermediate objectives. This indicates (1) that the intermediate objective resolves the obstacle, and (2) that all obstacles must have at least one intermediate objective. This requirement means that anyone who proposes an obstacle must also propose a solution. Also note that an obstacle may require solutions (intermediate objectives) composed of multiple concurrent or sequential steps. For simplicity’s sake, our examples will only show a few intermediate objectives.

Continuing with our software delivery example, we may find it difficult to write automated tests for acceptance criteria. Developers may not be accustomed to writing automated tests in our scenario, as they have relied upon a traditional human QA team. A developer who is accustomed to a traditional manual QA process may not understand how to write automated tests. Additionally, developers may not see the value in writing automated tests if they have never done so before.

In order to overcome these obstacles, we can train developers on writing automated tests and gain buy-in to automated testing by educating developers on the benefits of automated testing.

 

 

The level of detail you need for a Prerequisite Tree depends on the clarity of the team implementing the changes. You may find that stating overall tactics like the above works well enough. Alternatively — especially when taking these ideas to a larger team that has not been involved in the decision making process — you may need to outline talking points for developer team leads, modifying software delivery workflows to accommodate required changes, and so on. Transition Trees exist to turn a Prerequisite Tree into a highly detailed action plan.

 

Transition Tree

Transition Trees are useful when a high level of detail is needed to execute on the plan outlined in a Prerequisite Tree. For example, retraining employees in essential job functions will require more than a list of new workflow steps to be effective: the entire team will need to understand the reason they are executing on the new plan. A Transition Tree outlines the plan of action, need for the plan, rationale for each step in the plan, and the expected results (intermediate objectives). The Transition Tree is most useful for team members who were not involved in the Prerequisite Tree exercise.

 

Continuing with our example, we may need to outline specifically how to train developers on automated testing so they no longer lack the knowledge required to write automated tests.

 

 

In the above, we have a need to write automated tests for acceptance criteria. We can fulfill this need through a few actions: we will provide automated testing tools and frameworks, and demonstrate how to write test cases. It is believed that executing these actions will result in the mechanics of writing automated tests will be known to the development team. Once this result is realized, we will have attained our intermediate objective of training developers on automated testing.