When I was a senior in high school, my English teacher made us read “Politics and the English Language,” an essay by George Orwell. The essay points out that much contemporary writing is, in general, imprecise and ugly. One of the main reasons for this, he says, is that many people take for granted that “language is a natural growth and not an instrument which we shape for our own purposes.”

While the ideas of a dead political theorist and author may not seem particularly relevant to our work as business analysts, this particular insight is important to remember. We can, and should, make a conscious effort to shape the language we use on a project for the purposes of clarity and efficiency.

One of the best ways to do this is to create and maintain a Project Glossary and, importantly, share it with all members of the project. In a previous blog post, we discussed how the state of the Project Glossary can provide a glimpse into the health of the entire project. If a team hasn’t put in the effort of defining important project terminology, it usually means the team has been sloppy in other areas as well.

Expanding on that idea, it’s important to keep in mind that a glossary can be more than just a reference guide which only appears when we find a technical term or acronym we haven’t seen before. By making the creation of the Project Glossary a collaborative and ongoing process, it can spark conversations about terms that will be used over and over as the project moves forward. Hopefully these conversations will lead to a more accurate and nuanced understanding of important project terms and, ultimately, more efficient project communication.

Of course, the importance of a robust and well-maintained Project Glossary depends on how familiar the members of the project are with one another, with the organization, and with the project. For consultants and others who may not be deeply familiar with an organization, the importance of a glossary is clear. However, since much of the value of a glossary comes from the conversations that happen during its creation, maintaining a glossary is important even when team members are familiar with one another and with the organization. You may discover, as our team did when we started to create a glossary for a recent project, that there are big differences in what people who use the same words are trying to say.

So next time you start on a project, remember that project terms are tools that you can create and modify to suit your team’s needs, not relics passed down to your team from the distant past. And tools are no good if you don’t know how to find them, so don’t forget the Project Glossary either!