How Can Project Glossary Documentation Be Better?

Every time I see a glossary of terms associated with project documentation, I have the same two reactions. The first reaction is a simple word balloon in my mind stating "Nice!". The second reaction is "how effective is this glossary when it exists in this single document?".

This is from the Seattle Seahawk 12K this last April. A very fun race that had over 7,000 fans hooting "Go Hawks" from time to time!

Project glossaries are very similar to the glossary found at the end of a book. It contains key terms and their associated meanings to the context of the document / project. It is a powerful but often overlooked component of project documentation. In cases where a reader is confused by what is being discussed or is struggling to find context from a narrative, a glossary can help. 

If your project is highly cross functional and/or has a localization element to the team, a glossary review of the domain might be one of the first tasks to accomplish on the to do list. In many cases, these diverse groups don't recognize key terms or they have completely different impressions what a key term really means. This glossary review session can be very helpful in nipping that confusion in the bud, before it can have a negative effect on project progress.

Effective communication benefit all stakeholders and those benefits are often indirect, largely unnoticed but often critical to long term success. A well defined and communicated glossary is a proactive planning step and it should be something you consider integrating into your project documentation efforts.

I have one recommendation for how glossary information can be more effective on an enterprise wide implementation. Put the information in a database and have it be available to everyone in the organization. This allows the greatest chance of a shared understanding of key terms organization wide. To make this approach as effective as possible, I have the following suggestions:

  • allow the data to be searched, organized and exported
  • avoid ambiguity that can be associated with words such as approximately, quickly and ease of use
  • when a document contains glossary info, have it refer the user to the larger networked version for additional illumination
  • evangelize the network glossary and include it in employee orientation training
  • have a traceability feature in the glossary database that can refer users to the project documentation in which that term appears
  • although the content should be created and edited collaboratively, it should be managed by a single workgroup such as a PMO
  • when new project documentation is submitted, have it reviewed for possible updates to the master glossary
  • when the glossary is updated, have some low impact communication method in place to inform those who would most benefit from that notice (analysts, project managers, product owners, etc...)

© 2016 Dwayne Wright