write 250 word discussion paragraph on topic listed below.. with references

readingonLogicdiagram.pdf

Home >Human Resource Management homework help >write 250 word discussion paragraph on topic listed below.. with references

vand14310_ch08.qxd 6/10/03 10:12 AM Page 105

Y CHAPTER EIGHT

NOT JUST THE FACTS

Building the Logic

O nce you begin collecting data, you also begin developing opinions about the

validity of your hypotheses. These opinions start to give you a sense of what

you will conclude about the situation you are investigating, which in turn helps

lead you to the solutions you might design and recommend. The challenge is

keeping everything straight. Which hypotheses do you accept? Which ones do you

reject? Which ones require more data? How confident are you of the data you have

collected? Which data are useful? Which data are trustworthy? Why are there in-

consistencies? Do they matter? You want to move from a morass of inconsistent

and unclear data to a set of clear, logically consistent conclusions that lead to

innovative and practical solutions. But how?

I learned at McKinsey & Company that a solution is valuable only if it is

transparent—that is, if you can explain why you are recommending it—and that

conclusions are much more valuable if they are based on facts. The information

on which belief or judgment is based makes a big difference. If you show peo-

ple why you reached your point of view, they have the opportunity to decide

whether they agree based on the logic you used. Justification is a big part of action.

Making your conclusions and solutions transparent—in other words, showing

your work—is key to success.

The premise underlying the designing solutions process is fact-based analysis.

Any conclusions you draw and solutions you design are based on the facts that

underlie the situation. Unfortunately, facts can be a bit hard to pin down.

105

Co py ri gh t © 2 00 3. J os se y- Ba ss . Al l ri gh ts r es er ve d. M ay n ot b e re pr od uc ed i n an y fo rm w it ho ut p er mi ss io n fr om t he p ub li sh er , ex ce pt f ai r us es p er mi tt ed u nd er U .S . or

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) - printed on 8/7/2014 7:04 AM via KAPLAN HIGHER ED (IA) AN: 100900 ; Vandenbosch, Betty.; Designing Solutions for Your Business Problems : A Structured Process for Managers and Consultants Account: ns019078

vand14310_ch08.qxd 6/10/03 10:12 AM Page 106

106 Designing Solutions for Your Business Problems

While I was working with a durable consumer goods manufacturer once, it

took nearly a month before everyone agreed on the definition of a sale. I had

thought that a sale was a simple transaction to track. However, it was complicated

by returns, manufacturer’s discounts, salespeople’s negotiated prices (which

reduced sales but also their commissions), sales to distributors, sales to end con-

sumers, and so forth. I would never have believed it would take so long to come

to agreement on such a seemingly straightforward concept. Then I did a project

for a bank. It took even longer to come up with the components of customer

profitability. First, we had to define what a customer was . . .

When you move beyond measurable transactions, facts are even harder to

agree on. Everyone knows about the unreliability of eyewitnesses at crime scenes.

There is no reason to believe that people working in an organization are any more

reliable at remembering what they have experienced. And yet we all believe we

remember something exactly.

And then there are opinions. Whose is right? Whose matters?

The dictionary is no help. The Oxford English Dictionary defines a fact as “truth;

reality; a thing known for certain to have occurred or to be true; a datum of

experience.” For lots of things, it is not at all clear whether it is known for cer-

tain to have occurred. It depends on whom you ask. Truth is variable as well.

We have all been admonished that perception is reality. Hence, all perceptions are

valid. What do you do with varying perceptions when you are trying to conduct

a fact-based analysis?

All of these problems with facts notwithstanding, attempting to solve a

problem by relying solely on opinion is a much greater risk. Table 8.1 sets out just

a few of the mistakes people typically make when they face decisions. My remedy,

TABLE 8.1. FLAWS IN DECISION MAKING.

Poor framing

Recency Primacy Probability

Escalation

Association

Groupthink

Allowing a decision to be influenced excessively by the language used for describing the decision Giving undue weight to the most recent information Giving undue weight to the first information received Overestimating the probability of familiar or dramatic events; underestimating the probability of negative events Unwillingness to abandon courses of action that have been decided on previously Reusing strategies that were successful in the past, regardless of whether they fit the current situation Overemphasizing group consensus and cohesiveness instead of bringing out unpopular ideas

Source: Adapted from Tversky, A., and D. Kahneman, D. “Rational Choice and the Framing of Decisions.” Journal of Business, 1986, 59, S251-S278.

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 107

107 Not Just the Facts

and the remedy of many reputable problem solvers before me, is to get the

data and do the best you can to use them wisely.

Developing a logic diagram like the one shown in Figure 8.1 is a way to stay

organized as you collect data and begin to draw conclusions and design solutions.

It also ensures transparency because it shows the rationale you used. As its name

implies, a logic diagram shows the logic of your argument in a diagrammatic form.

When you read from left to right, it answers the question, “So what?” What are

the implications of these data? What is their relevance to your conclusions and

solutions? When you read from right to left, it answers the question, “Why?” Why

did you arrive at this solution, these conclusions, these findings?

The logic diagram provides a mechanism for you to check your logic with

your team and your client. In fact, members of the client organization should be

key participants in logic development and testing. If they don’t believe it, why

would they bother to implement it?

FIGURE 8.1. LOGIC DIAGRAM TEMPLATE.

Data

Findings

Conclusions

Solution

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 108

108 Designing Solutions for Your Business Problems

Tommy Lee, a senior vice president at JP Morgan Chase, has been helping

people solve their information technology problems and manage their projects for

most of his career, most recently as the head of an internal consulting group. Two

of his mantras are, “If you can’t draw it, you don’t understand it,” and “If you

can’t represent it on a single page, it’s too complicated.” Logic diagrams force him

to represent his idea on a single page. They provide a way to put data into a struc-

ture and what he refers to as a “commonsense approach to determine when to get

more data.”

Hans-Ulrich Mayer from Nestlé feels that “not everyone is honest enough

to admit that they are illogical,” so logic diagrams help them to see the flaws and

gaps in their thinking. One project his area was involved with was improving man-

ufacturing productivity in a line of business across Europe. The project was par-

ticularly challenging because different countries had different approaches, different

sensitivities, and, for the most part, some arrogance about the superiority of their

own way of doing things.

The project manager whom Hans-Ulrich appointed was young, relatively

inexperienced, and not European. From the start, he had no credibility with

his European counterparts. In fact, in most presentations, participants arrived

wanting to prove he was wrong and reject his solutions. However, his logic dia-

grams gave him fact-based authority. Ultimately, the people affected showed a

great deal of appreciation for the work, Hans-Ulrich believes, in part, because

of the strength of the project manager’s methodology and the logic diagrams he

developed.

The Details

Let’s say you are working with Acme Ceramics, which makes and distributes

ceramic tiles. Although its sales have been rising dramatically year over year, its

margins have been falling. You have developed a hypothesis that the absence of a

sales and pricing strategy is the root cause of low margins.

As part of your data collection, you divided Acme’s product line into two

groups: high and low margin. Then you organized the sales data into these groups.

One piece of very low-level data might show that three boxes of Acme’s low-margin

tiles were sold at the hardware store at the corner of Main and Maple in Springfield

yesterday. The data for the previous month from all the hardware stores the com-

pany supplies could be summarized into a statement about sales in that month. A

comparison of this to sales the month before, the year before, and the budgeted

amount would provide a higher-level understanding of the current situation. Com-

paring the data for low-margin products to high-margin products is at a higher level

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 109

109 Not Just the Facts

yet. Your finding from these data might be that low-margin products are selling at

a rate of two-to-one over high-margin products. As the data get summarized, they

evolve into findings.

Data

Your logic diagram should contain data to convince yourself, but also data to con-

vince your client, stakeholders, and other interested people. Remember that

data do not have to be quantitative to be convincing. Behaviors and opinions are

just as important as operating reports and sales numbers in determining the best

path for an organization to take. Background and experience will also have an

effect on the level of detail required to build the logic for an argument. For

example, a client who is contemplating a move into a new product line will need

much more evidence about the prognosis for the product than will a client who

has been successful in that line for many years. A client who has had a bad expe-

rience with the product line may need more evidence than people in either of the

other two situations.

You need to be careful to understand which data are news and which are self-

evident, not to you as you develop the logic but to those with whom you plan to

share it. You may think that some aspects of your argument need no support, but

your client, stakeholders, and other interested people may not agree. Conversely,

you may think some aspects need a great deal of elaboration, but they are obvi-

ous to your client organization. Remember that you have to convince your client

as well as yourself about the validity of your logic.

My first consulting project was for an investment bank that wanted help

deciding whether a software package the floor traders wanted to buy was worth

breaking standards for. Historically, this firm used only software for which it owned

the code, and the vendor in this case was not willing to provide this information.

One small part of the analysis required us to look at the total cost of using the

software over a two-year time horizon. Just as I had learned in Finance class, I

carefully calculated the net present value of the initial hardware and software

purchase price and subsequent maintenance fees. I provided ample justification

for what I perceived to be the superiority of my approach. And although I’m sure

my answer was correct, it was way out of line with what the problem and the

client required. First, net present value does not add a great deal when con-

ducting an analysis over two years, unless the cost of capital is in excess of 20 per-

cent. Second, telling an investment house about the superiority of a particular

valuation technique seems to be bringing coals to Newcastle. Not surprisingly, my

manager caught my blunder and gave me my first lecture on working smart

and not hard.

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 110

110 Designing Solutions for Your Business Problems

Findings

A finding is a summary statement derived from raw data that directs your think-

ing toward the solution of the problems or the exploitation of the opportunities.

When you develop findings, you discard the irrelevant, cross-check the relevant,

and use the result to review and revise your hypotheses.

At Acme, you might have conducted six interviews with salespeople who are

responsible for ensuring shelf space for Acme’s products at mom-and-pop hard-

ware stores. Sales to national chains and contractors occur through a separate

channel. Each salesperson had several opinions about the organization, but they

all stated that they focus on sales volume rather than margin because of their com-

pensation plan. Each individual you spoke with provides you with a data point. A

finding that summarizes the data points would be, “The sales compensation plan

favors low-margin products.”

Whether the sales force focus is an interesting finding depends on where the

argument is going. It begs the question, “So what?” More specifically, what effect

does the sales force’s focus on low-margin products have on average margin? This

finding has the potential to lead to a diagnosis, so it should not be discarded. When

a group of findings lead you to diagnose the situation and make a judgment about

it, you have developed a conclusion. By themselves, findings do not interpret

information or explain implications.

Conclusions

A conclusion is a diagnostic statement, based on the data and findings, that

explains problems or opportunities and is significant enough to warrant action.

Hypotheses are untested opinions. Hypotheses that are tested and supported

become conclusions, but conclusions can also arise directly from the findings.

To continue the Acme example, you have found that low-margin products are

selling much better than high-margin products. You have also found that the com-

pensation system favors low-margin products. As you continued data collection,

you found that Acme’s marketing and advertising do not distinguish between high-

and low-margin products. Finally, you have found that Acme is underpricing its

competition by a significant amount on its low-margin products and charging a

significant premium in relation to the competition on high-margin products. Your

initial hypothesis about the absence of a sales and pricing strategy seems to be well

supported. However, to support it fully, you will have to investigate whether there

is a sales and pricing strategy and if your findings line up with it. If you find a

strategy to focus on high-margin products, your conclusion would be that

organizational systems do not line up with the strategy. However, if there were no

strategy in place, your conclusion would be your initial hypothesis: A lack of a

sales strategy is the root cause of low margins.

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 111

111 Not Just the Facts

Once again, the question, “So what?” looms. Whether this is an interesting and

important conclusion depends on where the argument is going. One or more con-

clusions lead you to design a solution describing what your client should do—what

actions he should take. In this case, you might recommend that the organization

develop a sales strategy that lines up compensation, marketing expenditures, and

pricing.

Solution

The solution in a logic diagram describes the actions that you believe the client

should take based on the conclusions you have drawn. Good solutions are prac-

tical and achievable, and they will lead to specific benefits when they are imple-

mented. They resolve problems or realize opportunities. It is not until you have

included a solution in your logic diagram that you can be sure that the logic is

airtight and compelling. A conclusion isn’t useful unless it points to an action the

client should take. Hence, until you have recommended a solution, you don’t know

whether you have gaps or excesses in your logic.

At a minimum, a solution should cover the assignment scope. If it is imple-

mented, the client should expect to reach his objective. It should completely cover

all the aspects of the conclusions, and you should be able to track its compo-

nents back to the findings. The solution usually addresses the findings via the con-

clusions by indicating how the findings will change as a result of implementing

the solution. In other words, the findings provide the details that the solution must

address, as is the case in Acme’s logic diagram in Figure 8.2.

However, the requirements for solutions go far beyond fitting into an air-

tight logic diagram. The solution must be feasible for the client to whom you are

recommending it. There is no value to a solution that doesn’t fit with the client’s

constraints and her will and skill to implement. Chapter Nine provides details

on how to design solutions in the light of the client situation.

The Logic Diagram

This completes the path from data to solution. Each finding is supported by

data, each conclusion is supported by findings, and each solution is supported

by conclusions. The logic is airtight.

Reading from left to right in Figure 8.2 verifies that the argument is complete.

You will be able to answer the question, “Why?” about the solution using the con-

clusions that lead to it. For each conclusion, you will be able to explain why you

reached it by relying on the findings that lead to it. Finally, although the data are

not shown in Figure 8.2, you have data to support each finding.

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 112

112 Designing Solutions for Your Business Problems

FIGURE 8.2. LOGIC DIAGRAM FOR THE ACME PROJECT.

Findings

There is no sales strategy.

The sales compensation plan favors low-margin products.

Low-margin products are selling at a rate of two-to-one over high- margin products.

Develop a high-margin sales strategy that incor- porates compensation, marketing, and pricing.

Marketing and advertising do not distinguish between high- and low-margin products.

on high-margin products, they sell poorly.

Organizational systems do not support high-margin products.

Low-margin products are priced below competition, while high-margin products are priced above.

Conclusions

Solution

Without a strategic focus

The number of levels you need to move from data to findings depends on the

detail required to support your argument. There aren’t arbitrary lines between

data and findings and findings and conclusions. What is important is that you move

from data to synthesis to diagnosis to solutions. If it takes two levels of findings

rather than just one, that’s fine.

Mike Hastings once worked with a project team that was struggling with se-

quence and messages in its final presentation. They called him in after working

on it for the better part of a week. After thirty minutes, Mike asked them to show

him the logic diagram. They had to reverse-engineer it from the messages they

were trying to share with the client because they hadn’t put one together previ-

ously. Forty-five minutes later, they were able to develop a story line and realized

they needed only about half of the original slides. They also realized that one

area they were pursuing had insufficient data to draw conclusions.

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 113

113 Not Just the Facts

Events, Patterns, and Structure

Another way to label data, findings, and conclusions is events, patterns, and struc-

ture.1 An event is something that happens—a piece of information. A sale was

made, a customer complained, an employee was late for work. An event takes place

at a single instant in time.

Patterns help us to understand how events relate to each other. They are the

relationships among events. For example, sales have been growing in the South-

west region and declining in the North, customer complaints have been increas-

ing for the past six months, employee motivation is on the decline. Usually you

can create a chart or a graph to describe a pattern. When you think in terms of

patterns, you are putting the events in context. You are beginning to answer the

question, “So what?”

Causality is the next level of understanding. The generic question is what

caused the pattern. What caused sales growth to vary between regions?

What caused customer complaints to increase? What caused employee motiva-

tion to decline? Answering these questions gives you insight into the underlying

structure of the situation. Sometimes, however, one level of answers is not enough.

You have to probe more deeply to find out the root cause of the situation if it’s

relevant. In the case of sales growth, if the cause is shifts in population, you may

be able to stop investigating, but if it is a change in management or a restructur-

ing of incentives in one region, you may need to dig further.

Of course, if as you dig you find that you don’t have all the data you need,

you may have to test your hypothesis about the root causes of the patterns of

events that you have uncovered.

Building a Logic Diagram

The first decision you need to make when building a logic diagram is whether your

solution should be portrayed by a single box or by its elements. Although you

are designing an integrated solution for the organization, connections to conclu-

sions and findings may be clearer if you portray its elements.

Assuming you choose to portray elements of the solution, there are only a few

rules to follow when creating a logic diagram. If there is a flaw in your logic dia-

gram, there is probably also a flaw in your thinking. There must be arrows from

each piece of data to at least one finding. If there isn’t a connection (see Figure 8.3),

there isn’t a “So what?” The same holds true from findings to conclusions and from

conclusions to the elements of the solution.

There must be arrows to each solution element from at least one conclu-

sion, to each conclusion from at least one finding, and to each finding from at least

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 114

114 Designing Solutions for Your Business Problems

one piece of data. If you don’t have an arrow, you can’t answer the question,

“Why?” Although there is nothing wrong with having only one finding lead to a

conclusion, it usually indicates a risky diagnosis.

Finally, arrows may not be drawn from findings to the solution elements, from

data to conclusions, or from data to solution elements.

The most practical way to begin to develop a logic diagram is to do so as soon

as you have created the data matrix. A hypothesis is an unsupported conclusion,

and a question that is answered becomes either data or a finding, depending on

the level of detail in the answer. Questions to which you hypothesize answers are

propositional hypotheses. As you find answers to the questions, you turn questions

into data and findings, and as the findings are collected, they provide support

for hypotheses, turning them into conclusions (Figure 8.4). The problem with this

approach, however, is that you may miss some very interesting data combinations,

which could lead to unexpected findings and conclusions, because you have

limited your assessment of the data to verifying or rejecting your hypotheses.

Another approach for developing a logic diagram is to collect all the data first

and sift through them to develop findings. Then diagnose the situation based

on the findings you have developed to create conclusions. In the ideal world,

this is the preferable method: rather than let yourself be swayed by your initial

hypotheses, you let the data talk to you. However, there is a problem with this

approach as well. When you do not construct your logic diagram as you go, you

may not recognize that a line of reasoning is flawed. If you don’t, you may be

FIGURE 8.3. LOGIC DESIGN FLAWS.

Data

Conclusions

Findings Solution

The finding does not lead to a conclusion.

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 115

115 Not Just the Facts

FIGURE 8.3. LOGIC DESIGN FLAWS. (Continued )

Data

Conclusions

Findings Solution

Conclusions

Data

Findings Solution

The circled data element is superfluous.

The circled con- clusion has no findings justifying it.

faced with new hypotheses and data requirements late in the project. It is possi-

ble to overcome this problem by being disciplined about maintaining your sto-

ryboard and keeping close track of those stories that are not turning out the

way you had expected.

Of course, no matter how you approach logic development, it is important

to keep your objective and scoping diagram in mind. It is easy to get sidetracked

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 116

116 Designing Solutions for Your Business Problems

FIGURE 8.4. EVOLVING LOGIC DIAGRAM.

Proposition

Proposition Hypothesis

Conclusion

Finding

Proposition

by a potential conclusion and find more data for it, only to realize that it does not

relate to the issue at hand. When collecting data and developing the logic for the

project, remember that it is just as important to discard data as it is to search for

them. Remember also to check your data for accuracy and consistency in addition

to relevance. Sample the integrity of your data before you use them. Compare

views inside and outside the organization, compare claims made by customers

to those made by salespeople, and compare the perceptions of managers and their

subordinates.

Logic diagrams, although always useful, are much easier to build when you

keep the project’s scope firmly in mind. Mike Griffiths once worked with a client

team that let their logic diagram grow out of control: they ended up with over five

thousand data items grouped under 150 findings. As the team became more and

more uncertain about what they were investigating, interviews became increas-

ingly unstructured and inconclusive. Without a scoping diagram to control the

project, scope naturally crept outward. The data were so unwieldy that before

Mike intervened, the only way the project manager could absorb what had been

collected was to spend his entire two-week Christmas vacation studying fifteen flip

charts of sticky notes containing the data points. Mike and the client estimated

that by developing a scoping diagram and using hypotheses from the outset, they

could have reduced the project’s duration by more than 60 percent.

Answering the following questions will help you assess the quality of your

findings and conclusions:

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 117

117 Not Just the Facts

Do your findings . . .

• Fully test the hypotheses?

• Fully support the conclusions?

• Provide a reliable and accurate summary of the data?

• Seem clear and convincing?

Do your conclusions . . .

• Diagnose problems or opportunities?

• Cover the full scope of the topics?

• Unite the findings?

• Suggest possible solutions?

• Use judgment?

The challenge with these questions, of course, is that they are completely

subjective. Something may seem completely clear and convincing to one person

and utter nonsense to someone else, depending on their background, experi-

ence, and predisposition. This is when your early work on understanding the

situation will stand you in good stead. If you have developed a good understand-

ing of the social and political climate in the organization, you will have a good

sense of what it is that people are likely to accept and what they are likely to resist.

However, nothing works as well as asking people whether they buy an argument,

as long as you do it in such a way that indicates that you care about their answer.

You have to make yourself confrontable when you test your logic, and you have

to listen to what people say. Whenever you are trying to convince someone of

something, you have to start from where they’re starting from, not from where

you’d like them to end up. Appendix B provides insight into how to ask questions

so that you obtain insight into people’s perspectives rather than platitudes or

shallow advocacy.

The Benefits of a Logic Diagram

In addition to the obvious advantages of a logical argument, there are two ways

that the logic diagram assists in the problem-solving process. First, it helps you see

how far along you are in the data collection process and where there might be

holes in your logic. Second, it provides a simple way for you to share your logic

with others. Rather than making someone read a half-finished presentation or

listen while you talk through your arguments, you can show them your logic

diagram and ask them to tell you which parts of it they find convincing and which

need more work.

ap pl ic ab le c op yr ig ht l aw .

vand14310_ch08.qxd 6/10/03 10:12 AM Page 118

118 Designing Solutions for Your Business Problems

The logic diagram can be shared with people who know little or nothing about

your project. You will quickly find out if you are clear and straightforward and

if your arguments make sense to others. It’s amazing how often you think you have

great support for a point of view, only to realize when you share it with someone

else that it’s not as airtight as you thought it was.

Jeff Gill, the director of human resources for Landmark Graphics, once used

a logic diagram when he was the foreman of a jury. After two half-days of testi-

mony, the jury was asked to reach a verdict. Jeff found that they had widely dif-

fering opinions about what they had heard. He suggested they make a list of the

facts they could agree on and then move forward from there.

In consultant development sessions, my colleagues and I ask participants to

go through a case study to learn problem-solving tools and techniques. The ses-

sions culminate with the Logic Challenge: each team is asked to present its logic

diagram to the group and stand by silently while the other teams comment. Often

what appears completely logical and compelling in a team room quickly falls apart

when subjected to the scrutiny of those who are not personally involved.

Summary

The logic diagram is the core of the problem-solving process. By providing a frame-

work to help you connect data, findings, conclusions, and solutions, it allows you

to test quickly whether the argument you hope to use to convince your client to act

is both complete and consistent. Each component can be tested by itself, but it is

testing the whole and answering the questions “Why?” and “So what?” that enable

you to determine whether you are really making sense.

ap pl ic ab le c op yr ig ht l aw .