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.

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:

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

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:

  1. 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.
  2. 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.
  3. 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:

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.

© 2014 by David Olson