Does Networking Hurt Your Hands? The Power of a Glossary
A few weeks ago I was working away from home, and I was able to attend an IIBA UK event in the evening.
It was a really enjoyable event, and after meeting a whole bunch of new people and chatting about all things BA related, I went and checked in to my hotel. As I was checking in, the receptionist asked me how my day had gone. I explained that it had been busy, and I’d spent a few hours networking late into the evening. As much as I enjoy networking (I love meeting new people and sharing/learning), I do find it exhausting. As he handed me my key, the receptionist said something that really surprised me:
“Ah, I used to do a lot of networking. Kills the hands, doesn’t it? All that terminating. I used to work for a communication company so I did a lot of networking”.
Perhaps it was because I was tired, but I did the typically British thing and just smiled and accepted the statement that he’d made without questioning it–but on my way to my room I was puzzling over what he’d said. Why would networking hurt his hands? Too many handshakes maybe? And why would you terminate something at a networking event… that sounds pretty serious! And why is the fact he worked for a communication company important…
Then the penny dropped. Networking has different meanings, and I suspect he was referring to laying physical networking cables in a data center or communication room, where cables have to be crimped and (presumably) ‘terminated’. Perhaps using some of the tools is uncomfortable after a while. “An evening networking” to me means meeting other BAs and having a coffee. To him it meant navigating cables in a comms room ‘out of hours’ getting everything ready before people arrive the next day.
The Illusion of Communication
As William H. Wyte once wrote “The great enemy of communication, we find, is the illusion of it.”. This is often the case inside organizations and between organizations too. With our plethora of acronyms and words with ‘special meanings’, it is easy to appear that we are agreeing on a particular issue, idea or requirement, only to find out that each person at the table has a subtly different understanding of what is being discussed.
Even words that appear, on the surface, to be obvious can have different meanings depending on who you ask. The word ‘customer’ might seem clear and obvious, but it is quite possible that different people attribute different meanings to it. Who is the ‘customer’ of a training course? The delegate who attends it? The company that employs the delegate (assuming they are paying)? Probably both–although both will have subtly different needs and requirements, only some of which overlap. This is made even more complicated in intermediated industries where there might be an end customer, and one (or many) intermediaries. If a financial service company sells products via brokers, some might refer to the broker as a ‘customer’, others might refer to the end investor as the ‘customer’. Again, they’ll have very different needs and requirements.
This can lead to all sorts of crossed-communication throughout the business change lifecycle, not least when it comes to requirements. Whether we’re writing user stories, use cases or even a heavy-weight requirements catalogue, it pays to think about terminology. This is where the good, old, trustworthy glossary comes in.
A glossary perhaps isn’t the first thing that springs to our minds as business analysts. It’s something we know we probably should do, but with the pressures of a project it can be easy to let it slide. This simple experience, with a misunderstanding over the word ‘networking’, reminded me how important they are. After all, with a clear glossary, writing just about any type of requirement artifact becomes easier. If there is a clear and agreed meaning of “Investor” and “Broker”, for example (rather than using a term like “Customer” that might mean either, or both) we can be concise and precise in our requirements writing.
This potential for misunderstanding also highlights the need for techniques that don’t rely on the written word. Visual techniques, including formal modeling, can help explore the problem space and requirement scope too. All of these activities help us cultivate conversations and help us ask “what exactly do you mean by ‘x’?”. Not only this, but a well-defined glossary can help inform the production of other artefacts such as a concept model (these are clearly different things, but defining terms up front helps a great deal).
A glossary might take some time to create and maintain, but it’ll help avoid ambiguity and ensure we can create concise and precise requirements. It is an investment in time worth making.