Learning the Stakeholders Language with Concept Maps and Glossaries

Published: 11 October 2014

Perhaps the single most important thing a business analyst can do when they start working on an initiative (whether it be a project, process, or problem analysis) is to learn the language of the stakeholder(s) they will be working with.

Learning the language of your stakeholder(s) should be among the very first tasks you undertake as a business analyst. Indeed, in my opinion, it is the very foundation of EVERY other activity a business analyst undertakes with that stakeholder.

It is difficult to understand the business problem(s) you are trying to solve if you do not understand the subtleties of the language the stakeholder is speaking. Even common terms used within the larger organization can have subtly different meanings to your stakeholder that are important for you to know.
When working with multiple stakeholders, you cannot communicate optimally with them if you do not do so in language that they understand at the most complete level.
When working with multiple stakeholders, you cannot identify potential differences in stakeholder needs if you do not understand the exact language each stakeholder is speaking,
You cannot most effectively plan to elicit information if you do not know the meanings and relationships of the concepts the stakeholders use.
And you cannot fully understand the information you elicit from stakeholders if you do not understand the full meaning of what they communicate.

How do I propose you learn the stakeholder’s language? By using glossaries and concept maps.

Glossaries are used for documenting the meaning of terms and concepts. Concept Maps are used for documenting the relationships between terms and concepts. Together, they help a business analyst learn a client's language at a deeper level than achieved by glossaries alone, or by simply speaking to stakeholders, which is how many business analysts seem to do it today.

Indeed, using these two techniques in combination has several potential usages. However, I am only going to discuss the first two in this post:

Learning the Clients Language
Establishing a Consistent Project Language
Eliciting Tacit Knowledge
Identifying Potential Requirements Dependencies

In my opinion, there are three shortfalls with the common business analysis approach to this issue.

First, many BA's will only create a glossary as part of their requirements in order to define what the term means as used in the requirements. This means the glossary is often not created until after elicitation is mostly complete and analysis is well under way. This means they have lost the potential benefits of learning the stakeholder's language in depth during the elicitation and enterprise analysis activities.
Second, a glossary is best suited for defining what a term means. It doesn't do a very good job of showing how terms and concepts are related to each other.
Third, the focus of many BA's when creating a glossary is defining a standard definition for a term when used by all stakeholders in a project. This is NECESSARY for project communications, but it also means that the BA has usually failed to document how a term is used by each stakeholder, leaving them unaware of potential communication issues.

Even the IIBA says in BABOK 2 that the main usage of a glossary is:

… for ensuring that all stakeholders are in agreement on the format and content of relevant information.

So that rather than understanding each stakeholders potentially unique language the glossary envisioned by the IIBA is most for imposing a unified language on all stakeholders for project communications.

So how do we address these issues, if you agree that they are valid issues at all? My recommendations are as follows:

The VERY FIRST activity you should undertake with each new stakeholder and SME is defining the language they use through evolving glossaries and concept maps. This may be done as part of process mapping and other elicitation activities, but it needs to be the major focus at the start.
You should create a separate glossary and concept map for each business unit or team you engage with as part of your business analysis effort, at a minimum. I have found slight but important differences in terminology even among members of the same team.
The results of the first two activities above should be the primary inputs for your project / requirements glossary. You want to define definitions and relationships for the project that are closest to what the majority of important stakeholders involved in the project use.

By taking these steps, a business analyst can:

Know exactly how a stakeholder will unconsciously interpret information given to them, by knowing how they use concepts and the relations between concepts.
Tailor their elicitation and other communications activity to best suit the stakeholder(s) they are communicating with.
Identify likely communication gaps and issues amongst stakeholders and in project team communications to various stakeholders.

I am adding wiki entries for these two techniques today, which include detailed information on creating glossaries (including information on how to write definitions) and concept maps. I have even included examples of an actual early stage glossary and concept map for the primary business unit I have recently started working with on a project. This way you can see how the two techniques complement each other.

You can access both wiki pages via these links, or on the wiki home page:

As always, feedback is welcome. Especially if you use other techniques for learning the stakeholders language.

Thank you for reading.