Better team communication with glossaries: Overcoming the 5 biggest obstacles

Glossaries are a simple but effective tool for improving communication in teams. However, there are a few things to consider when introducing and using them. If the following five obstacles are not actively considered, a half-finished glossary will quickly end up in a drawer and gather dust.

One or two readers will know that I have been working on this topic for a while now and that I also have the tool Semiant with which the obstacles described here can be overcome.

What is a glossary and why is it useful?

A glossary is used to ensure consistent terminology within a team or organization. Especially in the context of systems engineering, where interdisciplinary teams with different technical languages often work together, a glossary helps to avoid misunderstandings. It specifies precise definitions for terms that are either subject-specific, ambiguous or project-specific.

A glossary helps to improve the quality of documentation, processes and products. In large projects, a well-maintained glossary can also help to familiarize new team members more quickly as it enables them to familiarize themselves with the terminology used. A glossary also prevents misunderstandings for interested parties outside a team. This enables employees in sales, marketing or support to communicate better with customers and sharpen their own understanding.

In practice, however, it is not so easy to create a glossary and then ensure that it is used and maintained. We will now look at how we can overcome this and other obstacles.

Obstacle 1: A single glossary for all is not possible

I have seen companies launch the "company-wide glossary" initiative more than once - and fail. There are several reasons for this:

1. Different departments and teams have their own languagesEach department within a company uses specific terms and definitions that are deeply rooted in their respective specialist cultures. A term can have different meanings in different contexts, which makes a uniform definition almost impossible.
2. Conflicts in the prioritization of termsIn a company-wide glossary, it is often difficult to decide which terms should be included and which should not. Priorities can vary from department to department, which can lead to discussions and delays.
3. Resistance to standardized termsEmployees and teams who are already familiar with their own terminology may refuse to replace their familiar terms with standardized definitions. This not only leads to acceptance problems, but also makes the implementation of a standardized glossary more difficult.
4. Dynamics of the definition of termsTerms and their meanings evolve over time, especially in innovative or technology-driven industries. A company-wide glossary would need to be updated regularly to remain relevant, which often leads to a huge administrative burden.
5. Different requirements for the depth of the definition of termsWhile some departments may require detailed technical definitions, others may only need a simple, generally understandable explanation. A single glossary often cannot fulfill these different requirements at the same time.

Instead of developing glossaries top-down, they should be developed bottom-up

For this reason, the development of glossaries should be started at team or project level. For one thing, there are usually fewer terms here, which speeds up the development of a useful glossary. Furthermore, it is easier to reach a consensus.

Obstacle 2: Creating the first (useful) glossary

Let's get this out of the way: A few years ago, this first step, the creation of an initial glossary, was an expensive affair that required quite a bit of manual labor. Even if a student trainee took on this task, expert hours were required for the reviews. This is where AI is a blessing and even generic AIs such as ChatGPT can create a machine-readable glossary for an uploaded document in minutes. However, a review with experts is also important here.

Obstacle 3: Accessibility and ease of use

The first glossary is ready! And now? How can employees use it? The options are:

• Document software such as Excel or Confluence - An Excel on the Sharepoint or a confluence document are the low-budget solution for a shared glossary. Unfortunately, employees often forget after a few days that a glossary even exists. The result: the glossary collects dust in the digital drawer.
• Special software for glossary management - However, there is also web-based software for managing glossaries. In addition to the solution I co-developed Semiant tools such as TermStar or TermWeb. Semiant differentiates itself by the fact that it can be integrated into almost any web application via a web browser extension and can be activated there with a single click.
• Built-in glossary management - A little known fact is that many tools in product development already have glossary management, such as DOORS Next or Sparx Enterprise Architect. This is a user-friendly option, but it is limited to the relevant application.

Obstacle 4: Keeping glossaries up to date

Glossaries are dynamic resources that need to evolve. However, updating them and communicating changes effectively can be a logistical challenge, especially in large or decentralized teams. Here it is important that users can provide feedback and suggest improvements with just a few clicks. Possible options are:

• Give users editing rights - In the simplest case, as with Excel or Confluence, employees can edit the glossary directly. However, this can lead to misunderstandings and resentment in larger teams.
• Special software with workflows - Specialized software usually offers the option of incorporating improvements into the database via corresponding workflows and regularly publishing new versions of the glossary.
• External workflow - The improvement workflow can also be managed using a separate tool. For a Confluence glossary, for example, it makes sense to use Jira tickets.

It is important here to avoid frustration among employees and minimize frictional losses.

Obstacle 5: Involving external stakeholders

As I wrote at the beginning, I recommend a bottom-up approach to glossary management. Once the team has established glossary management at project level, the next logical step is departmental or even company level. It is important to note that we cannot simply extend the team glossary for use at the organizational level: Instead, there should now be multiple glossaries, for the different levels. As part of the introduction of the department glossary, for example, some terms would "move" from the team glossary to this one, but others would exist in both glossaries if they have different meanings there.

An example of a glossary term used in the Project team and in the Department team could have different meanings is "Release".

• In the project teamRelease often refers to a specific version of a product, system or software that is released after a certain development cycle. It is closely linked to a fixed schedule and the requirements defined in the project.
• In the department team (e.g. marketing or sales)Release" can rather refer to the time and manner in which a product or campaign is launched on the market. The focus here is on communication, branding and the go-to-market plan.

At this stage at the latest, the infrastructure must enable the confident handling of multiple glossaries, which is actually only possible with special software such as Semiant. Semiant also makes it possible to go one step further and include external stakeholders, such as suppliers or customers.

Conclusion

A well-maintained glossary optimizes collaboration within the team and reduces misunderstandings. However, implementation is by no means trivial: from creation and maintenance to integration into work processes, there are numerous challenges that need to be considered. A glossary that is actively used and continuously developed increases efficiency, improves the quality of communication and creates a basis for sustainable success - both within teams and beyond.

Image by madsmith33 from Pixabay