Maximizing Profitability Part 33

Earlier we demonstrated how by simply eliminating multi-tasking, significant gains can be made in project completion rates, but we still have to address the impact of the Student Syndrome and Parkinson’s Law. We know that both of these behaviors work to lengthen the time required to complete projects. Remember how excess safety is imbedded into traditional project management plans? Resources estimate task times and add in their own protection against disruptions caused primarily by Murphy. Knowing that this safety exists, resources then delay starting work on their tasks until the due date is close. Even if the resources don’t delay the task starts and finish early, these early finishes are not reported and passed on. So how does CCPM deal with these two behaviors?

While CPM relies on individual task durations as well as scheduled start and completion dates, CCPM does not. The focus is no longer on finishing individual tasks on time, but rather starting and completing these tasks as soon as possible. So how does this work? Like CPM, CCPM still gathers estimates on individual tasks and identifies its own version of the Critical Path. Unlike CPM, CCPM considers competing resources (i.e. the same resource has to work on different tasks) and makes them a part of the critical path. Let’s look at an example of how CPM and CCPM identifies the critical path.

CPM defines the critical path as the longest path of dependent tasks within a project. That is, tasks are dependent when the completion of one tasks isn’t possible until completion of a preceding task. The critical path is important because any delay on the critical path will delay the project correspondingly. The figure below is an example of a series of tasks which must be completed in a project with the critical path highlighted in grey. Traditional project management determines the critical path by looking at the task dependencies within the project. Task A2 can only be initiated after A1 is completed. Task B3 can only be performed after completion of B2 and C2 only after C1. Task D1 can only be performed after completion of A2, B3 and C2. Using CPM the critical path would have been identified as C1-C2-D1 and the project completion estimate would have been 29 days (i.e. 8d+12d+9d).

In addition to task dependencies there are also resource dependencies that CPM fails to recognize. What if, in our example, tasks A2 and B3 are performed by the same resource? Is the critical path different? In the figure below we see the new critical path that includes a provision for resource dependencies and as you can see the new critical path is 5d+10d+10d+9d or 34 days. So the minimum time to complete this project is now 34 days. In our opinion, the failure to consider resource dependencies is one of the key reasons why project completion rates are so terrible. The simple implication of incorrectly identifying the critical path, which we will now refer to as critical chain, is the project team will never be able to complete their project on time without heroic efforts, adding additional resources, overtime or a combination of all three. The practical implication of incorrectly identifying the real critical chain is that the focus will be on the wrong tasks. Is this any different than focusing on non-constraints in our earlier discussion on TOC?

We said earlier that safety is imbedded within each task as a way to guard against the uncertainties of Murphy. Critical Chain takes a completely different approach by assuming that Murphy’s uncertainty will happen in every project. Unlike CPM, CCPM removes these safety buffers within each task and pools them at the end of the project plan to protect the only date that really matters, the project completion date. There are many references that explain the details of how CCPM does this, but here’s a simple example to explain it. Basically we have removed all of the protection from individual task estimates which we estimate to be 50 % of the original estimate. The figure below demonstrates the removal of this safety. So now, the length of the critical chain is no longer 34 days, but rather 17 days. But instead of just eliminating the safety buffer, we want to place it where it will do the most good…..at the end of the project to protect the due date. This isn’t exactly how this works, but for presentation purposes to demonstrate the theory behind CCPM it will suffice.

The figure below is this same process, but this time the safeties that we removed are added to the end of the project to act as a cushion to Murphy’s inevitable attach. So the question now becomes, how do we utilize this buffer and how does it improve the on-time completion of the project?

Suppose task A2 takes 7 days instead of the 5 days that are in the plan? In a traditional project management environment, this would be cause for panic. In a CCPM environment we simply consume two days from the project buffer and we’re still on schedule. Suppose now, for task B3, we only take 3 days instead of the planned 5 days. We simply add the gain of 2 days back into the project buffer. In traditional CPM, delays accumulate while any gains are lost. This is a significant difference! The project buffer protects us from delays. For non-critical chain tasks, or subordinate chains such as C1-C2 from our example, we also can add feeding buffers to assure that they are completed prior to negatively impacting/delaying the critical chain.

One of the key differences between CPM and CCPM is what happens at the task level. In traditional project management each task has a scheduled start and completion date. CCPM eliminates the times and dates from the schedule and instead focuses on passing on tasks as soon as they are completed, much like a runner in a relay race passing the baton. This function serves to eliminate the negative effects of both the Student Syndrome and Parkinson’s Law from the equation and permits on-time and early finishes for projects. In order for this to work effectively, there must be a way to alert the next resource to get ready in time.

In my next blog posting, we’ll discuss how Goldratt’s 5 Focusing Steps apply to project management and how we track progress on both CPM and CCPM to demonstrate why CCPM offers a much more reasonable way to do so.

Maximizing Profitability Part 32

In my last blog posting we talked about Parkinson’s Law (i.e. Work expands to fill the available time), the Student Syndrome (i.e. procrastination or delaying work on a task because we know there’s safety time imbedded in our estimate) and multi-tasking (i.e. jumping from one project to the other) and how each one extends the time required to complete projects. Although eliminating multi-tasking improves our on-time completion rate, there are other things that can be done to improve these rates even more? Let’s take a look.

As we’ve seen, in CPM task durations are inflated to protect against Murphy’s untimely attacks. What if we could significantly reduce these imbedded safety buffers and still provide the protection that we need? In our example from the figure below, suppose we were able to reduce the estimated duration by 50 % and still protect against Murphy. In other words, if we could complete the tasks in 5 days instead of 10 days, wouldn’t this be a quantum leap in project completion time reduction?

The figure above is a depiction of the reduction in durations of each project. We have just reduced the time to complete these three projects from 30 days to 15 days, but can we do this and safely guard against the uncertainty introduced by Murphy? The answer is, yes we can! But before we explain how to do this, we want to introduce (or re-introduce to some of you) something called the Theory of Constraints (TOC).

TOC came on the scene in the mid-1980’s through its developer, Eli Goldratt. Goldratt taught the world that every organization has at least one (and usually only one) constraint that prevents an organization from coming closer to its goal. And for most companies, the goal is to make money now and in the future. In fact, Goldratt analogized this concept to the strength of a chain being dictated by its weakest link.

In a manufacturing environment, TOC presumes that only one work station, the one with the least capacity, dictates the throughput of the process and to operate all stations at maximum capacity will only serve to create excess inventory in the process. This excess inventory increases the lead time and wastes resources. The best way to understand TOC is to envision a simple, repeatable process as in the figure below.

In our example, Step 3 at 7 days is the slowest resource since it requires 7 days to complete it, whereas all of the others require much less than 7 days. Therefore the maximum throughput of the process in the above figure is 1 unit of product (or service) every 7 days. TOC identifies Step 3 as the constraint and tells us that if we want to improve throughput, then we must focus our improvement efforts on this step.

The question you might have in your mind right now, is why bring up the Theory of Constraints (TOC) when we’re talking about Project Management. The answer is quite simple. TOC recognizes the existence of a constraint and this recognition in a project management environment is absolutely critical to shortening the time required to complete projects.

TOC teaches us that the first order of business is to define your Goal. In a single project, the goal is identified as making the promised project due date while in a multiple project environment, the goal is to maximize the throughput of projects. So how do Goldratt’s 5 focusing steps apply to project management?

Goldratt’s 5 Focusing Steps:

1. Identify the system constraint.

2. Decide how to exploit the constraint.

3. Subordinate everything else to the constraint.

4. If necessary, elevate the constraint.

5. Return to step 1, but don’t let inertia create a new constraint.

Good question and in my next few postings, I will demonstrate how each of the 5 steps apply to a project management environment as well as introducing TOC’s version of project management, Critical Chain Project Management (CCPM).

Maximizing Profitability Part 31

So the question I left you with in my last posting remains…..if individual project tasks have so much extra time imbedded in them, then why are so many projects coming in late? We think that this is partially explained by two common human behaviors. Resources know that they have built “safety” into their tasks, so they often delay work on the task until much later than they had originally planned. Think back to your high school days. When you were given a due date for a paper for say, next Thursday, when did you actually start working on it? Wednesday? Eli Goldratt coined the term, the Student Syndrome, to explain one of the reasons why the apparent built-in safety gets wasted. When the task start is delayed and Murphy strikes, the task will be late.

Another human behavior that lengthens projects is referred to as Parkinson’s Law. Resources intuitively know that if they finish a task in less time than they estimated, the next time they have the same or a similar task to complete, they will be expected to finish it early also. So, to protect against this, even thought the task is finished early, the resource doesn’t notify the project manager that it is finished until the original due date. After all, we’re talking about credibility here, so to protect their credibility, early finishes aren’t reported. Parkinson’s Law states that work expands to fill the available time, so resources use all of the available time. The key effect on projects, of these two behaviors, is that delays are passed on, but early finishes aren’t. So is it any wonder that projects are late?

While these two behaviors negatively impact project schedules, there are other reasons why projects are late. Many organizations today have multiple projects going on at the same time and it’s not unusual for projects to share resources. In fact, many project managers tend to “fight over” shared resources because they believe their project is the one that has the highest priority. Another significant problem is that in many project based companies, leadership initiates projects without considering the capacity of the organization to complete the work. Leadership also mistakenly assumes that the sooner a project is initiated, the sooner it will be completed. As a result, perhaps the most devastating problem of all associated with project completion occurs……multitasking! But wait a minute….I thought we’d all been taught for years that multitasking is a good thing?

Multitasking happens when resources are forced to work on multiple project activities at the same time. Like we’ve always said, humans aren’t very good at rubbing their tummy and patting their heads at the same time. Many people believe (especially in leadership positions) that multitasking is a good thing because it increases efficiency since everyone is “busy” all of the time. If you’ve ever to read The Goal by Eli Goldratt (if you haven’t, you should), you might remember how focusing on local activities actually damaged the overall system performance. You may also recall how Goldratt used his robot example whereby running the robots continuously, efficiency did improve, but at the expense of creating lots of excess inventory.

The negative impact of multitasking in a project management environment is much, much worse. Let’s look at an example. Suppose you have three projects,as demonstrated in the above figure, that you are assigned to and in each project you have estimated that you have 2 weeks (10 days) of work on each project for the tasks assigned to you. Assuming Murphy didn’t strike, if you started and finished Project 1 without stopping or working on any other project, it would be done in 10 days. Ten days because that’s what you told everyone it would take (Parkinson’s Law). Likewise for Projects 2 and 3, assuming no other interruptions, each would take 10 days to complete for a total time to complete the three projects of 30 days. But having laid it out like this, if all three projects were scheduled to start on the same day, then Project 1 would be on time at 10 days, Project 2 would be done in 20 days (i.e. 10 days late) and Project 3 would be done in 30 days (i.e. 20 days late).

But can you reasonably expect to work on only one project at a time? Because there are probably three different project managers (i.e. one for each individual project), each one is most likely telling you (or maybe even screaming at you) that they need you to show progress on their project (as you will see later on, CPM reports project progress typically by measuring % of tasks complete). And because you want to satisfy all three managers, you decide to split your time between the three projects (i.e. you multi-task). So as is demonstrated in Figure 2, you start with Project 1 and work on it for 3 days. On the fourth working day, you stop working on Project 1 and begin Project 2 and work on only it for 3 days. On the seventh working day, you stop working on Project 2 and begin working on Project 3. On the tenth day, you stop working on Project 3 and begin working on Project 1 again. You repeat this sequence until all three projects are completed as in the figure below.

By multitasking, look what’s happened to the time to complete each individual project. Without multi-tasking each individual project took only 10 days to complete and 30 days to complete all three. Without multi-tasking Project 1 was completely in 10 days, Project 2 in 20 days and Project 3 in 30 days. With multi-tasking Project 1 took 28 days, Project 2 took 29 days and Project 3 took 30 days. Both methods completed all three projects in 30 days, but which set of results do you think your leadership would prefer? Also, keep in mind that when you multi-task, there is also time required to get re-acquainted with each project so the multi-tasking times will actually be considerably longer. In fact, some studies have shown that tasks often take 2-3 times their estimated duration when multi-tasking occurs.

So let’s summarize what we’ve learned before we move on. We’ve learned that task time estimates for tasks are artificially lengthened as a protective measure against Murphy and all of the negative baggage he brings to the party. We’ve learned that even though this safety is built in, it is wasted because of the Student Syndrome and Parkinson’s Law. With the Student Syndrome we put off work (i.e. procrastinate) until the last minute, while Parkinson’s Law says that if we’re given ten days to complete a task, that’s how long it will take, even if it is completed earlier. And finally we’ve learned how devastating multi-tasking can be to the completion rate of projects. So what can we do about these three behavioral problems? What if we could significantly reduce these imbedded safety buffers and still provide the protection that we need? In my next blog, we’ll take a look at just that.

Maximizing Profitability Part 30

In the next several blog postings, I am going to write about Project Management.  Specifically, I'm going to compare the primary method being used today called Critical Path Method to a Theory of Constraints based method known as Critical Chain Project Management.  Most of what you will read here is from a white paper my son John Sproull and I wrote several years ago. Before I make this comparison though, I want to write briefly about the state of project management in the world today.

In a fairly recent survey (The Chaos Report) by the Standish Group, studying nearly 10,000 IT projects across America, it was reported that 52 % of projects ended up costing greater than 189 % of the original budget, 31 % were cancelled and only 16 % of the projects were completed on time and on budget.

In 2007, a new Chaos Report, revealed that only 35 percent of software projects started in 2006 can be categorized as successful, meaning that they were completed on time, on budget and met the user requirements. Although this was a marked improvement from their first groundbreaking report, it’s safe to say that these statistics still aren’t acceptable or at least where they need to be!

In yet another study done in Australia, construction projects completed only one eighth of building contracts within the scheduled completion date, and that the average overrun exceeded 40%. The fact is, there are many other reports from numerous industry types, from all over the world, that all conclude the same thing, project completion rates are abysmal!

So the question I pose to you is this. What if I could demonstrate a different method that would push your project successful completion rate from where your rate is now to over 90 %? Would you be interested in hearing about it?  I'm assuming many of you would be, so the focus of the next several blog postings is going to be on project management.

Ninety percent of the Project Managers around the world are using a project management method called Critical Path Method (CPM) and have been doing so for many years. If you ask a typical project manager about what factors delayed a completed project, most will tell you that something they didn’t expect or even had no control over cropped up in some of the tasks and delayed them. In other words uncertainty or the Murphy bug bit them! Every project from virtually every environment has uncertainty associated with it and how this uncertainty is dealt with determines the ultimate success or failure of the project. So in order for a project to be successful, doesn't it make sense that there must be a way to protect it from uncertainty. Let’s take a look at how traditional project management (CPM) protects a project from uncertainty.

CPM uses a “fudge factor” to protect projects from inevitable uncertainty. That is,when developing the project plan, durations for each individual task are estimated by the resources responsible for executing them and then a safety factor is added to each of the tasks by the resource responsible for completing them. For example, suppose the realistic estimate of time for an individual task is one week. Is one week what the resource actually tells his or her project manager? Typically the resource will add a safety factor of their own to guard against “things” that might happen to cause a delay in the completion of the task. So it’s not unusual for the original one week to be quoted as two weeks. Resources react this way because they know from experience, that as soon as they give the project manager an estimate, it automatically becomes a commitment!

A typical project manager will then add up all of the individual, inflated time estimates and then add his or her own safety factor. Why is this done? Project Managers know that at some point in the project Murphy will strike and some of the tasks will be delayed, so they too add a safety factor to protect the project from being late. Keep in mind that every resource inflates every task, so it’s not uncommon for the estimated duration to be greater than 50 % greater than it takes to actually complete the task. So with all of this built-in safety, the project should be completed on time….right? So it seems, but the statistics on project completions don’t bear this out. We’ll explain why later.

In traditional project management PM) how do you track progress against the completion date? The typical method involves calculating the percentage of individual tasks completed and then comparing that percentage against the due date. Sounds reasonable, but is this the right way to track progress? The problem with using percentage of tasks completed is that not all tasks have the same duration. That is, comparing a task that has an estimate of one day to a task that should take one week is not a valid comparison. Compounding this problem is the mistaken belief that the best way to ensure that a project will finish on time, is to try to make every individual task finish on time. This too sounds reasonable, but later on we’ll show you why this isn’t so.

Why are so many projects being finished late?  In my next blog posting I'll discuss the human behaviorial reasons why this phenomena (i.e. late projects) might be happening.

Maximizing Profitability Part 29

Transition Trees – Steps to construct

In the last section we discussed the basic principles behind a Transition Tree. What they can be used for and how they can help you achieve desired outcomes. In this section we will discuss the steps necessary to construct the TT. There are five (5) steps to construct and if followed in sequence should yield positive results in accomplishing the desired out comes to achieve the final objective.

Step 1 - Define the situation for which you are preparing the Transition Tree.

Not all situations can benefit from the construction and use of a TT. Before you invest the time and effort to build the tree make sure it is something you really want to do. In order to benefit the most from a TT you must choose a subject that is important to you and one in which it is helpful or necessary to map out a course of action. The TT will also provide a useful tool to define how the actions can lead to the successful accomplishment of the objective.

By clearly stating the starting point you allow yourself the freedom to examine what it is you really want instead of settling for what you think is possible. Write your situation in two sentences. First, describe the need, and second define the subject of the TT you are going to create.

Step 2 - Determine your objective(s).

A very clear verbalization of where you ultimately want your analysis to end up provides an effective means to evaluate the effectiveness of your actions. It is possible, when building a TT, to have more than one objective listed at the top. However, a TT with more than one objective is also harder to construct. It requires more focused attention on the Desired Outcomes for each objective. It is also possible that each objective could have similar or closely related Desired Outcomes. If the objectives are different it could add confusion to your tree and make it difficult to explain to someone else. A word of caution is to be careful when selecting more than one objective. At times, it might also make sense to construct two tree rather than just one.

When you are building a TT from a PRT, write down an Intermediate Objective (IO) from the PRT that appears particularly difficult to accomplish. It is possible to choose more than one IO from a PRT. However, it is more practical to develop a TT for each IO, rather then trying to combine them.

Ask yourself what the purpose of the plan is.

When the subject is a future event, the purpose is something that you want. When the subject is a past event, the purpose is the actual effects of the past. Sometimes a Transition Tree can have multiple purposes.

State the purpose as a specific objective(s) in the present tense.

Most of the time you will be writing a TT for attainment of a future objective. By verbalizing the objective in the present tense, you will be psychologically more invested in making it happen – it doesn't sound so unrealistic or difficult to make happen. This minor shift in perspective also helps you later in the process when you are checking the sufficiency of the logic. State the objective as clearly as you can.

Using the Transition Tree as a delegation tool

There are many companies who proclaim "empowerment" yet, there are few who have truly figured out how to make it happen. Delegation can be one way of enabling empowerment as long as the person delegating doesn't override the decisions/actions of the delegates. The TT enables the one delegating to assign tasks and ensure that the delegates meet the objective with certain freedoms. The tree provides a succinct means of communicating clearly the “why” (the objectives/needs) along with the “what” (the task) so that the delegates understand more clearly the dynamics of the situation and are able to make decisions about actions based on whether or not the objective will be achieved – without needing the constant support of the person delegating.

Hint - Look at the big picture.

Ask yourself how the objectives relate to the desired results of the organization. Will achievement of the objective help move the organization toward its goal? If it doesn't, you should probably reconsider what you have chosen as your objective and/or reconsider whether this is a good investment of your time.

Step 3 - Determine the actions are necessary to achieve your objective(s).

Using cause and effect analysis, the future is always much more predictable than when using correlation techniques. You just need to determine what actions you need to take. In Step 3 you need to build the cause-effect structure that links the effects of your actions to the objective(s) you have selected.

When you think about the actions you need to consider what things need to be done to make the objective happen. These actions define the grassroots level of things to be completed. These are the things that you can go do “right now”. There is no planning below the action level. This is the place it starts.

You are seeking to logically bridge the gap between the current situation and the objective. The bridge will be provided through your use of cause and effect that provides the link between actions, their effects, and the objective.

Write the objective from Step 2 at the top of a piece of paper.

Write a connection that describes a step toward accomplishing the objective.

The basic elements you are trying to connect include an action, and an entity that describes the need for the action, and the desired outcome of the action.

Action - The action should be something that you believe is one of the first things required to reach the objective. State the action as a complete sentence. This will give you a starting point for constructing the tree. It may or may not be the first action at the bottom of the page when the tree is completed.

Need for action - There is something in the current situation you are intuitively aware of that has made you feel the need to take the action. After you verbalize the need, you have the opportunity to check if your assumptions about reality are valid (i.e., apply the Entity Existence reservation). This also provides an anchor by which others can judge the need for the action.

Desired outcome - What do you need to have to achieve the objective? Usually people fill this in after they have verbalized the action, so the question becomes: What do you need to gain from the action so that you are closer to achieving the objective? This step is difficult for many because we all know that there are many possible effects that may result from an action. What we are trying to do through the Transition Tree is have some control over the possible effects by causing just one to occur. Clearly state what it is that you want the action to accomplish?

Solidify the causality.

This step requires you to carefully check your logic using the Categories of Legitimate Reservation and fill in any holes you can find. Add actions, as needed to ensure the desirable outcomes. This is the step at which you must be very precise about what you have written. An analysis on paper may look good to you but reality is what counts.

Continue building upwards until you have reached your objective (stated in Step 1).

At this point you probably have some “blank” space between a Desired Outcome and your objective. Starting from the Desired Outcome (Step 3) ask yourself what needs to be done next that will bring you closer to the objective? If you are an action-oriented person, it will probably be easier for you to construct the tree from the action perspective. If you think more in terms of goals, it will probably be easier for you to continue building from the Desirable Outcome perspective. Regardless of the trigger source, you will need to continue to verbalize actions, needs, desirable outcomes, that help solidify causality.

Hint: Sometimes you will choose as an action - something you don't know how to do, or something that someone else is required to do. These are not your actions, but "desired outcomes" which still require some action on your part to achieve. Change such desired outcomes to round boxes and beneath them add the action you need to take to achieve it.

Some people might experience difficulty continuing to build the tree. If such is the case then use the following template to help fill in the missing links. This template can be especially helpful to review when you are seeking to modify the structure for those who will read it as it forces the writer to verbalize some steps in the evolution of the tree that they may have taken for granted.

Step 4 - Look for any undesirable side effects.

For most people, it is very easy to convince themselves that their plan will work. However, many plans have been known to fail, especially when some element of your plans does not produce the desired effect and in fact produces an Undesirable Side Effect. Undesirable effects can sometimes happen quickly and have instantly devastating effects on your planning. Doing this step will guide you through the process to identify the potential pitfalls of the plan and help define the necessary actions then to resolve them.

Ensure there are no undesirable side effects.

For most people, it is very easy to convince themselves that their plan will work. However, many plans have been known to fail, especially when some element of your plans does not produce the desired effect and in fact produces an Undesirable Side Effect. Undesirable effects can sometimes happen quickly and have instantly devastating effects on your planning. The steps of Key Action – 4 will guide you through the process to identify the potential pitfalls of the plan and help define actions then to resolve them.

Examine possible negative effects of your actions.

Start at the action appearing at the bottom of the page and ask yourself "If (action) and everything else remained as it is today, then ..." This will surface potential effects of the action, some of which are minor others of which might be major. If you find something major proceed to the next section. If you don't anything, examine the next action that appears in the tree keeping in mind that you have created a partially new reality. This will slightly impact the question you will ask to surface additional effects: "If (action) and (new reality) and everything else remained as it is today, then...."

Add actions that will eliminate undesired effects.

Focus your effort on removing the major undesirable effects you have surfaced. Figure out what action that can be taken to eliminate it. Incorporate this action, into the tree. The only way to eliminate an unwanted effect is to take action – just saying that it will not happen will not make it so. Don't forget to check if your new action causes other major negative effects.

You are finished with this process once you are satisfied that you know the potential side effects and you have resolved all major issues that could jeopardize it.

Hint: Here are some questions to ask that may help surface additional negative branches:

• What is the impact of this on T, I, and OE?

• What is the impact of this on other parts of the organization?

Step 5 - Take action.

Reality doesn't change with thoughts and plans, but rather with your actions. Step 5 is a gentle reminder that in order for the objective(s) to be realized, actions must be taken in reality.

There you have it. I hope these writings have been somewhat sufficient to give you a better understanding of the TOC Thinking Processes and the ability to apply some of what you have learned to problem solving. In my next post, we will look at a different topic, Project Management, which is still in the realm of Maximizing Profitability.

Maximizing Profitability Part 28

Transition Trees (TT) - Basic Principles

In the last section we discussed the Prerequisit Tree (PRT) with its many Intermediate Objectives. It is possible that you could encounter a particular Intermediate Objective (IO) that seems difficult to accomplish. When such an IO is encountered, the Transition Tree (TT) can provide the steps necessary to accomplish the IO. In essence the TT can become the mini-implementation plan for a specific IO on your way to accomplishing all of the IO listed in the PRT.

TT’s are constructed using sufficiency-based logic, and can be used to define and scrutinize the specific actions required to reach an Objective. When you are creating an action plan, most people focus primarily on the actions themselves, or on the desired outcome(s) of the action. Usually the focus is on "What are we going to do?" and "How are we going to do it?" rather than "Why are we taking this action in the first place?" It is important to remember that the primary focus of the TT is to focus your attention less on what you plan to do, and more on what you want to accomplish when determining and communicating the needed actions. This is accomplished by coupling an action with a need to generate a desired effect.

This subtle, but important, shift in the focus, allows the you to:

• Monitor implementation progress by watching the effectiveness of the actions (meeting intermediate objectives along the way to the overall objective) versus just completion of the actions.
• 
  
• Better make informed decisions and adjustments to the action plan, as required, instead of "going back to the drawing board" to re-write the entire plan.
• 
  
• Communicate the key elements of an implementation plan effectively to others; The "What" and the "Why".

Principles

The formal structure of a TT looks similar to a spinal cord, with the vertical stacking of Desired Outcomes. Because of this familiar “stacking” the core of the TT has been referred to as the “backbone”. This backbone provides the description of the IO’s, which will gradually create the changes required. These changes will occur in reality as a result of the planned actions. The TT methodology requires careful examination of the actions necessary to achieve the desired objective.

Parallel to the desired outcomes are the necessary actions. Each action is supported in sufficiency with additional causality of another desired outcome. When an ellipse supports an action, and desired outcome, then sufficiency has been established. By scrutinizing each action it can be determined if it is sufficient to produce the desired outcome and achievement of the TT Objective.

Many times we rely on a set of actions because “it worked for someone else,” without checking if the actions really lead to the outcome you want, or if they fit your unique situation. When using a TT as a blueprint for implementing an objective, the focus is on causing specific changes in reality, rather than sticking to specific actions just because we think they will work.

Transition Trees can be used to:

• Convert a strategic plan into a comprehensive tactical action plan.

• Plan important meetings, presentations, letters, phone calls, etc.

• Effectively delegate tasks through communicating both the “what”, and the “why.”

• Communicate how a sequence of desired actions will lead to specific effects.

• Solicit the needed collaboration of others.

The TT allows you to take your thinking to a very finite detail and determine the steps necessary to achieve the objective. The square “Action” boxes define the actions you must take coupled with the needs you are trying to fill, to achieve the desired outcome you want.

In the next blog we will discuss the steps for constructing a TT and developing the action plan to achieve the overall objective.