Communication can fail in many ways. The Dilbert above is an example of how too much communication can result in the opposite of what is intended.
But often the first failure in communication is to communicate at all.
In the literature you can find abundant examples of how communication can go wrong. IT is a subject area where Communication is crucial, yet somehow especially hard.
Let's try to give some obvious cases:
The most obvious one is NO communication. This one comes in many disguises.
1. No communication by lack of preparation. An employee is fired on the spot, and leaves. Now this aint much of a problem in a warehouse, but an employee working on a datawarehouse system probably has lots of knowledge in his head which was never documented in designs, or fragmented. Now the manager firing the employee will probably realize that a newly appointed employee taking over has some problems, as the situation is pretty obvious.
These kinds of situations are sometimes unavoidable, but one precaution organizations can take is making sure that documentation is up-to-date and that userids / passwords can be recovered by a central department, or institute policies that managers always have useris/passwords of all servers and systems.
2. KT is easy, isnt?
An employee takes over the maintenance of a system as an employee leaves for another company. The manager plans a series of KT (Knowledge Transfer) sessions between the two employees. The manager may feel that after 5 sessions the new employee should be able to take over the job seemlessly. He may be in for a disappointment. The new employee, depending on training and experience, may be able to perform many of the regular tasks if his predecessor, but may run into a few problems when a major overhaul is in place. It is very likely that some essentials have been missed during KT.
Now job transfer is something unavoidable, but one should realize that a series of job transfer sessions is always incomplete.
3. Listening is hard
During design, a designer may think that he understands that requirements documented. While reading or listening, our minds make up images based on the words of the author / speaker, AND based on our own experiences.
For example
Speaker: I bought a new car.
Listener: pictures a standard person car.
Speaker: It's a very big one.
Listener: pictures a small van.
Speaker: It's a beautiful red one
Listener: pictures a red van.
Speaker: and all its wheels are well balanced
Listener: expands the image from a van to an 18-wheeler.
One thing that you can do to make your communication clear is to communicate as much as possible, to repeat information and to check with the listener what he understood.
4. People who are quarreling. One of my first employers, a management consultant, was hired because a certain administrative proces took weeks for every oprder to complete. He quickly discovered that two people, sitting in different rooms, but who were at consecutive posotions in the process, were at odds with each other.
Now a normal request in the process did not cause much trouble. A took the form, approved it, and sent it on to B. B. could do his task. But if something was not OK, he scribbled something on the form and sent it on to B. B simply returned it with something like 'not clear'. That could continue for weeks.
My employer redesigned the process in such a way that A and B were no longer consecutive in the process, and things moved a lot smoother.
Though this example sounds exaggerated, little or no communication due to quarrels or irritation appears more often than one may think. While writing this post I was asked to solve a functional design discrepancy. One designer, let's call him J, had written a functional design. He had received a new document code C12012 for a certain document from another designer, W.. He sent his document around to several people for review, and got some comments back. W, who was responsible for the system that received the documents, reviewed that the code should be C12012, not C12012 Attachment A.
Somehow this review was not received by J. Hence he did not update the functional design, and the system was configured wrongly.
Now IF J. and W. had been friends, J. would have asked: hey, why didn't I receive any review from you? But as a little bit of irritation between the two designers had built up over several years, J. didn't take the trouble to walk to W.'s room. He just went ahead with the review comments he had received from others, assuming that was all. And so an error crept into the configuration, which was somehow not discovered during integration test, went into production, was withdrawn, and a patch had to be made. The total correction effort, due to complexity of environments, was several weeks. All this could have been prevented with some extra communication: "hey, i got the reviews of others, but not yours yet? You had no comments?"
5. Assumptions are the mother of all ....
If some crucial bit of information is missing, the reader/listener will either ask (if he realizes he misses something) or assume. The latter can be very dangerous.
One trick to kill assumptions is to ask the listener to rewords what he understood, but that wont work for readers. A pitfall to avoid is using half-worded sentences, like : DVB message as existing stream of FUS.
Actually this sentence combines to things. First, it uses 2 abbreviations which are not explained. Second, the message of the sentence is not clear. Is it a requirement that all DVB messages are like existing FUS? Or is it a general property that holds for most DVB message? Or are the messages totally different, but are their flows similar? The sentence has several short comings. The most obvious one is that a verb is missing, and you should always beware of 'sentences' without a verb.
6. Lack of context.
I recently read a design that started with:
The ATM will be changed to direct the MQ in such a way that XHT will no longer obstruct THX.
Gr8, guys and gals. With some guessing i can deduce that ATM does not stand for Automated Teller Machine. But it would have been a lot easier to understand with something like:
This design concerns the way messages from the systems XHT, THX and ATM are routed over the enterprise service bus (ESB). For the functions and details of the XHT, THX and ATM systems please consult the documents [2], [5] and [13] mentioned in Appendix B.
This sentence describes context. It does not give the aim (why are we doing this?) but it does give a setting.
Frankly, I never find the reason: "Oh, but every one knows what ATM stands for" a valid excuse. ALWAYS give a setting, there are bound to be times when the stuff is going to be read by people who don't know the setting.
