Why IT communications fail to communicate

One of my client’s business analysts solicited my opinion: “Is this a good specification document?” he asked.

Long ago I’d learned — the hard way — the wisdom of the adage “When someone asks for advice, they’re usually looking for an accomplice.” So I answered his question with a question of my own, asking him why he had asked.

“I gave this to a developer, who told me it was a bad spec. So I wanted your opinion.”

Yup. Accomplice it is.

Still, I looked at the spec. It was a reasonable document as these things go. But like many specs it was bad for one simple reason: The business analyst had used it to communicate specifications to the developer.

It’s a common mistake, and it isn’t limited to business analysts and application specifications. CIOs, IT managers, and, for that matter, people throughout a typical enterprise make it too: They try to communicate with each other by shipping documents back and forth.

While it’s sometimes unavoidable, when it comes to achieving a shared understanding of just about anything, it’s a poor second-best.

The problem starts with how using documentation to communicate ignores the fundamental nature of communication.

The four fundamental flaws of documentation

If you prefer to communicate via documentation — and encourage everyone in your organization to follow suit — four facets of communication are getting in your way.

Language: Every natural language, be it English, Latin, or even Esperanto, is imprecise at best. Synonyms are approximate, not exact; words are defined by other words, leading us down the path of infinite recursion; different people bring different vocabularies and assumptions to their attempts to interpret what they’re reading.

Unless, of course, the language they use to write the spec is pseudocode. This is precise and unambiguous enough. But then we’d have business analysts writing code instead of specs and so what would be the point?

Disambiguation: No matter how even the best writers might try, they’ll never create a document that’s completely free of ambiguity and entangled logic. In making the attempt, many find themselves trudging along the literary path of a different profession for which ambiguity and the likelihood of misinterpretation are equally problematic: They write lawyerly, contract-style prose, which their victims try to make sense of with all the futility of trying to understand the average EULA.

Disagreements: No matter how well a business analyst (going back to our app dev example) describes their design, the stakeholders they’ve worked with to create it aren’t always going to agree on all points. Stakeholder disagreements unavoidably turn into design compromises and, worse, inconsistent specifications.

A CIO’s budget defense document faces similar challenges.

Intermediation: “Disintermediation” is the expensive word for “eliminating intermediaries,” which is exactly what most IT shops don’t do. Instead, they intermediate. Keeping with our BA example, the  typical business analyst’s role is, regrettably enough, to serve as an intermediary, due to the fallacious view that technical professionals aren’t capable of having productive conversations with their projects’ business stakeholders.

This utterly preposterous proposition has been accepted doctrine for decades and it’s long past time to put it to rest. If technical professionals can’t converse effectively with non-technical human beings, how is it that they marry spouses who aren’t technical professionals, raise children whose first words are “Mama!” (or, often, “No!”) and not “<p>Paragraph text</p>,” enjoy backyard barbecues with neighbors who (gasp!) might earn their livings in marketing or accounting, or, for that matter, train dogs to respond to their voice commands?

It isn’t uncommon for CIOs to fall into the same trap. They treat their org chart like a collection of software modules, with well-defined ways for outsiders to interact — basically, like they’re invoking subroutines — and assume all other executives look at the enterprise the same way.

But just as there’s no perfect org chart, so there’s no perfect way to prescribe a department’s outputs and the inputs required of other departments so they get those outputs.

The solution is conversation

What goes wrong, isn’t, of course, limited to IT design documents. These just illustrate the point, which is that when we rely on documentation to communicate we’re asking for trouble, and usually find ourselves in it.

Welcome to the solution. It isn’t particularly complicated. It’s that when people need to understand each other, they need to talk to each other, interactively, using the (I hope) well-known guidelines for active listening. In particular:

• Express interest: The person or people you’re listening to need to be confident you’re actually care about what they have to say about their thinking.
• Let the other person talk: Even if they aren’t talking about the subject you want them to talk about, pay attention to what they want to talk about. They need to get it out of the way before they can focus on what you need.
• Focus: Letting them talk is one thing. Letting them talk forever is something else. At some point, encourage them to focus on the subject you need to talk with them about.
• Ask (1) — clarify: If, as the communicator’s target, you aren’t clear what they mean, ask for additional clarification.
• Ask (2) — re-state: If, as the communicator, you aren’t confident the person you’re communicating with understands you, ask them to re-state it — in their terms, not yours.
• Ask (3) — finalize: As communicator, ask how to phrase whatever the conclusion is when the time does come to document it.
• Remind: When the documentation is complete, walk through it, face-to-face, with the key stakeholders to confirm that it reflects the conversations you’ve already had with them.

If this seems a bit idealized, perhaps it is. You can’t always get face-to-face with all stakeholders, and the bigger the subject the harder it is.

There are also linguistic issues to contend with: If you and the other person don’t have a language in common that you’re both fluent in, relying on a document can be more effective than attempting a conversation.

So in the end we have to accept that sometimes we do have to rely on documentation to communicate. Like, for example, right now as you read these words.