The original concept of the Transition Tree was to "flesh out" the Prerequisite Tree. As Goldratt originally conceived it, the Prerequisite Tree's purpose was only to identify obstacle to implementation and determine ways to overcome them. But besides overcoming obstacles, there are many more activities that usually take place in most implementations. So Goldratt created the Transition Tree to add all that detail. The repeating-structure nature of the Transition Tree (reality, unfulfilled need, action, leading to new reality) made for some ponderously detailed trees. They also inevitably included detail required to satisfy logical requirements that was obvious to most implementers. Moreover, very few FRT injections requiring Prerequisite Trees involved completely new kinds of creative activities---things that had never been done before. In most cases, overcoming obstacles involved doing things that most professionals already knew how to do. They didn't need the "work-task instruction" detail---and the rationale for why they should do each step.
All this became clear to the students to whom I was teaching the thinking process. As I scrutinized their Prerequisite Trees, I found them including some of these necessary-condition task detail that had no particular obstacle associated with it. But to satisfy the format of the Prerequisite Tree, they were contriving "obstacles that weren't really obstacles" just so they could have an obstacle-IO pair for an activity that they intuitively knew needed to be done. And they were reluctant to replicate all that detail AGAIN in the Transition Tree.
So I bowed to the inevitable---or the practical. I started building (and teaching) Prerequisite Trees that had IOs with no associated obstacles, but there were many more total IOs this way. I concluded that if the "new" Prerequisite Tree included IOs to over come real obstacles, plus IOs that were crucial to successful implementation that did not have an obstacle associated with them, most people could execute the Injection directly from the Prerequisite Tree, without needing a Transition Tree at all. Because my students were almost exclusively professionals, they didn't need a Transition Tree to tell them how to do their jobs, or why. All they needed to know was what to do---and the Prerequisite Tree gave them all of that.
Moreover, there was an additional benefit to a "more robust" Prerequisite Tree. If it included ALL the key tasks and activities that needed to be done to implement an injection, the IOs in total represented all the tasks, in sequence, required to manage implementation as a project---in other words, the activity network that forms the basis for a project schedule. This makes the natural follow-on to a Prerequisite Tree NOT a Transition Tree, but a Critical Chain project network.
However, I should emphasize that the "more robust" Prerequisite Tree approach to project network-building is NOT intended for traditional complex technical project tools. It won't replace a Work Breakdown Structure in a construction or development project, for example. But for organizational change? That's another matter. Most organizational policy change---which is really the purpose of the thinking process in the first place---is not conceived by professional project managers, nor is it managed by people with project management experience. It's usually managed by non-project-oriented people with little or no exposure to Work Breakdown Structures, or any of the traditional project management tools. For such people---at whom the thinking process is primarily aimed--converting the "more robust" Prerequisite Tree into a Critical Chain project network, and managing the change as a project, can be an ideal approach.
