One of my client\u2019s business analysts solicited my opinion: \u201cIs this a good specification document?\u201d he asked.\n\nLong ago I\u2019d learned \u2014 the hard way \u2014 the wisdom of the adage \u201cWhen someone asks for advice, they\u2019re usually looking for an accomplice.\u201d So I answered his question with a question of my own, asking him why he had asked.\n\n\u201cI gave this to a developer, who told me it was a bad spec. So I wanted your opinion.\u201d\n\nYup. Accomplice it is.\n\nStill, 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.\n\nIt\u2019s a common mistake, and it isn\u2019t 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.\n\nWhile it\u2019s sometimes unavoidable, when it comes to achieving a shared understanding of just about anything, it\u2019s a poor second-best.\n\nThe problem starts with how using documentation to communicate ignores the fundamental nature of communication.\n\nThe four fundamental flaws of documentation\n\nIf you prefer to communicate via documentation \u2014 and encourage everyone in your organization to follow suit \u2014 four facets of communication are getting in your way.\n\nLanguage: 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\u2019re reading.\n\nUnless, of course, the language they use to write the spec is pseudocode. This is precise and unambiguous enough. But then we\u2019d have business analysts writing code instead of specs and so what would be the point?\n\nDisambiguation: No matter how even the best writers might try, they\u2019ll never create a document that\u2019s 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.\n\nDisagreements: No matter how well a business analyst (going back to our app dev example) describes their design, the stakeholders they\u2019ve worked with to create it aren\u2019t always going to agree on all points. Stakeholder disagreements unavoidably turn into design compromises and, worse, inconsistent specifications.\n\nA CIO\u2019s budget defense document faces similar challenges.\n\nIntermediation: \u201cDisintermediation\u201d is the expensive word for \u201celiminating intermediaries,\u201d which is exactly what most IT shops don\u2019t do. Instead, they intermediate. Keeping with our BA example, the typical business analyst\u2019s role is, regrettably enough, to serve as an intermediary, due to the fallacious view that technical professionals aren\u2019t capable of having productive conversations with their projects\u2019 business stakeholders.\n\nThis utterly preposterous proposition has been accepted doctrine for decades and it\u2019s long past time to put it to rest. If technical professionals can\u2019t converse effectively with non-technical human beings, how is it that they marry spouses who aren\u2019t technical professionals, raise children whose first words are \u201cMama!\u201d (or, often, \u201cNo!\u201d) and not \u201c<p>Paragraph text<\/p>,\u201d 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?\n\nIt isn\u2019t 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 \u2014 basically, like they\u2019re invoking subroutines \u2014 and assume all other executives look at the enterprise the same way.\n\nBut just as there\u2019s no perfect org chart, so there\u2019s no perfect way to prescribe a department\u2019s outputs and the inputs required of other departments so they get those outputs.\n\nThe solution is conversation\n\nWhat goes wrong, isn\u2019t, of course, limited to IT design documents. These just illustrate the point, which is that when we rely on documentation to communicate we\u2019re asking for trouble, and usually find ourselves in it.\n\nWelcome to the solution. It isn\u2019t particularly complicated. It\u2019s 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:\n\nIf this seems a bit idealized, perhaps it is. You can\u2019t always get face-to-face with all stakeholders, and the bigger the subject the harder it is.\n\nThere are also linguistic issues to contend with: If you and the other person don\u2019t have a language in common that you\u2019re both fluent in, relying on a document can be more effective than attempting a conversation.\n\nSo 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.