When I set about documenting an organization’s management system (or a part of it) I usually use one of two types of software packages: either a mind-mapping program (such as MindManager or MindGenius for a PC, or iThoughtsHD for an iPad) or a flowcharting one such as Visio or Promanade. [This isn’t meant to be a plug for those programs but I use them and suggest you might like to give them a try.] Promanade is my favourite, mainly because it’s the easiest program I’ve found that draws deployment flowcharts – flowcharts that focus on the two crucial tenets of responsibility and communication. From the above title, it shouldn’t come as a surprise that I want to talk about the second of those…
Communication between participants is vital in any enterprise and two key types are communication between co-workers (sometimes called horizontal communication), and communication between customers and suppliers (vertical communication). The difference between these two lies in the nature of the relationship and the protocols to be observed, often reflecting the balance of power between the communicating parties, rather than the method (although there may be a greater requirement for formality with the latter). In the Promanade flowcharts, each task has a person assigned as being responsible; others involved are either assisting, consulted or informed. The consulted and informed parties are not active participants in the task but, instead, are recipients of communication – and the key difference is that consultation requires a response. These may also be thought of as one-way and two-way communication; and an acknowledgement of receipt is not the differentiator – consultation requires a more involved response, a commitment beyond a delivery receipt. Consultation requires a relevant response, perhaps approval of the information communicated, disagreement or a reply with further information for consideration. Another way of considering them are as having a passive recipient (informed, one-way) or an active recipient (consulted, two-way).
It’s important to differentiate the need when developing work processes and a common error is to assume agreement or acceptance. For example, let’s consider contract review (a common part of almost any ISO9001 compliant management system). An enquiry has been issued by the customer and a tender submitted based on the supplier’s interpretation and understanding of the bid specification. The contract is then written on the basis of the customer’s understanding of the tender in relation to the enquiry so, at this point, it is the customer’s interpretation that is in place. When the supplier reviews the contract it is important to positively confirm what is to be supplied; a positive acceptance defining the scope of supply as understood by the supplier can sometimes be crucial.
[A case study: A client of mine once received what was, for them, a large order for one of their products. However, the order specification was ambiguous so the supplier acknowledged the order by stating their understanding of the requirement. After the products had been supplied and installed (on an offshore oil & gas installation) the customer discovered they were not right, not as they had specified in their order. The supplier was now liable to replace them at no cost, something that could well bankrupt the company. The Managing Director called for a review of the contract paperwork and, tucked inside the file, was a copy of the acknowledgement clarifying what they were agreeing to supply – which was what they had supplied. After pointing this out to the customer, they received a contract for the replacements at the customer’s cost. A happy (and very relieved) supplier and a customer buyer learning the lesson to read order confirmations.]
Picture an hospital operating theatre scene in many films or TV shows: “scalpel” says the surgeon, “scalpel” says the nurse as she hands it over. Repeating an instruction back is a very effective way to provide assurance that the correct information was received.