In all the great exploration dramas, there comes a moment when two or more of the principals clash. Should they abandon the canoes and proceed on foot? Should they backtrack through the jungle to rescue Finley from the apes? Should they steal the jewel from the idol's head and risk a perpetual curse?
These are great dramatic moments, but in real-life requirements work, you could happily dispense with them. Unfortunately, different people will have different ideas of what a project requires—which makes exploring requirements into a political battle. Consequently, all the preparation in the world won't save your project from an occasional intense conflict. It may not be terribly serious, but if it isn't handled well, it could mean a bad end to the project.
Out-of-control conflicts tend to damage projects because they reduce the willingness to explore possibilities. Just as in exploring the jungle, most people will run away at the first sign of conflict, rather than stay to see what possibilities are offered. At such times, what you need is another kind of tool: a person who is a skilled facilitator. Skilled facilitators can do more than merely cope with conflict. They can turn conflict into a source of new possibilities.
The first thing a facilitator does is determine whether a conflict is essential or inessential. An essential conflict concerns this project, at this time, and involves the people who are present—we say, "Here, Now, Us."
If the conflict is about another project (not Here), another time in this project (not Now), or people who are not present (not Us), then it's not essential. A facilitator resolves an inessential conflict by making everyone aware it belongs somewhere else. Once the inessential has been stripped away, usually there is no conflict left. If there is, the facilitator can meaningfully apply negotiating techniques, as we'll discuss in Section 13.3.3. The best way to show how a facilitator handles certain inessential conflicts is through some examples.
Jerry was facilitating a requirements meeting in which two participants, Morris and Eileen, took violent objection to the mention of a particular programming technique.
"We've tried that, several times," Morris said, with a tone that implied that the rest of the participants were utterly stupid.
"Yes," Eileen agreed, "we tried it, and it didn't work."
"In fact," said Morris, "it was a total disaster, and killed the project."
"Well," Jerry said, trying to stay calmly in the here and now, "in that case we should know a little more about it. When and where did these disasters take place?"
Morris looked questioningly at Eileen. "As far as I can recall, Eileen, it happened on three or four application projects."
"Yes, I can think of at least four."
"And is this an application project like the others?" Jerry asked.
"No!" Morris said proudly. "This is a systems programming project, which is even harder than an application."
"And why is it harder?"
"Well," said Eileen, "for one thing, we can't use COBOL. This will be programmed in C++ and Assembler."
"And the other projects were done in COBOL?"
"Of course!" said Morris. "All of our applications are written in COBOL."
"And could there be something about COBOL, for instance, that makes this technique inappropriate?"
"Well, sure! COBOL is entirely different."
Suddenly everyone in the room understood that whatever this conflict was about, it wasn't about a technique that didn't work in COBOL. Once they were brought back to the present, it wasn't difficult to find out what the real conflict was, and to resolve it.
Perhaps the most familiar example to illustrate the Here-Now-Us principle is the personality clash—when two people always seem to take opposite sides regardless of the subject matter. If the two people involved have a long history with one another, their clash is usually a case of confusing the past with the present. Something from the past probably hasn't been resolved, and the facilitator has to test this hypothesis. When combatants say things like, "You always. . .," or "You never...," you can be quite sure this is a continuation of an old argument.
When the facilitator asks them if this is really a here-and-now issue, most of the time they'll come to their senses and decide to settle their personal problems somewhere else. If you have the impression it's not that easy to handle such a conflict in the real world, it's probably because you haven't seen a skilled facilitator do it.
If the combatants have little or no history, then you can safely assume the clash is a case of mistaken identity—or, rather, two cases of mistaken identity. Each person somehow sees the other as "just like" someone else in their life, now or in the past. Sometimes these mistakes can be cleared up by recognizing the nature of the problem and providing moderate face-to-face facilitation. At other times, it may be a matter for the psychoanalyst, in which case the best you can do is get professional help.
A personality clash always intensifies when a facilitator attempts to take sides. On the other hand, if nobody can bring the contestants to the here and now, then one or the other must be removed from the project. Quite often, things get better as soon as a person with authority sits them both down and says, "You will both be removed if you don't work this out by the time we leave this room."
Of course, the threat to remove someone can't be an idle one, so what can you do if both of the people are indispensable? In that case, the remedy is simple: Eliminate both of them.
Figure 13-1. When you have two indispensable people who can't get along, eliminate both of them.
No project can succeed if it depends totally on a person who is permanently out of emotional control. The belief the project will fail if one person isn't available merely subjects you to continuing extortion by someone who is emotionally unstable.
The secret to handling this type of conflict is to have the courage of your convictions. The sooner you face facts, the better your chances of success. In our experience, nobody's indispensable early in a project. Delay renders a soluble problem insoluble.
This kind of conflict often reveals flaws in the way the requirements work is being managed, which is one reason you may be reluctant to face it. If you really do feel someone is indispensable, you might take a look at your maps and models, for example, to see why they haven't been understood by everyone.
Another example of an out-of-time, out-of-place conflict is the kind of generic conflict taking place between, say, technical people and marketing people, accountants and auditors, or security people and just about everybody else. There are plenty of essential conflicts between engineering and marketing, but quite often one side or both anticipates conflict with the other. They've experienced such conflict before, and because it was so unpleasant and unproductive, they don't want to experience it again. No matter if these are different people, on a different project, at a later time—they start the conflict before those "bad guys" get a chance to start it first.
The best way to prevent this kind of group prejudice conflict is to provide lots of early opportunities for the parties to get to know one another as human beings before they are forced to deal with one another in their professional roles. Informal gatherings, such as pizza lunches, popcorn breaks, or even a party, can do this job—if you structure them so people don't just sit with their own cliques. Even better is to provide time at the beginning of the schedule for professional team-building activities. Of course, many of the tools used for specific jobs in the requirements process also serve as vehicles for team-building, but be sure they don't come too late to soften the conflict.
Team-building activities won't prevent all intergroup prejudice. Without warning, someone will start spouting such rubbish as, "You engineers are all alike! You can't let go of anything until it's perfect." or "If you weren't always thinking of how to make a quick buck, you marketing types might get a high-quality product that would sell on its own."
When the participants know each other as individuals, however, the facilitator can call upon personal knowledge to bring the participants to the here and now. Then the facilitator asks, "Are you speaking about Bob, or some other engineers you've known in the past?" or "What have you seen or heard from Cally suggesting she is not interested in a high-quality product?"
Similar conflicts arise across management levels within an organization. Level n and level n+1 tend to push in opposite directions, which means a person in a middle level will push differently depending on who is in the room. Sometimes it seems easiest to avoid such conflicts by keeping people at different levels out of the same meeting, but that tactic is a serious mistake. Level differences are most easily handled when conflicts are faced directly with two or more levels represented in the same room at the same time. Everyone is in the same organization, with the same ultimate goal, and the only time it's easy to forget that is when the other people are not visible.
Did you ever smack your thumb with a hammer, or drill into a water pipe concealed behind a wall? Tools are like that. If you use them without giving them your full attention, you can wreck the work and injure yourself. With interpersonal facilitation tools, you may not injure yourself physically, but you can leave psychological wounds from which a project may never fully recover.
To be a good facilitator, you must develop the art of being fully present with the people whose interaction you are facilitating. Of course, nobody can be fully present at all times—distractions are a part of life. However, it's the facilitator's job to notice when it isn't a fully present meeting, and to act. To do this kind of facilitation, you must
1. Be free to notice everything, and don't pretend certain things aren't happening.
2. Be free to ask about anything puzzling.
3. Be free to comment on anything, especially on your own reactions.
4. Be free to comment when you don't feel any of the above freedoms.
With these freedoms, you can say such things as, "I notice John is working crossword puzzles, and I find I'm distracted from the content of the meeting because I don't know what's going on with John. John, can you let me know what's happening for you?" This informs the group you aren't fully present and also calls their attention to the problem of John not being fully present.
Here are some other types of comments the fully present facilitator can make:
1. Although I'm supposed to be neutral at this time, I find myself favoring proposal A because I have no written documentation of proposal B.
2. I'd like to take a five-minute break to gather my thoughts.
3. I'm feeling very angry right now, and i'd like a two-hour break to cool off.
4. I'm unable to follow the meeting when more than one person talks at a time.
5. Phoebe, I'd like to hear everything you have to say, but I'm not sure if you were finished before Marilyn started talking. Were you?
Figure 13-2. Q. What questions does a six-hundred-pound facilitator ask? A. Anything he wants! To be a good facilitator, you must develop the art of being fully present—free to notice, free to ask, and free to comment—but a bit more gently than a gorilla.
The fully present facilitator models the kind of behavior that's desirable for everyone if your meetings are to be effective tools. People who are fully present help others avoid or derail inessential conflict. But how can the fully present facilitator deal with the essential conflicts?
A common type of essential conflict would be labeled "personality clashes" if the term hadn't already been adopted for the inessential conflict discussed earlier. Such conflicts do not involve just two people, but two groups of people, usually with everyone in the room taking one side or the other. These conflicts don't arise because one professional group stereotypes another. They arise because people even in the same professional group have different personalities, so what meets the needs of one may threaten another.
For instance, some people are more naturally optimistic than others. Some people prefer to wrap up all the loose ends, while others like to leave a few possibilities open. Some primarily want a reward, while others have a greater need to avoid punishment. Some need to feel in control of the situation; others want to be under the control of the situation.
To handle such essential personality conflicts, you as the facilitator start by acknowledging what is going on and then working toward each group's accepting they all have a perfect right to their own desires. However, they do not necessarily have any right at all to satisfy those desires (Figure 13-3). This acceptance means everyone must forego name-calling, which most people will agree to when it's made explicit.
Figure 13-3. Meetings run better if everyone understands we all have a perfect right to our own desires—though not necessarily to getting those desires satisfied.
The acknowledgment and acceptance of this "desires principle" will be advanced if you can put a positive interpretation on both sides—something the other side can recognize at least as well-intentioned and reasonable, if not correct. We call this step reframing. A facilitator might reframe the conflict as follows: "I hear one group saying they'd like to save time by making this the final document. I hear the other group saying that although they know of no exceptions at the moment, they would like to leave the document open to changes, just in case. Is that a fair statement?"
When you find a reframing of the situation with which both groups can agree, you will definitely have eliminated the name-calling and forced each side to acknowledge the right of the members of the other side to have their own feelings. You'll then be in a position to seek the third way—a reframing that offers members of each side at least some of the safety they need. In our example, both sides agreed the document could be made final, with an amendment procedure designed to be used in case something unforeseen arose. The amendment procedure was difficult to use, so it would not be abused with frivolous amendments.
Obviously, the effective facilitator must understand negotiations and be able to lead negotiations in which the participants might not be very skilled. In a meeting between a service bureau and some of their customers, the "optimists" (customers) argued there could never be errors in the input data—so they wouldn't pay for error-handling programs. The "pessimists" (service bureau people) simply could not accept this assumption.
The two sides argued to no avail until the facilitator observed, "You are arguing about a fact, a fact which cannot be known until the future. Each of you has experiences in the past to make you believe your prediction about input errors is correct, but nobody will really know until after this system is built." This statement brought the argument to a halt, but with both sides turning on the facilitator.
Now, if you can't stand people turning on you when you make true observations, you won't be very good at facilitating requirements meetings. Every requirements process we've ever facilitated has had at least one argument about facts in the future. In this case, the facilitator stilled the attacks by proposing, "Since we don't know how many errors there will be, suppose we set a price to be paid to the service bureau for each error in the input. For example, since these customers believe there won't be any errors, we can set the price at the cost of running the job again, after the error has been corrected."
In the face of large potential rerun costs, the customers agreed they didn't really know for sure there couldn't be any errors. They accepted the service bureau's offer to assist in conducting an error study, and eventually agreed to pay for programs to handle the five most common errors. They also agreed any other type of error would result in a paid rerun, or acceptance of the resultant faulty output.
What the facilitator did by this proposal was to begin a process of revealing and testing assumptions. Sometimes people get angry when you reveal their assumptions—but less angry than they will be when they later discover their assumptions were wrong. Over the years, we've learned to welcome this kind of conflict. Why? Because it's a powerful tool for revealing contradictory assumptions. Of course, if we didn't know how to handle the tool, we wouldn't welcome it.
Once you've stripped away the inessential conflicts, the true personality differences, and the differences in information, you're left with the essential political conflicts existing in all development projects. Some of the classic conflicts are
1. quality versus planned development time
2. cost versus planned development time
3. cost of quality versus planned development time
4. project payoff versus actual development time
5. security versus access
6. full functionality versus reliability
Don't be discouraged if you run into one of these essential conflicts in your requirements work. In fact, if you don't surface these essential conflicts, it's a sign you don't yet understand your problem. During the requirements phase, the facilitator's job in the face of such essential conflicts is easy. In fact, it consists of only two parts:
• Keeping everybody calm by reminding them these are perfectly natural conflicts.
• Convincing everybody to resolve these conflicts in the design phase.
The resolution of such essential political conflicts is the job of design, not requirements. The requirements job is to state, for example, what level of quality is required and what development time is allowed. When the design work is done, there may not even be a conflict between these two requirements, in which case everyone would have wasted precious breath arguing about them during the requirements process. Not only that, but if someone wins the argument, you may wind up compromising quality unnecessarily because the true desires were omitted from the final requirements document. Any compromise made in the requirements stage is no longer available for the designer to attempt to resolve in a creative way.
1. There are times when it's worthwhile to retain a professional facilitator, who can offer several benefits. Experienced facilitators have lots of practice to polish their facilitation skills, and they have no personal stake in one outcome or another—so it's easier for them to avoid getting embroiled in any conflict.
2. Experienced facilitators can serve as trainers for your own facilitators, who may be talented but not very experienced. Although we are both professional facilitators, we rarely accept facilitation work where we don't have the opportunity to train one or more of our client's people in facilitation skills. That's because using local facilitation has many advantages over retaining outsiders. First and foremost, local people can be available throughout the life of a project, even when meetings are called suddenly. Indeed, those sudden meetings are most in need of facilitation because they're likely to lack planning and yet be held in an emotionally charged situation. So even if you hire outsiders, consider using them to train your own facilitator corps.
3. We encourage our clients to "stockpile" good facilitators. They start by identifying people who have already displayed some native talent for this kind of work, regardless of their technical background. Technical knowledge is not essential for facilitators, and in many cases, it's an advantage to the facilitator not to know too much about the technical content of meetings. When they do have such knowledge, they more easily become embroiled on one side or the other of a conflict—even when the technical content is merely a mask for some inessential conflict.
4. We like to create a volunteer facilitator corps, or support team, distributed as widely throughout the organization as possible. These volunteers take outside training, observe and critique one another, share experiences, and volunteer their services. In a short time, the demand for their time greatly exceeds their availability, because people rarely understand just how useful a skilled facilitator can be until they have experienced one. After they've experienced one, they won't waste their time and emotional energy trying to get along without one.
5. Good facilitation is like good police work. When it's done well, you may not notice anything being done at all. That's why projects sometimes fail to appreciate the people who are facilitating their meetings. If everyone has some training in facilitation skills, the facilitators' jobs will be easier, because they will have a more cooperative and appreciative audience.
Every project will experience conflict, and it cannot succeed consistently without some kind of facilitation. Some projects are lucky enough to have "amateur" facilitators who can act appropriately when the need arises. But if you don't want to depend on luck, develop a corps of trained facilitators.
It's never a good idea to conduct any requirements meeting without a facilitator, because you can't predict when intense emotions will erupt. A good facilitator, however, will prevent most of the inessential conflict, and minimize the rest.
This chapter is intended to stress the importance of facilitation, not to make you a skilled facilitator. Many good books about facilitation are there for the reading.
Every participant should take responsibility for facilitating meetings, but a few people should be professionally trained as specialists in the job, which has its own highly developed skills.