Glossary

What is it?

Knowing what a glossary is, is simple.  A glossary is “an alphabetical list of terms or words found in or relating to a specific subject, text, or dialect, with explanations”.[1]  Or if you want to know what a glossary is as it relates to Business Analysis we can use the IIBA’s definition:  “A glossary documents terms unique to the domain.  It is created in order to ensure that all stakeholders understood what is meant when certain words are used.  A glossary consists of a term relevant to the domain and a unique definition for each, as well as cross-referencing aliases.”[2]

Or to break it down into component parts, a glossary is:

  • A list of words that relate to a specific domain or subject (your project or analysis space)
  • A definition for each of those words
  • [Optionally] Synonyms for each word

The key thing that separates a glossary from a dictionary is that the terms in a glossary are related to a specific domain of knowledge or area of analysis.

 

Why do it?

While most of us know what a glossary is, why and how to use one in Business Analysis work is often much less understood.  For most of my career, a project glossary was only something I used when I needed to document new acronyms or the name of some system I wasn’t familiar with.  And I’m sure I wasn’t alone.  But a Glossary is can be a critical part of an analysis effort that is more useful than you think.  The key reasons for creating a glossary include:

Knowledge Discovery and Learning

A glossary can be a key resource to your knowledge discovery and learning efforts when you begin work on a new project.  This is especially true when you are working in what the IIBA calls the “Enterprise Analysis” stage, or Concept stage of a project.  You as the business analyst need to learn how terms are used for this new domain of activity if you are to build the mental framework needed to elicit and analyze relevant information.  This process of creating a glossary is essential to learning the business.

So as you start reviewing existing business documents, process maps, and project documents; start identifying what look like important terms and create your personal glossary for the project.  If there is an existing glossary, copy it into your personal and note where you found the definitions.  If there is no definition specified, or if the definition provides does not seem to match the way the term is used in context, add a definition that seems to support the way the term is used.  If you are still not sure, try searching for the terms on the web and see if any definitions there turn up relevant.

When you speak to individual stakeholders, it’s a good idea to create a mini-glossary of the terms they use and how they use them.  This enables you to compare different usages among stakeholders and locate potential areas of misunderstanding between all of the parties involved in the project.  These can then be combined into your personal glossary so that when referring a term you can see how it’s used by all of your stakeholders in one location.

This personal glossary will show you the many potential definitions of a term in the context of your analysis effort, and can then be used as the foundation for creating a single project or effort glossary that deliberately encompasses or rejects certain definitions rather than being completely unaware of alternative possibilities.

Improved Communication

Most projects seem to treat the glossary as something that is only used to provide a simple definition for terms that are not thought to be common knowledge.  But as I worked on more projects with global teams, and with more contract project and development staff, and across multiple business units; I soon came to the realization that a glossary enables you to define the common language of your project effort.  And when you define a common language, you not only enable better learning on the part of the project team, you enable better communication across all of the parties involved.  Not just project to business, or business to project to technology, but business to business.

One challenge to this is that the exact terminology used by different stakeholders can vary from unit to unit, location to location, and even within the same team at the same location.  Language is personal.  So when creating a glossary one consideration is to try and define definitions for terms within the project space that are as close to what the majority of your stakeholders already use as possible.

Glossaries shouldn’t just have acronym’s or the occasional unfamiliar term.  You should start creating your glossary as soon as you start work on any business analysis effort.  Even if you haven’t spoken to a single stakeholder yet, start documenting what YOU think various terms and concepts mean as they come up.  Then as you start engaging with various stakeholders you can ask what the term means to them, and share your interpretation, especially if it varies from theirs.  Then talk about what the term or concept doesn’t mean, or what is excluded.  Especially where one term is broader or narrower than a related term.  The idea with this is implant the concept to your stakeholders as early as possible that THERE CAN BE NO ASSUMED SHARED UNDERSTANDING of terminology.  I have seen so many project issues arise due to assumed shared understanding of terminology, that I have lost count. And the best way to reduce those risks is by building a shared language for the project effort, which is documented in a Glossary.

As part of building this shared understanding, I often accompany a Glossary with a Concept Map, which shows how terms and concepts relate to each other, rather than their definitions.

A Foundation for Elicitation

The terms and concepts you define during the creation of a glossary will likely be useful when eliciting and defining business rules, data models, concept maps, object models, state diagrams, use cases, and other artifacts of the elicitation and analysis processes.

What a Glossary is Not

A project glossary should NOT be used as an attempt to force business units to adopt a single set of definitions in how they use terms outside of a project.  Changing the language a business uses is a change management activity and could require a project-level effort of its own.  I’ve had several project managers say something to the effect of “these terms have been standardized in such and such a place, why don’t we use those definitions?”  Remember that the goal is to foster communication and understanding among project stakeholders, and the best way to do that is to try to adhere as closely as possible to the definitions of terms that are already used by those stakeholders.

How do I do it?

Step 1 – Decide Location

Decide where the glossary will be stored, and what format it will take. I think it’s a good idea to have a copy of the glossary in your requirements documents, but I have also seen them kept as separate documents, as SharePoint lists, in a corporate Wiki, or other locations.

Step 2 – Decide Form and Create Template

Create the template for your glossary, including deciding if the Glossary will contain a separate column of synonyms or if they will be listed as their own term. I like to list synonyms as separate glossary entries with a definition of something like “X is a synonym of Y, most commonly used in circumstance A or by team C”, but you should work with your stakeholders to decide what makes the most sense for your effort.

Step 3 – Identify Terms

As terms come up that seem important or relevant in your enterprise analysis work (if any), especially through activities related to current state analysis (such as document analysis); add them to the glossary, even if you don’t define a definition at that time.

Make sure to check resources such as:

  • Project Vision Statement
  • Project Charter
  • Business Case
  • Existing organizational and system documentation
  • Existing process maps

Step 4 – Craft Definitions

As glossary terms are identified, craft definitions for them. There are a few links in the Resources section below on how to create definitions, but I recommend the “genus-differentia” [3]approach where feasible.

The Genus-Differentia Approach to Definitions

A genus-differentia definition is composed of two parts: [3]

  1. A genus: An existing definition that serves as a portion of the new definition; all definitions with the same genus are considered members of that genus.
  2. The differentia: The portion of the definition that is not provided by the genus.

So the genus-differentia approach to defining terms is the idea of taking a more abstract or higher level concept, defining it, and then using that existing definition to define other terms that are more specific variants of that term. This is similar to the process that business analyst use for requirements, you start with more abstract requirements and further refine them until they are more detailed.

As an example, look at the following definitions. Notice how by defining just three terms (Line, Shape and Angle) that all of the rest of the terms can be defined in reference to those two terms. After those three definitions the genus of each definition is underlined and the differentia is italicized so that you can easily see how the genus-differentia approach works.

  • Line: A straight or curved continuous extent of length, with or without a beginning and end.
  • Shape: The form of an object – how it is laid out in space
  • Angle: The space (usually measured in degrees) between two intersecting lines or surfaces at or close to the point where they meet.
  • Right Angle: An angle of 90°.
  • Figure: A shape defined by one or more lines in two dimensions.
  • Triangle: A figure with three straight sides and three angles.
  • Quadrilateral: A figure with four-sides.
  • Rhomboid: A quadrilateral of which only the opposite sides and angles are equal.
  • Trapezoid: A quadrilateral with only one pair of parallel sides.
  • Rectangle: A quadrilateral with four straight sides and four right angles.
  • Square: A rectangle with four equal sides.

The “Rules” for Well-Crafted Definitions

Wikipedia provides the following traditional rules for crafting definitions:[4]

  1. A definition must set out the essential attributes of the thing defined.
  2. Definitions should avoid circularity. A definition of a term must not consist of terms which are synonymous with it.
  3. The definition must not be too wide or too narrow. It must be applicable to everything to which the defined term applies (i.e. not miss anything out), and to nothing else (i.e. not include any things to which the defined term would not truly apply).
  4. The definition must not be obscure. The purpose of a definition is to explain the meaning of a term which may be obscure or difficult, by the use of terms that are commonly understood and whose meaning is clear.
  5. A definition should not be negative where it can be positive. We should not define “wisdom” as the absence of folly, or a healthy thing as whatever is not sick. Sometimes this is unavoidable, however.

And I would add the following suggestions as well:

  1. Make sure that you engage with stakeholders on glossary terms that need definitions, to review proposed definitions, and to review existing definitions to ensure they are still accurate for the intended purpose and capture the language stakeholders use wherever possible.
  2. Where appropriate, make sure you document what a term DOES NOT mean as well. This is especially true when the project usage of a term differs from common language or when the definition used by certain stakeholders needs to be rejected for use by the project.
  3. If possible, try to include the source of any definitions you use in the glossary. This way if there are questions about the definition, you can follow-up with the source, or at least identify the source you used.

 

Step 5 – Update and Revise

The glossary will likely continue to evolve with new terms and new / change definitions as the analysis effort continues.  So it may never be “complete”.  However, the glossary should be “finalized” and sign-off on at the same time requirements are.  And since the glossary is the key reference for the understanding of the requirements and project effort, it should be placed under the same change control process as requirements once they are sign-off on.

 

What Should the Results be?

Your goal for the glossary and definitions should be that an outside party who knows nothing of the business or industry could use them to understand your documentation.

The glossary below is one I am currently (as of the time of writing) working on as part of the concept phase of an effort to improve my employer’s Institutional Client Reporting capabilities. It’s still early on and I have left out some terms in an effort to reduce the size a bit and eliminate any potentially sensitive information, so give me a bit of leeway.  But I wanted to use an actual example of a working glossary from an industry that some may not be familiar with.

 

Term Description
3c7 The section of the Investment Company Act of 1940 under which PRIVATE FUNDs operate. Sometimes used as a synonym for PRIVATE FUNDs.
3c11 The section of the Investment Company Act of 1940 under which COMMINGLED TRUSTs operate. Sometimes used as a synonym for COMMINGLED TRUSTs.
Account An account is created to hold the assets owned by a client as a result of their investment in a PRODUCT through an INVESTMENT VEHICLE.
Ad-Hoc Report A type of REPORT with content that is generated on request, rather than on a regular schedule. The content of the report is usually different than that of a SCHEDULED REPORT (often more info than a scheduled report).
Attribution A performance-evaluation tool used to analyze the abilities of portfolio or fund managers. Attribution analysis uncovers the impact of the manager’s investment decisions with regard to overall investment policy, asset allocation, security selection and activity. A fund or portfolio’s returns are compared to a benchmark in order to determine whether a manager is actually skilled or just lucky.Attribution DATA is one of the most frequent types of CONTENT provided to CLIENTs in REPORTs.
Batch Report A REPORT that is generated with other similar reports at the same time. Generally for different clients, but the content is the same. All Batch Reports must be FULLY AUTOMATED.
Benchmark A standard against which the performance of a security, mutual fund or investment manager can be measured. Generally, broad market and market-segment stock and bond indexes are used for this purpose.
Caveat A disclaimer or similar text that provides important Legal or Compliance information about a particular piece of CONTENT.
Chart A visual representation of DATA. Charts are a type of CONTENT.
Chunk A “Chunk” is a pre-defined group of DATA elements, CONTENT, and design elements that are packaged together for easy inclusion in a report without having to rebuild them from scratch.An example might be a performance “chunk” that bundled together a table with specific performance time periods for a portfolio and benchmark, a specific chart design of that data (say a bar chart), and some static text in the form of labels and standard disclaimers. The user would select the “chunk” and insert it into a report where the data elements would be mapped to the appropriate portfolio and benchmarks for defining what actual data values are used to populate the placeholders in the “chunk”
Client The investor to whom investment management services are being provided.Client reporting needs are defined by their Investment Management Agreement or by the type of the INVESTMENT VEHICLE through which they have invested.
Commentary A set of text that provides additional context to investment performance and/or investment outlook.Commentary is always point-in-time specific, and usually product / account specific. General economic outlook is an example of point-in-time specific commentary that is not specific to a particular product or account.
Commentary is a type of CONTENT.
Commingled Trust Commingled Trusts are offered under section 3c11 of the Investment Company Act of 1940. They are a class of INVESTMENT VEHICLE that are made up of a pool of assets that are jointly managed by the same entity under a common investment management strategy. Commingling the funds allows for greater efficiency and lower costs for the investors, while still allowing for daily trades.
They MUST be administered by a bank and can only be provided to eligible employee benefit plans (ERISA clients), which are a type of INSTITUTIONAL CLIENT.  Commingled Trust accounts are maintained on the accounting system of the administering bank.
Consultant An outside party that provides investment planning, allocation, selection, and monitoring services to an INSTITUTIONAL CLIENT or potential institutional client.
Content Content is the total information set that is used to populate a REPORT. Individual pieces of content are usually time, product, and/or context-specific (i.e. they are only true or relevant in regards to a specific time-period, product, or context).
Content types include COMMENTARY, CHARTS, DATA, and DIGITAL ASSETS.
Data Data is alpha-numeric information that is derived from some entity or value set (such as a set of portfolio holdings, a group of investors, a company, etc.). Data is typically, but not always, generated on a regular schedule (such as every month-end, every quarter-end, etc.).
Data is a type of CONTENT.
Digital Asset A separately maintained, standardized, piece of content with its own template (almost always as 1 or more slides in PowerPoint format) that can be included in a report on an optional basis. Created for standardized, rarely updated, pieces of content that are widely used in many reports.
Digital Assets are a type of CONTENT.
Fully Automated Report A category of current REPORTs which denotes those reports for which all CONTENT is available in the current reporting solution and for which no manual intervention by the reporting teams is required.
Holding An asset owned by a CLIENT in their ACCOUNT. Accounts can have more than one type of holding and multiple specific holdings of the same type.Accounts in mutual funds, COMMINGLED TRUSTs, and PRIVATE FUNDs typically hold only shares of the pooled investments. SEPARATE ACCOUNTS can hold shares of pooled investments and stocks, bonds, cash, and all other individual investment asset types which the investment manager makes use of.
Institutional Client Institutional clients are typically those who manage large pools of money on behalf of others. Typical institutional investors include pension funds, insurance companies, investment companies, savings institutions and foundations. They are considered sophisticated investors and are eligible to invest in products that cannot be sold or marketed to the general public. High Net Worth (HNW) individuals are frequently considered institutional investors as well.
Institutional Vehicle Institutional investment vehicles are those which are exclusively or primarily provided to institutional investors. They typically have lower management fees than RETAIL VEHICLEs but have very large minimum investment amounts. Examples can include separate accounts, institutional mutual funds, institutional share classes of retail funds, private funds, and commingled trusts.
Investment Vehicle The term “investment vehicle” refers to any method by which individuals or businesses can invest and, ideally, grow their money. There is a wide variety of investment vehicles and many investors choose to hold at least several types in their portfolios.
Investment vehicles can range from certificates of deposit through to hedge funds and similar highly complex vehicles. Different investment vehicle types usually have different requirements and restrictions for client reporting under which they operate.
Manual Report A category of current REPORTs which is created via an entirely manual process. The report may use a “standard”-style template, but the data needed is not available in the current reporting solution.
Partially-Automated Report A category of current REPORTs which is created partially in ACR, and then additional changes are made manually before the report can be provided to the client.
Private Fund Private Funds are offered under section 3c7 of the Investment Company Act of 1940. They can only be offered and sold to INSTITUTIONAL, qualified, or accredited investors. Clients may only trade into or out of private funds once a month, on the first business day, and a maximum of 25% of the 3c7 fund assets can come from US ERISA investors.
Private fund accounts are maintained on the accounting system of the investment manager.
Product A product is a specific investment strategy offering made by an investment manager. Each product may be offered through several different INVESTMENT VEHICLE’s so that investors can access the product through different price points and structures.
For example, the “Templeton Global Bond” product can be invested in through U.S. RETAIL FUND, SICAV, and SEPARATE ACCOUNT vehicles.
Report A set of content, usually presented in the structure and format specified by a TEMPLATE, provided to an appropriate party such as a CLIENT, CONSULTANT, or other recipient.
Reports are usually time, product, and/or context-specific (i.e. they are about a specific account or product, for a specific time-period, or in regards to a specific context).
Reporting Period A reporting period is the period of time which the information in a report is relevant to. Theoretically, a reporting period could cover any period of time. However, the most common reporting periods are weeks, months, quarters, semi-years (6 months), and years (1 year).
Retail Client Retail clients are typically public individuals, or non-institutional entities. They are considered unsophisticated investors the products and marketing offered to them is highly regulated.
Retail Vehicle A class of INVESTMENT VEHICLE that is approved for offering to the general public (RETAIL CLIENTs) for their investment needs, although INSTITUTIONAL CLIENTs may also invest in them. They typically have higher management fees and smaller initial investment requirements.
Examples include SICAV’s, US RETAIL FUNDs, ETF’s, Closed-End Funds, Canadian Mutual Funds, and local investment offerings outside the United States and Europe.
Scheduled Report A type of REPORT with fixed content that is generated on a specified recurring schedule.
Separate Account A separate account is a type of INVESTMENT VEHICLE that is privately managed to buy individual assets. They differ from a mutual fund because the investor directly owns the securities instead of owning a share in a pool of securities.
SICAV SICAV is the common abbreviation for “SOCIÉTÉ D’INVESTISSEMENT À CAPITAL VARIABLE”. SICAV’s are the rough equivalent of the U.S. Retail mutual fund in Europe and are a type of open-ended investment fund in which the amount of capital in the fund varies according to the number of investors. Shares in the fund are bought and sold based on the fund’s current net asset value.
Static Text Static Text is a type of CONTENT that is not updated via automated systems. It normally refers to section labels, headers, and similar text that rarely changes.
Template A template specifies the layout, structure, and general content of a REPORT. A template may also specify the file format that the REPORT is generated and / or delivered in.
Triggered Report A type of AD-HOC REPORT which is generated based upon the occurrence of a “trigger event” specified in the Investment Management Agreement with a client.  Examples of trigger events might be the departure of a portfolio manager, the bankruptcy filing of an equity issuer in the clients’ portfolio, or the default of a bond in the clients’ portfolio.
U.S. Retail Fund Sometimes also called a “40-Act Fund” after the Investment Company Act of 1940 under which they operate, U.S. Retail Funds are a class of mutual fund INVESTMENT VEHICLE’s which can be marketed and sold to the general public in the United States. They operate under different requirements and regulations than PRIVATE FUNDS and COMMINGLED TRUSTs.

 

Advantages

  • Glossaries, and especially the process of creating them and achieving consensus among stakeholders and what definitions the effort will use, are a tremendously useful tool in business analysis.

 

Disadvantages

  • The disadvantage of a glossary is that no matter how hard you try, if the definition that the project uses in the glossary does not match what is in a stakeholders head, at least 8 times out of 10 they will use the definition they already have when doing anything related to the project or analysis effort. This is a fact of the human condition and there is no perfect solution. 🙂

 

Tips

  • I like to add some form of text styling to other glossary terms that appear in the definition of a term. I usually use a combination of bold font and all caps text, to make terms that are further defined elsewhere in the glossary really stand out.
  • The IREB recommends that a glossary be placed under the responsibility of a single person, so that changes are only made by one person and all changes are reviewed before they are made. This prevents stakeholders with conflicting understanding from editing glossary definitions to fit their specific definition when the project effort may require a different definition. [3]

 

References

  1. Google Define: Glossary
  2. BABOK v2.0; Section 9.5.3.1
  3. Wikipedia Entry: Gunus-Differentia Definition. Various authors. Accessed on October 8, 2014.
  4. Wikipedia Entry: Definition. Various authors. Accessed on October 8, 2014.

Other Resources

 



© 2014 by David Olson

Leave a Reply

Your email address will not be published. Required fields are marked *