Project Glossary: The Right Way to Create One

During the course of most projects, at some point, someone starts creating a project glossary of terms.  Typically, most of us are well into the first or second requirement document before we realize that people don’t understand some of the terms or acronyms being used.  When that happens, the Business Analyst or Project Manager starts the glossary so everybody can understand these specials terms and acronyms.

I have come to believe that a project glossary really should be created right at the beginning of the project. In other words, on day one when you start working with the business, collecting initial high level requirements and defining the business case.

The project glossary is critical. And even though everybody uses it just to explain acronyms, I think it should do something a little different.  How about a project glossary that is used to actually explain the intention of a word, not just to define it?

What is CRM really used for?

Let me give you an example. “CRM” is a term that many people in the industry are familiar with.  Although CRM stands for Customer Relationship Management, many organizations do not use their CRM system to track existing customers. They’re using it to actually track prospects or non-customers. So if  “CRM” wasn’t as ubiquitous and somebody brand-new (who never heard the term) came in, they might say, “Well, why are we in the CRM system to track prospects? Why wouldn’t we use the CRM system just to track customers? Isn’t that what the C in CRM stands for?”

Ideally, our glossary would have an entry for CRM that explains CRM stands for “Customer Relationship Management”. However, it would also go beyond defining the acronym and actually explain that on this project, or in this organization, we use CRM as a business development tool for prospects as well as to track dialogues with existing customers.

Then there are some companies that use the word “customer” to represent certain customers and use the word “client” to represent special VIP customers. This should also be explained in the glossary so that everyone understands the difference between the customer and client and the perception around those two segments.

But Wait, There’s More

Another tip about project glossaries: Don’t just define or explain how you’re using a term or an acronym. Also explain what the term doesn’t include. For example, if “word processing tools” were in my glossary, I’d say, “This term describes the spell check, formatting and print tools but does not include the process of sharing documents via e-mail.”  This way there’s less confusion.  You can read my previous post on ambiguity here.  It’s an interesting story on how ambiguity can create grave problems in any project if you’re not careful.

To summarize, the glossary is critical to good project communications and should be used for more than just explaining acronyms. Other things to keep in mind:

• Create your project glossary at the very beginning of a project.
• Use your project glossary to explain ideas, including how the term is specifically used within the organization.
• Include the scope of the term, specifically what the term does not include.

Do you use glossaries from day one? Do you have any best practices with your glossaries?

Category: Defining Success, For Practitioners