False Consensus

As an information systems designer and developer, I specialize in bridging the gaps between existing technologies. As a consequence, my projects often involve more than one group inside the client organization.

Sometimes when I am dealing with multiple groups, I find myself stymied in the requirements-gathering stage of a project. I keep hearing a nice, shallow, consistent story from all the parties and I am highly confident that near-perfect consensus has not actually been achieved.

I should state that I do not worship at the altar of consensus. I prefer consensus. I strive for consensus. But I do not insist on it, or pretend that it is always worth the effort. Sometimes people within an organization have different views or goals and sometimes one side needs to win and the other side needs to lose so that the organization as a whole can win.

Alas, apparent near-perfect agreement is, in my experience, most likely to be based on miscommunication and often deliberate miscommunication. Since so many organizations do worship consensus, it is often seen as unprofessional to disagree. To avoid seeming unprofessional, or antagonizing the boss, people bend their words to simulate agreement. I call this "false consensus" because all parties only seem to be in agreement.

Without public and acknowledged disagreement, there is little chance of conflict resolution. (I do not mean to imply that rudeness or aggression are called for; instead I mean to imply that resolving a conflict usually requires that the conflict first be acknowledged and explored.)

As long as we are in the realm of words, and not in the realm of action, this word-bending works or at least appears to work. But once action is called for, as in the implementation of a piece of software, the false consensus is exposed. Often it is not recognized and is expressed as a software misfeature or bug, which it is not.

For example, some years ago I worked on a project to create an HTML document for a customer. There were some real issues to be decided about the actual purpose of this document:

• was it supposed to help customers place orders?
• was it supposed to help customers understand the response to their order?
• was it supposed to help internal users process the orders?

The answer was "yes". This wonder-document was supposed to serve all three very different audiences at once. I was highly confident that this was impossible, so I suggested that we create three documents instead, but that was deemed unnecessary, and just the sort of thing that consultants do to pump up our fees.

I tried a different approach: which items from the product catalog were to be included? This was an easy answer: all of them: why would any items ever be left out? So I gave up and did as I was asked.

At the first review of the document, there was horror: what were the internal items doing in the document? The folks who dealt with orders wanted the non-ordering items removed. The folks who dealt with post-processing wanted the order-only items removed. While we all agreed that "everything" should be in the document, there was no agreement on what "everything" meant. When I pointed out that "everything" generally means "all of the members of a given set" there was eye-rolling and muttering about the difficulty of communicating with computer people.

Eventually, at the end of the project, when it was most expensive and stressful to do so, we hashed out answers to the questions that the false consensus had obscured.

I still do not have a good strategy for coping with this issue, because often there are powerful internal political and social forces at work driving the people working for the client to pretend to agree utterly on utterly everything. All I can do is try to estimate the project impact of this practice on my projects and charge accordingly.

I would love to hear about ways to get around this and I would love to know if other IT professionals encounter the same issue; maybe I need to get out more.