CHAPTER 5
Using Logic Trees to Construct Your Methodology
As was discussed in Chapter 2, the objectives1 in your proposal express the steps your project will take me. These steps can result in my having insight, a plan, and/or an implemented plan. The objectives are an important set of outcomes of your project, and your methodology describes how you will achieve them. It consists of a logically sequenced group of actions that will achieve the objectives.
Unfortunately, many of the methodologies you present in your proposals don’t persuade me that you will effectively achieve the project’s objectives. Sometimes, those methodologies contain vague generalities such as “interview management,” “gather data,” “analyze data,” and “report results.” These generalities provide me with very little or no insight about how, precisely, you will achieve the objectives. Other times, the methodologies contain more specific tasks, but the logical relationship among the tasks and the objectives is unclear, as is the relationship of the tasks to each other. From my perspective, it often appears that you cut and paste from previous proposals to describe what you will do in this project. That’s not good enough to prepare winning proposals, especially if a thoughtful, tailored methodology is one of my hot buttons or one of the selection committee’s evaluation criteria.
You might believe that a compulsively logical methodology is not an important factor in my decision-making process—and sometimes that’s the case. But more often than not, I suspect you use this belief to rationalize your lack of effort in developing logical methodologies (and effective project workplans after you have been awarded the assignment).
Likewise, you may believe that the more detailed the methodology, the greater the chance that I will take it and apply it myself, using my own resources. Yes, I’m certain that such things happen, but nowhere near as frequently as you believe. Listen, I want as good a relationship with a dependable, results-oriented problem solver as you want with me. If we can develop an acceptable level of trust, I believe that the risk to you is minimal. Moreover, if I believe that the methodology is critical, you won’t win without a logical, well-thought-out one.
I also suspect that you may not have a structured and rigorous way of constructing a clear and logical methodology. I do. Let me share it with you. It involves the following four steps:
1. Clearly identify the project’s objective(s), based on my overriding question(s).
2. Place each objective at the top of a logic tree, and order the actions necessary to achieve it.
3. Sequence the actions.
4. Identify and integrate the activities necessary for planning and communicating your proposed actions.
I’ll discuss each of these steps in this chapter. But first, because the key to completing them is a logic tree, I need to tell you what that is and how to construct one.
Using Logic Trees
According to Barbara Minto in The Minto Pyramid Principle,2 a logic tree (Minto calls it a pyramid) is a framework for organizing ideas, a framework for logical thinking. It structures a group of actions and their consequences that, taken together, produce a desired result. A logic tree is based on the assumption that sequences of actions are performed to achieve a specific result. That is, actions are not random; they are undertaken deliberately. A logic tree expresses these actions and the reason they are performed. For example, let’s say you decide to perform the following two actions in Figure 5.1. Why would you do so?
The answer might be to make a butter sandwich (Figure 5.2), which is not necessarily a great sandwich or a culinary challenge but is a good illustration for my purposes at this point.
Here we have a logic tree. It contains a single box at the top. That box implies a result, the ends, in this case a butter sandwich. The boxes below it are the actions, the means, necessary to produce that result. If you told me, in the methodology of your proposal, that one of your tasks would be to make a butter sandwich, I might ask, “How?” You would answer by naming the two steps on the lower row.
FIGURE 5.1 The beginning of a logic tree
FIGURE 5.2 A “grouping” in a logic tree
Note two things. First, the boxes are related through a logic that goes both bottom-up and top-down; second, whether you read bottom-up or top-down, the boxes always exist in a question-answer relationship. From the bottom, the lower boxes are the actions necessary to achieve the result implied by the top box to which they are joined. So, if you were building your logic tree from the bottom up, you would ask yourself, “What result would be produced from these two actions?” That answer would generate the top-level box, a butter sandwich. From the top down, the higher-level box also generates a question: “How would you achieve the result implied by this action?” That answer would give you the two boxes (the actions) at the lower level.
As Figure 5.3 illustrates, a well-constructed logic tree has four characteristics.
The fourth characteristic, MECE, in Figure 5.3 means this:
A grouping refers to any number of actions on one level that achieve the result implied by the action above.
The actions in that grouping appear nowhere else in the logic tree (i.e., they are Mutually Exclusive).
No other actions within the grouping are required to achieve the result implied by the action above (i.e., they are Collectively Exhaustive).
FIGURE 5.3 The four characteristics of a logic tree
Now let’s assume that you want more to eat than a butter sandwich, though given the limited amount of food in your refrigerator, the butter sandwich will have to serve as the main course. So instead of the box “make a butter sandwich,” we substitute the box “prepare main course,” and we include two other boxes on the same level, as shown in Figure 5.4.
What will be the result of those three top boxes? Prepared food, as shown in Figure 5.5. The top box, then, will again be an action that expresses that result: Each box needs to be an action that expresses a result because depending on your perspective, each box is either an action or a result.
Figure 5.6 builds the logic tree further, illustrating that each box on a higher level must be connected to a grouping below it comprising at least two boxes.
Now, if I wanted to try your patience even more, I could continue building the logic tree ever upward. I also could continue to build it downward, since further actions could be required to explain how you butter one side of each slice of bread and join them together. What determines where you start and how far down you go? I can explain the “down” part in one sentence: As far down as you need to go so that your reader or listener no longer asks “How?” That’s easier said than done, considering that your methodology will rarely be presented to just one person. Someone like Ray Armstrong, ABC’s president, for example, may not want to see a methodology built as low as would someone like Paul Morrison, the chief industrial engineer.
Explaining where the logic tree begins will take two more paragraphs. Assume you have a potential client to whom you’ve been trying to sell for some time. You have had several meetings with her and have developed a fairly sound business relationship, but so far you’ve been unable to make the sale. It so happens that she and your best friend went to school together and haven’t seen each other for over 20 years. She would like to see your friend, and your friend would like to see her (and you, of course, would like to make the sale). Next week, this potential client will be in town for two days. Your overriding question is: “How can I further my relationship with her to increase the likelihood of a sale?” Your answer is to give a dinner party that she and your friend will attend (and during which, we’ll assume, you won’t serve butter sandwiches as a main course).
FIGURE 5.4 Building a logic tree from the bottom up (1)
FIGURE 5.5 Building a logic tree from the bottom up (2)
FIGURE 5.6 Building a logic tree from the bottom up (3)
Note that three things have generated the logic tree in Figure 5.7 and therefore determined where it begins. First, a problem: in this case, your not having yet made a sale. In your proposal, the problem is discussed in the situation slot. Second, an overriding question related to the problem: in this case, “How can I further my relationship with my potential client to increase the likelihood of a sale?” Third, an objective, which is the answer to the overriding question: in this case, “Give a dinner party.” The objective is stated in your proposal’s objectives slot. It also becomes the top box in your logic tree, as shown in Figure 5.7, which provides the logically related actions necessary to achieve that objective.
In the rest of this chapter, I’ll show you how all those actions under the objective form part of your proposed project’s methodology. I’ll also take you through the revision of a methodology of an internal proposal written to the XYZ Company, a provider of information systems.
FIGURE 5.7 A logic tree structures the tasks necessary for achieving an objective.
Some years ago, XYZ’s marketing group wanted to explore the idea of offering its services to a new market, the motor freight sector, possibly in partnership with a motor carrier. Figure 5.8 lists the objectives and the tasks as they first appeared in the proposal. After you’ve read Figure 5.8, I’ll take you through the four-step process of constructing (in this case, revising) the methodology. Because constructing a logic tree seems complicated the first few times you try to build one, I’ll repeat much of what I said when building the logic tree for giving a dinner party. In the work session at the end of this chapter, you’ll have yet another opportunity to see a logic tree constructed. After that, you should be able to start building your own.
Step 1: Clearly Identify the Objective(s), Based on the Overriding Question(s)
Because the methodology contains the tasks you will use to achieve your project’s objectives, the starting place for building your methodology has to be the objectives themselves. It makes little sense to plan a trip if you don’t know where you’re going, and it makes equally little sense to tell me how you’re going to go about achieving what you’re uncertain about accomplishing. Fortunately, I’ve given you some important tools for thinking about your objectives. As we’ve seen, they can be of only three kinds: Insight, Plan, or Implementation. If yours is an Insight Project, you will have only one objective, related to insight. A Planning Project will have only one objective, related to developing a plan. An Implementation Project also will have only one objective, related to implementing a plan. Understandably, a project intended to develop a plan and implement it will have two objectives. So will one that combines insight with a plan.
Objectives
• Develop market and competitive information to assist XYZ in determining if there is a demand for the proposed service offering and how it could be tailored to better meet customers’ needs.
• Determine how the product should be marketed given customers’ needs, the marketplace, and the activities of competitors.
• Identify potential actions for XYZ to be successful in this marketplace.
Tasks
• Conduct kickoff meeting.
• Identify market participants and develop questionnaires.
• Evaluate motor carriers’ requirements.
• Evaluate competitors’ capabilities.
• Evaluate shippers’ needs.
• Review progress with top management.
• Assess overall market potential.
• Define market opportunities.
• Assess strategic alternatives.
FIGURE 5.8 The original objectives and tasks for the XYZ proposal
Two overriding questions existed in the XYZ situation, one related to insight and one related to a plan. XYZ wanted to know whether entering the market was desirable, and, if it was, the company wanted to know how best to do so. But you’d be hard pressed to glean that information from the objectives shown in Figure 5.8. In fact, the objectives as originally stated don’t even suggest that the study might only involve one phase—the market assessment. After all, if the market were not worth entering, XYZ wouldn’t need or even want a plan for entering it. Therefore, the consultants should have revised their objectives so that the first related to insight and the second related to a plan:
Determine if XYZ should enter the information-service market for motor carriers.
If entering the market is feasible, develop a plan for doing so.
These objectives much more clearly capture the desired results and also indicate the phased nature of the project.
Step 2: After Placing Each Objective at the Top of the Logic Tree, Order the Actions Necessary to Achieve It
In building a logic tree, you need to keep two principles in mind:
Each box in the logic tree is a single action that expresses a result.
The actions must be as specific as possible.
Because all the actions in the logic tree work together to produce the objective, all are logically integrated. The integration occurs because each action on each level is part of a group of actions that produces a result at a higher level. Figure 5.9 depicts this condition. On the lowest level are three groups of actions. Since the logical reason for performing any group of actions is to achieve some result, each group on the lower level produces an implied result at the next higher level:
Actions 1, 2, and 3 are performed in some logical manner to achieve Result 1. Actions 4, 5, and 6 produce Result 2. And so forth.
As you construct your methodology, you must phrase these three results as actions because they are undertaken to produce a higher-level result or group of results. At the very top of the structure, regardless of how many levels it contains, is always the final result: the project’s objective. In a well-structured logic tree, as Figure 5.10 illustrates, every box—no matter how far down the tree it might reside—contributes to achieving the objective.
FIGURE 5.9 Each grouping achieves the result implied by the action below.
If your project has more than one objective (if, for example, it’s a combined Insight and Planning Project, as in the proposal to XYZ), you will need to build a logic tree for each objective, as shown in Figure 5.11.
In constructing your logic tree, you must try to phrase the actions as specifically as possible because I might want to know precisely and specifically what you will accomplish. An effective technique is to test your action by rephrasing it in your mind as an actual result.
Consider these poor examples: The result of the action “gather information” would be “gathered information.” The result of “interview top management” would be “interviewed top management.” These results, I think you see, aren’t very specific. They don’t express a result. After you’ve gathered information, all you have is a bunch of information. After you’ve interviewed top management, all you have is a bunch of interviewed managers. Compare these nonspecific actions to “identify resources and timing required” or “specify capabilities required.” These actions express specific results, which, as we’ll discuss later in this chapter, are deliverables: “identified resources” and “specified capabilities.” These are things I can see; I can visualize a list of resources or capabilities.
FIGURE 5.10 Every action at every level contributes to achieving the objective.
FIGURE 5.11 A separate logic tree is necessary for each objective.
Now, let’s examine part of the logic trees that could have been developed by XYZ’s internal consultants. In Figure 5.12, I’ve included all of the first two levels and part of the third.
This and any well-constructed logic tree develops your ideas by way of a series of arguments. In Figure 5.12, several arguments exist that are mutually exclusive and collectively exhaustive. First, whether XYZ should enter the market can be determined by three major tasks: identifying market opportunities, specifying the capabilities and resources required to capitalize on those opportunities, and comparing XYZ’s capabilities and resources to the market requirements. Second, the market opportunities can be determined by identifying the motor carriers’ needs for the proposed information system, the needs of the motor carriers’ customers, and the capabilities of XYZ’s competitors. Finally, to develop a plan for actually entering the market, XYZ needs to know (1) which actions are necessary for closing the gap between what the market demands and what XYZ can do and (2) what resources and timing are necessary to carry out those actions.
In checking the logic of your logic tree, use the several requirements I’ve discussed:
Each box must be an action that expresses a result. Therefore, each box must be phrased as specifically as possible.
Each group of boxes on one level must produce a result, a deliverable, on the next level. That group and its result form an argument that goes something like this: “To achieve result A, action X, action Y, and action Z, and only those actions, must be performed.”
FIGURE 5.12 A partial logic tree for the XYZ proposal
All arguments are mutually exclusive and collectively exhaustive (MECE).
Applying this logic tree technique will help you indicate logical relationships and identify the gaps in your logic, letting you know where you have left something out.
Step 3: Sequence the Actions
In this straightforward step, you can sequence the actions by using a typical outline or bullet form, as I’ve done in Figure 5.13. Once again, I’ve taken the steps completely down to two levels and only partially, for illustrative purposes, to a third. Note now how the project is phased, with the project’s objectives used, in this case, as the titles of the phases.
FIGURE 5.13 The sequenced actions from the XYZ logic tree
Because the outline form does not readily reveal logical relationships or logical inconsistencies (as the logic tree does), you should use the outline form only after you have constructed your logic tree.
Step 4: Identify and Integrate the Activities Necessary for Planning and Communicating Your Proposed Actions
In building your logic tree, you must distinguish between actions and activities. When you take your car in for repairs, you want your mechanic to perform two very different kinds of tasks. First are those actions directly related to achieving your objective of fixing or maintaining your car. These are the hands-on procedures to diagnose and solve the problem. Second are the kinds of tasks related to planning and communicating. These activities might involve the mechanic calling you when the car is fixed or calling you if the problem will cost more than was originally estimated. Then you could decide whether to have the car repaired, trade it in, or live with the problem. Both kinds of tasks—those actions necessary for achieving the objective and those activities necessary for planning and communicating—are part of the mechanic’s methodology, and they’re also part of yours. (See Figure 5.14.)
FIGURE 5.14 Your methodology combines the actions for achieving the objective and the activities for planning and communicating.
Although an activity such as presenting a planning study’s final report might be extremely important to the success of your efforts, it is crucial only in presenting the plan you constructed. It is not an action necessary for actually achieving the project’s objective of developing the plan. The same holds true for other typical activities, such as presenting interim reports and conducting kickoff meetings. Even those activities, however, should be phrased as specifically as possible. Therefore, instead of “conduct kickoff meeting,” you might phrase the activity as “confirm project objectives in a kickoff meeting.” After identifying the activities, you can sequence them in your outline, as I’ve done in the right-hand column of Figure 5.15, which compares the original methodology with part of the one we’ve been building by using a logic tree.
As you compare the original and the revision, I’m certain you’ll agree that the latter much more clearly defines the desired results and how you will achieve them. The original methodology is typical of those I see in proposal after proposal—boilerplate lifted from past proposals. The relationship of the tasks to the objectives is unclear, as is the relationship of the tasks to each other. The revised methodology, in contrast, is much more specific to our situation and clearly reveals the project’s objectives and how they will be achieved. If a logical methodology were important to me, I would surely reward you for that clarity. In my evaluation of your proposal, I would most certainly give you some of the two to five extra points you need to win. And even if a logical methodology were not important to me, it would provide you with the basis for a logical workplan that will help you more effectively execute the project after you’ve won.
FIGURE 5.15 Comparison of the original and revised XYZ objectives and tasks
The Logic Tree, Deliverables, and the Logics Worksheet
In Chapter 3, I discussed deliverables, one of four kinds of outputs suggested by the baseline logic, the other three being desired results, achieved objectives, and benefits (see Figure 5.16).
Desired Results: The outputs of the project or its phases: insight, a plan, and/or an implemented plan. Example from ABC: a plan for increasing capacity (a non-measurable result).
Objectives (achieved): The expression of S2, the desired results. Example: develop a plan for increasing capacity.
Deliverables: The outputs produced during the transition from S1 to S2. Example: specifications of current equipment and space utilization.
Benefits: The good things that accrue to the prospect as/after its desired result is achieved. Example: a thorough justification of the chosen option that provides the basis for requesting funding from Consolidated.
FIGURE 5.16 The four outputs of the baseline logic
In this chapter, we have also been discussing deliverables. Because the boxes in your logic tree are actions that imply a result, each result should be a deliverable produced by your methodology. Accordingly, as Figure 5.17 shows, you can use your deliverables from the Logic Worksheet’s Cell 5 (see Figure 3.24) as a first step in building your methodology. Once you have constructed your logic tree, you will undoubtedly discover additional deliverables that you should add to that cell and red flag if necessary, making certain that they are aligned with the desired results and benefits.
Before you read this chapter’s work session, I want to say something about workplans, which, as I’ve hinted before, can be formed in part from your logic tree. As Figure 5.18 illustrates, a workplan is nothing more than your methodology sequenced over time, with the actions indicated by horizontal lines and the activities by triangles. In proposals, the workplan is often presented in the form of a Gantt chart that includes the actions and activities on one axis and the timing of those tasks on the other. This kind of chart is most helpful in letting me see when you expect each task to begin and end. A Gantt chart also indicates which tasks will be performed concurrently and which tasks will overlap. Before you can develop your workplan, however, you need to construct a logical methodology. You’ll get some practice in the following work session, which develops a logic tree for the proposal to ABC.
FIGURE 5.17 The major deliverables on the Logics Worksheet could become your methodology’s major tasks.
FIGURE 5.18 The workplan shows the methodology’s actions and activities plotted over time.
CHAPTER 5 REVIEW
Constructing a Logical Methodology
1. The proposal’s methodology consists of two kinds of tasks: actions and activities.
Actions are tasks necessary for achieving the project’s objectives. Usually occurring over a period of time, actions are necessary in the problem-solving process—that is, for achieving the project’s objectives. Each action should express a result.
Activities are tasks important for planning and communicating. Usually occurring at a point in time, activities are important in the client-management process. Examples include: confirming the project’s objectives, reporting interim results, and delivering a final report. As much as possible, these tasks also should be phrased to express results.
2. Constructing the proposal’s methodology requires four steps:
Clearly identify the objective(s), based on the overriding question(s). An Insight Project has only one objective—providing insight. A Planning Project has only one objective—developing a plan. An Implementation Project has only one objective—implementing a plan. A combined Insight and Planning Project has two objectives. A combined Planning and Implementation Project has two objectives.
After placing each objective at the top of the logic tree, order the actions necessary to achieve it. Develop one logic tree for each objective. Every box in the logic tree expresses an action implying a result. Every box on one row is connected to at least two boxes on the next lower row. These lower-row boxes are the set of actions necessary to achieve the result implied on the row above. These lower-row actions, however, also imply results in the boxes connected to them on even lower rows. Each box in every row implies a result produced by the related actions on the row below. Therefore, each box is an action implying a single result. The actions should be expressed as specifically as possible.
Once the logic tree is constructed, list the actions in sequence. Use indentations or standard outline form to indicate the hierarchical relationships. You have now logically organized the actions.
Identify and integrate the activities necessary for planning and communicating your proposed actions. You have now constructed the methodology.
3. Once the logic tree is completed, identify deliverables that do not exist on the Logics Worksheet, add them to the Logics Worksheet, and align as necessary.
WORK SESSION 4: Developing the Logic Tree for ABC
Confident that your baseline logic is complete and well aligned, you turn your attention to the final element that provides a proposal with its logical foundation: the methodology. The methodology indicates how you plan to close the gap between the current situation, S1, and the desired result, S2; it effects the transition from S1 to S2.
A comprehensive and logical methodology will play a significant role in convincing ABC’s management that Paramount can best help it develop a plan to address its capacity problem. That you know. Because you also know that manufacturing strategy isn’t one of your own strengths, you suggest to Gilmore that he assign some of the firm’s functional specialists to work with you to develop the methodology. Gilmore quickly acts on your suggestion and joins the group himself.
Validating the Overriding Question and Objective
Because the methodology is the means to achieve the project’s ends (its objectives), the group’s first task is to define ABC’s overriding question. As you expected, the group members differ about what the overriding question should be. Some believe it should be phrased like this: “How can ABC best provide product to meet forecasted demand?” Proponents of this question suggest that internal resources and capital investment can be conserved by having more operations, especially low-value-added ones, performed by outside suppliers.
Others believe the question should focus not on product supply but on capacity: “How should ABC increase capacity to meet the sales forecast?” Both you and Gilmore argue for this question. Gilmore explains to the group that Armstrong gave him the clear impression that ABC preferred to have closer control of its manufacturing processes by performing most of its major operations within its own facilities. As a result of Gilmore’s counsel, the group agrees that the project’s objective should be this: “Develop a manufacturing facility strategy that will provide the capacity necessary to meet forecasted demand.” Of course, this objective should be tested and revised, if appropriate, with ABC’s management. This testing and discussion is a key element is building a stronger relationship during the business-development process.
Building the Logic Tree
After about two hours, the group completes a first draft and a second draft (Figures 5.19 and Figure 5.20) of the logic tree for ABC. As you look over the x’dout and italicized boxes in the second draft, you see clearly why various changes were made and still need to be made. For example, various x’d-out boxes didn’t survive the second draft because they didn’t express a result, a deliverable. Cases in point include “review and discuss existing forecast” and “examine current space allocations.” The results implied by these tasks are a review and an examination. These, you recognize are processes, not end products like deliverables. What, you must always ask yourself, is the end product of that review or that discussion?
FIGURE 5.19 The ABC logic tree, first draft
The same is true of tasks you’ve seen in many proposals, tasks such as “to analyze [something]” and “to evaluate [something].” An evaluation and an analysis are processes, not end products. You are beginning to understand that an “expansion analysis” just isn’t as specific as “a detailed list of expansion alternatives.” A “detailed list of alternatives” describes what the prospect will receive, rather than the process, the analysis, that will produce the deliverable.
Other boxes in the second draft are problematic in another way: They aren’t necessary for achieving the result implied in the box above them. The task “modify forecast” is a case in point: It expresses the same result as the box above it. These “mistakes” confirm to you the power of the logic tree in constructing a logical argument for your methodology: The logic tree clearly displays gaps and errors in logic and helps you, more quickly and effectively than you could otherwise, generate a third draft, as shown in Figure 5.21. Even this draft, you recognize the next day, has some problems, but you are satisfied that it is good enough for now. It will provide you with the guts of your methodology and the building blocks for your methods section. It also generates some additional deliverables that you record on your Logics Worksheet.
FIGURE 5.20 The ABC logic tree, second draft
