Building a business glossary

Do you speak the same language as the rest of your team?

A shared, common language is essential for open teams of all sizes. It's time to codify your vocabulary.

An open book
Image by : 
Opensource.com
x

Subscribe now

Get the highlights in your inbox every week.

A common, shared vocabulary is at the the heart of data quality and data management initiatives, not to mention effective team communication. On top of that, however, an explicit and common language also critical for maintaining a community-centered organizational culture. According to the Open Organization Definition, in the most successful open organizations, "people have a common language and work together to ensure that ideas do not get 'lost in translation,' and they are comfortable sharing their knowledge and stories to further the group's work."

Recently, our team needed to codify the vocabulary that forms the foundation of both our business practices and our operating culture. So we agreed to create a business glossary—one of the most challenging documents an organization can develop.

Here's how we did it the open way.

Know the lingo

A "business glossary"—sometimes referred to as a "data glossary"—is a document that clearly articulates and contextualizes common and important business terms and links readers to additional information assets (e.g., reports). Most commonly, a business glossary presents a list of terms, what those terms mean in a particular business context, and which systems and processes actually use or rely on the term. People often confuse a "data glossary" with a "data dictionary," which also defines data elements, their meanings, and their allowable values. Data dictionaries, however, are a bit more technical in nature. They formally document data (and metadata)—the structure and a description of tables and columns, relations, and constraints. Data dictionaries are  designed for developers, product owners, and reporting teams; a data glossary is designed for the entire business.

When tasked with creating a business glossary, our team intentionally chose to follow the Open Decision Framework.

The Open Decision Framework recommends that a project's problem statement is transparent. Multiple teams and stakeholders had requested a business glossary, so we knew the problem was obvious to many parties: We lacked clear and standard definitions of commonly used business terms.

So we chose to present the problem to our Data Governance Councils, the teams responsible for maintaining data integrity, security, and quality. Council members are from all areas of the business and all geographical regions. They represent a broad picture of all organizational data (customer, partner, product, and transaction) and its usage.

The principal idea was to foster meritocracy in determining the final definition for each term. When the group stalled and was unable to reach a final decision, the decision maker stepped in to help guide them to a workable solution.

Members volunteered to join a work group specifically to focus on a predetermined list of terms. Decisions makers leading the project moderated the groups, monitoring meetings, documenting terms and definitions, but allowing conversation to flow freely.

The principal idea was to foster meritocracy in determining the final definition for each term. When the group stalled and was unable to reach a final decision, the decision maker stepped in to help guide them to a workable solution.

After the work groups had completed their task and provided the terms and definitions to decision makers, a group of decision makers met to review the work. Together they developed clear, concise rules the definitions should follow (outlined in Figure 1). This provided guidance as they reviewed and edited the definitions.

Figure 1

Iterate

One of the primary principles of the Open Decision Framework is to release often, so decision makers chose to pause when they reached 75 terms and definitions, which represented a first release. They then sent a list of those terms to the data owner for review and approval. As expected, the data owner requested changes and posed challenges. So the decision makers met multiple subsequent times to resolve conflicts, edit the terms again (and again), then (finally) present a list of terms for publishing.

Finally, decision makers shared the list of terms (now close to 100 in all) back to the work groups for approval, then to the larger council. Once all groups had signed off on the contents of the glossary, the team created a centralized location for the glossary, published it, and announced it to the organization at large. The plan is to release more terms each month until the glossary is complete.

But that's not all! The team has also provided an opportunity for open feedback from anyone who uses the glossary. They expect changes and challenges, but, having used the Open Decision Framework to develop the glossary, they're confident they can meet the challenges in a collaborative and transparent way.

Using the Open Decision Framework helped the stakeholders to see that:

  • Project decisions align with the team's overall strategy.
  • There was visibility into the research, review, and evaluation processes.
  • The decision making process was inclusive, involving multiple parties.
  • The decision makers agree with the strategy and culture of the organization.
  • All voices were heard and valued.

Creating a business glossary is challenging—but using this open process led to great success for our team.

Subscribe to our weekly newsletter to learn more about open organizations.

About the author

Tracy Buckner - Tracy is the Project Manager for Communities of Practice at Red Hat. She is passionate about bringing business and technology together in creative ways to encourage full-circle feedback, transparency, and open communication. In her spare time, she is a writer and amateur photographer.