What are you talking about?
You’re in a meeting and one of your colleagues brings an important announcement to the team: “This weekend, the IT team will update the CPU & OS on our VRU server. This has potential to impact the SLA of our CCU and increase our CAR. We need to identify an SME to work with their POC to determine the actual CPU by COB.”
HUH?!
I think we have all been there. In our acronym and emoji society, it seems no one has the time to speak in complete sentences or use whole words. This is nothing new – acronyms date back to the Roman Empire – and we still use some of them today to denote time of day (i.e. AM – ante meridiem, and PM – post meridiem). As time has progressed, so has our need to communicate faster, so we continue to take this to new levels. As such, today, it can be very hard to ensure that everyone understands and connects with the message we are sending out.
That said, I want to take just a moment and deviate from our normal conversations about Process, Risk Management, and Architecture, to focus on something that is so fundamentally basic, that it is often overlooked. A Glossary.
Many of you may think that a glossary is something only used for papers and reference books. This could not be further from the truth. It goes without saying, (but yes I am going to say it anyway), that it is very hard to work with people when the lines and language of communication are not clearly defined. This is even documented in ancient writings about the Tower of Babel. The languages were confused, people could not understand each other, and the project was abandoned. The same thing can happen in our own projects and processes when a clearly defined Glossary is not established. This seemingly simple item can revolutionize your daily work life and spare you countless redundancies and/or inconsistencies in how processes, procedures, architecture objects, and of course, documentation are captured.
In many planning sessions that I’ve had with customers, this is one of the first discussions. We want to make certain that we are speaking the same language to ensure that the appropriate and expected deliverables are… well, delivered. So we start with identifying and capturing common terms and acronyms for that particular business. Once this is in place, we can create our Glossary. That same list of terms can now be linked to our processes, architecture objects, and documentation, to ensure that all parties involved know what is being said. This is especially important if a word or term may have more than one meaning.
With that in mind, give that colleague’s important announcement another look – but this time with the benefit of a glossary.
“This weekend, the IT team will update the CPU & OS on our VRU server. This has a potential to impact the SLA of our CCU and increase our CAR. We need to identify an SME to work with their POC to determine the actual CPU by COB.”
Glossary
CAR – Call Abandon Rate
CPU – (1) Central Processing Unit (2) Cost Per Unit
Did you notice the use of the term “CPU” in our colleague’s announcement was used twice? Without clarification, we may assign the wrong resource to assist with this situation, OR make decisions based on an incorrect application of the term.
The impact of not having a clearly defined glossary can be felt in both process/project time and cost. We might also consider the impact to moral. Many times rework can be prevented, and given the impact that rework can have on profits, it is good to understand how something as basic as a Glossary can help with more effective communication and collaboration, thereby reducing errors and cost in our processes.