'Solving Two Enduring Puzzles That Confound System Analysts and Designers'
by Don Rossmoore, Ph.D.
and Susan Nero, Ph.D.
There are two puzzles that confound systems analysts:
Why do others resist our good ideas about a system?
Why don't we get the spec correct? Or, why do users think we did not get the spec correct even though we gave them what they said they wanted?
Communicating about management intentions and systems is universally problematic. Research conducted over the past 25 years demonstrates repeatedly that adequate communication and understanding are not the norm in organizations.*
In fact, for systems analysts, miscommunication may be the greatest single cause of user resistance and designer error.
Correct communication requires special skills and training. It is not enough to simply exhort professionals to ask more questions. A systematic approach must be taken to recognizing the most common and unproductive communication patterns, followed by the development of new listening and speaking skills.
Without special training, even the most experienced professionals will maintain a belief in some well-meaning but faulty assumptions about human nature. These assumptions are so pervasive and universal that they are seldom noted or discussed. Unfortunately, they undermine even our most diligent attempts at effective communication.
The two key postulates in these faulty assumptions are that:
People act rationally.
What people think and say they do is actually what they do.
This is an optimistic, humanistic view of behavior, and these two postulates appear to represent a benign and trusting approach to human relations. However, if we test them against actual behavior, we will find that neither holds up. People do not act rationally and they do not behave as they believe they do. The mistaken assumption that they do often leads us into complex misunderstandings and mistrustful relationships. This discovery is central to solving our two puzzles.
Our research and consulting experience have led to a less optimistic, but more accurate, description of human behavior. We have tested the following postulates and found them to be much more useful:
People act defensively rather than rationally.
People are unaware of the difference between what they do and what they think they do.
The more important and stressful the situation, the more these postulates hold true. Unfortunately, this reality is seldom articulated in the IS environment, and the IS professional will find little precedence for incorporating it into her/his world-view. However, once professionals earn to see their world of communication through this lens, they can bring into focus important patterns of behavior that are common to all of us, and start developing effective communication. Stated simply, these behaviors are as follows:
(1) People avoid open, explicit discussion of tough and threatening issues.
In every organization we studied, there were several "undiscussable" issues that were nevertheless well known by many parties. In fact, they are often spoken of candidly in off-the-record and informal conversations -- but bypassed in forums where decisions get made. When an issue remains publicly "undiscussable" there is little chance that it will be managed productively. The more important the undiscussable issue, the more serious the implications for the organization. Here is an example of one undiscussable issue and its effect on an organization:
The top management team of a start-up mainframe computer manufacturer decided to double their head count and increase leased space by 50%, based on the Senior Marketing Vice President's sales forecast. In meetings, each of the other four members of the top management team supported the senior marketer's forecasts, but privately, they expressed serious concerns about their colleague's competence and mental health.
The senior marketer's revenue forecast for the first two quarters of the new product launch was $16M. Actual revenues were less than $4M. Because of the increased overhead, the company's cash reserves would be exhausted in less than four months. Suddenly, the top management team had to decide between a significant reduction in headcount and a significant new infusion of venture capital.
This financial crisis was an acute symptom of the chronic and critical underlying issue of the senior marketer's competence and mental health. Until that was confronted and discussed, the organization was wedded to a cycle of incompetent decisions.
The remaining three behaviors usually occur simultaneously. If we look closely at any attempt at communication, we may discover multiple occurrences of the following communication mishaps:
(2) Even when we think we are being precise and clear in our speaking, it is seldom the case that others are hearing us that way.
(3) When we hear information, we fill in the gaps and ambiguities with inferences based on our own beliefs, desires, and perceptions. Consequently, what we hear differs from what the speaker intended.
(4) Neither the speaker nor the listener is aware of the differences between what was intended and what was heard. Following are three anecdotes showing these patterns in action.
a. Sam's Folly, or The Case of the Missing Phrase
Sam, manager of Product Group X, is about to go on a month-long marketing trip to Europe. Paul, the assistant manager, will be sitting in for Sam. In his final briefing, Sam intended to give Paul the following instructions: Track the financials for each product weekly, and as soon as you see a cost over-run of more than 10%, alert division. Track shipments daily; as soon as any product slips more than $50K below its monthly objective, pull all your spare people and have them build the product until you are back on schedule. Monitor documentation very closely to make sure that no engineering changes get built without complete documentation. Do this by checking the weekly ECN print out. Do not do it by asking Chuck, because he is not reliable on documentation.
Sam's sent message included all of the above information except the part about checking the weekly ECN report rather than relying on Chuck. The consequence was that Paul monitored documentation by checking with Chuck. A key engineering change got built and shipped before it was documented. Two months later, the absence of this documentation led the product line to duplicate the design work at a cost of $180K. In this situation, a communication "gap"--a discrepancy between what was intended and what was actually said--occurred.
b. A Case Of Ambiguity
A division manager, Al, is told that he must cut $11 million from this year's operating budget. Al decides that he wants Product Group A within his division to cut $4.2M out of its budget. Al gives Harry, the manager of Product Group A, the following instruction, "Harry, I want you to cut as much as you possibly can out of your current operating budget." Harry cancels a weekend ski trip with his family so he can cut his budget. Monday morning he presents his budget cuts, which total $2.7M, to Al.
Al's intended message was, "Cut $4.2M." His sent message was, "Cut as much as you can." Harry does not know that Al has a precise figure in mind. Al remains unaware that he has not communicated that figure and is likely to perceive Harry as at fault for not following his instructions.
c. George Tells It Like It Isn’t
George, an engineering supervisor, has been extremely
unhappy with Brian's performance for over a year. Though his design work is
excellent, he comes to work late and he leaves early. When he is in his office
he always seems to be on the phone on a personal matter. If he is not on the
phone, he cannot be found, or he is at the coffee machine shooting the breeze
with the secretaries. George has decided that unless the Brian's performance
improves measurably he will fire him. George prepares to let Brian know of
this decision. When he calls Brian into his office, he says, "Brian,
I am quite pleased with your technical performance, but I think it would be
helpful if you improved your citizenship."
The intended message was, "Improve dramatically or be fired." The sent message was, "You're doing fine, just tidy up your citizenship." The sent message did not let Brian know about George's intention of firing him. After the meeting, George was unaware that he had not let Brian know of his intention to fire him. Two months later when Brian had not improved his performance in the ways George wanted him to, George fired him and Brian was genuinely surprised. In this case there is a very significant discrepancy between the sent and the intended message.
Normal Communication Strategies and Errors
All people in all organizations have a common history of miscommunication, including information systems design and implementation projects. In fact, an IS project can be recognized in retrospect as a continuous chain of communication errors. In our research and consulting, we call such errors "normal," because they reflect the flawed way that communications are normally handled. Breaking this chain of errors does not come naturally or easily. We all continue to make these normal errors and then find ourselves creating elaborate compensations for them later.
The beginning
step in breaking the chain is to understand the dynamics of the "normal"
strategies for communication. The next step is to recognize errors as they
occur, and to understand both the benefits and costs of these errors. The
last step is to develop new communication skills and put them on-line. But
these new skills cannot be developed until the first two steps are taken.
Although it seems paradoxical that errors could have benefits attached to them, our experience has shown us that they have a perceived value, which keeps us repeating them. In fact, we often commit these errors in the service of being a good team player or a competent professional. We consider them good behavior.
But many of the rules of good behavior clash with the rules of productive communication. It begins with what is the common experience in organizations: each person believes that, "If I state my true concerns and beliefs, I will undermine my position, my relationships, or my tenure." Yet each person also knows that, "If I don't state my true concerns and beliefs, we won't succeed." This is a universal dilemma. Most of the time we attempt to manage this dilemma by following a set of unwritten rules about how we should communicate:
The Unwritten Rules for Communicating in Organizations:
Don't share your true concerns and beliefs when doing so violates the rules of good behavior.
Camouflage your concerns and feelings to avoid violating the rules of good behavior (and act as if you're not).
Don't explicitly test your understanding of what someone else has said (so you don't risk looking stupid).
When someone says something that is unclear, make your best guess (without letting on that what was said was not clear to you).
When raising issues or voicing concerns that violate the rules of good behavior, take control in ways that limit others' ability to challenge or confront you (while trying to appear both fair and reasonable).
These communication
strategies benefit our sense of personal security and social propriety. But
that yields only short-term gain, for it has value to us only in the
moment. In the longer run, necessary conversations do not take place, vital
information is not shared, and our ability to analyze systems and solve problems
declines dramatically. Ultimately, our sense of personal effectiveness is
undermined. In an IS project with strategic implications, this is what often
happens:
Two Signature IS Problems
1. Disagreements over things such as strategic direction, systems specifications, and control of information remain undiscussed and unresolved. Example:
A global financial services company needed to define its business strategy for the next ten years in order to articulate the specifications of its new operating system. However, in the planning meetings held by senior managers, the subject of where key transactions would take place was never discussed. Privately, the marketing managers insisted that key transactions would be processed regionally. And the operations managers privately insisted that these transactions would continue to be processed centrally.
Central processing required significantly different specifications from regional processing, and was more profitable for the company. This important issue was consistently avoided at the planning meetings.
These senior managers all reported to the CEO, who chose not to attend the planning meetings. When he was told of the private disagreement, and was encouraged to get involved in the decision-making, he responded, " I don't have time. If these guys can't come to a decision without me, then I have the wrong people working for me."
In this example we see a key disagreement over strategic direction not being discussed among the people who disagree. And we see the one person with the necessary organizational authority to resolve the disagreement avoiding involvement. The result was seriously slipped timetables and constant off-line bickering among all the group involved.
2. Mismatches between analysts' proposed ideas and what users said they wanted. This leads to users resisting analysts' ideas, insisting the analysts did not get the spec correct. The result is escalating mistrust between users and analysts. Example:
A new system has been on-line for less than a year. IS is still working hard to modify the system to conform to user requirements. In a meeting between a key user and an analyst, the following communication takes place. User to analyst: "In the future I'll need to be able to answer a wider array of questions about traffic and traffic patterns of our major accounts."
Analyst hears: "In the future I'll need on-line access to all information on telephone traffic of our major accounts." The analyst proceeds to develop a design for an on-line database that includes full detail on all telephone calls made in the systems operating regions. This gives the user significantly more information than he wants, and increases the cost of the report unacceptably.
We can see that
the analyst did not check his understanding with the user. He assumed he understood
what was meant. And the user assumed the analyst understood him. Later, each
blamed the other for the misunderstanding, complaining either of incompetence
of or bad intentions. The chances for this relationship improving
are very slight. Future exchanges between the two parties are bound to be
strained and guarded, so that, rather than sharing more information, each
party will walk on eggshells around the other, making the information flow
minimal at best.
Four Basic Requirements of Productive Communication
The skills needed to reverse these scenarios are built on four foundations: Inquiry, Trust, Collaboration and Joint Control, and Completeness. When our communication is built upon these elements, normal communication errors seldom occur.
Inquire: detects
and fills gaps in communication, detects and clarifies to ambiguities,
and ests for differences between the message heard and the one intended
by the speaker. Because inquiry takes time and perseverance, and
can be annoying and stressful, it is often experienced as inefficient; however,
it almost always takes more time to correct communication errors downstream.
TRUST: Productive communication is always risky, because it violates the rules of good conduct. Individuals who strive for it must trust that they will not be penalized either for those violations or for uncovering disagreements or errors. Without sufficient trust, individuals will retreat back to the rules of good conduct.
Trust must be
built before anyone will risk communicating productively. , Paradoxically,
building trust requires that people discuss their concerns about violating
the rules of good conduct -- which discussion is itself a violation of those
rules. Agreements must be made, and upheld, regarding a suspension of the
rules. Emotions will be stirred by the violation of the old rules, and these
must be managed responsibly.
Trust can not be mandated. It is built incrementally in a delicate interplay between risk and support.
COLLABORATION AND JOINT CONTROL: Productive communication is the joint responsibility of the speaker and the listener. It is the speaker's responsibility to strive to avoid gaps and ambiguities, and to encourage and support the listener's inquiry. The listener must make sure he or she understands what was said, by repeating it back, and asking about perceived discrepancies. Neither person controls the communication, even if one has more power or status than the other. Each is equally responsible for the quality of the outcome. This works the same way in groups as one to one.
COMPLETENESS: Completeness is achieved when there are no gaps or ambiguities. Completeness is a function of inquiry, trust, and joint control. Give and take between speaker and listener, checking and re-checking for discrepancies between what is intended and what is heard, produces complete communication. Both parties will know when completeness is achieved, and will take the time necessary to reach that end.
An Example of Productive Communication
Bill: You should never bother the customer with routine problems that can be handled in house, because we have found the more we go to the customer with those kinds of problems, the more likely it is that the customer will get alarmed, instead of feeling good about being informed. Do you have any questions or comments at this point?
Art: Not yet.
Bill: I'd like to try to be more complete and precise about this if I may?
Art: Sure.
Bill: Let me try to be more precise by giving you a hypothetical example. Let's say you are in the middle of solving a routine problem and the customer calls and asks you how things are going, and whether or not you have any problems. I think it is appropriate to say either that there are no problems, or say that the only problems you are encountering are the predictable, routine kinds of problems that always surface at this stage of development. I'd like to know what you think about what I'm saying.
Art: I thought it would be a good idea to keep the customer as informed as possible.
Bill: How were you thinking of doing that?
Art: To check in regularly, maybe once a week, maybe once every other week.
Bill: And by checking in, what do you mean?
Art: Let him know about any problems. Ask him what, if anything he needed from us to support him on his end.
Bill: I like the second part, about asking him what he needs from us. May I ask what your definition of "any problems" is?
Art: Well, before we talked, it included routine problems, now I don't know.
Bill: In the first project I managed, I wanted to manage the customer interface as well as I could. And my way of doing that was to keep the customer very well informed. I let him know about every problem. And then one day I got called into my boss's office and he asked me what I was doing. He told me that he had just gotten a call from my customer asking that I be taken off the project immediately. The customer apparently told my boss that he had never been involved in a project that had so many problems before. From that I learned there is a big difference between keeping the customer informed and making him anxious. What do you think about what I am saying?
Art: It sounds as if I was about to do the same thing you did. I know it is important to keep the customer informed, but I am not sure, now, how to do that.
Bill: The way I do that, now, is to notify the customer every time we discover that we have a problem that is not routine, that has a high likelihood of causing a schedule slippage, or we have to go outside to find a solution. I call him up. At the same time, I put all the documentation we have on the problem, our diagnosis, and our proposed solutions in the mail to him, and I ask him how he would like to monitor our progress at that point, and I try to follow up on what he says he wants. What do you think?
Art: I like the idea of sending him the documentation and asking him how he wants to monitor our progress.
Bill: What do you think of my definition of when it is appropriate to notify the customer?
Art: Well, I'm not sure how it is different from mine.
Bill: If you said what I thought you said, I think your idea is to notify the customer any time you have a problem, even a routine problem, is that right?
Art: Yes, it is.
Bill: My idea is that you never bother the customer with routine problems that appear to have a moderate to high likelihood of being solved in-house within an acceptable time frame. My idea is that we notify customers only about problems in which there is a high likelihood that either we need to go outside for a solution or the problem will cause us schedule slippage. Do you see the difference in our positions now?
Art: Yes, I think so.
Bill: I think this is a very important point, so I would like to know what you think I just said, if you don't mind.
Art: I don't at all. There is a difference between us as to when we would notify customers. I would notify a customer of every problem. You think that will cause the customer to get anxious rather than informed. What you would like to see me do, instead, is to notify the customer any time I have determined there is a high likelihood either we will have to go outside for a solution or we will slip schedule. The way you would like me to notify the customer is to call him and then mail all the relevant documentation and ask him how he would like to monitor our progress. Did I get it?
Bill: Yes, you did.
Notice how this conversation generates increasingly intricate layers of insight and precision of thought. Neither person hesitates to ask the other questions or check out an interpretation or understanding. This could have been a much shorter exchange. It could have taken up less time, but it would not have led to this degree of mutual understanding and respect. And the extra time it took will be saved many times over down the line. We can imagine that in the future Art and Bill are likely to maintain good will and cooperation without taking action that will create a problem for either one of them. This is the type of communication needed in IS organizations, the only guarantee against the chain of misunderstanding, ineffective action, and mistrust which is so common in IS projects. This is the solution to our two puzzles.
article - Copyright© 1997 Don Rossmoore
Copyright© 2012 Don Rossmoore.