Coming to Terms

How can business analysts avoid misunderstandings and streamline the discovery of business needs in a new domain? Savvy analysts come to terms with stakeholder terminology, starting with a glossary.

Business analysts and architects often learn a new vocabulary during discovery — the business domain’s terminology. Often, stakeholders use terms without shared meanings. Therefore, stakeholders need to communicate accurately with agreement on what these terms mean.

One stakeholder, typically in a business analyst role, should own the glossary and ensure all stakeholders agree on the meaning of the terms. The glossary owner should make it available to all stakeholders. He or she updates the glossary to reflect changes initiated by and agreed upon by the stakeholders.

Example Glossary of Terms

Here is a sample glossary of key Salesforce customer relationship management (CRM) terms:

Source: Salesforce Glossary

Each business defines its own terms, typically based on standard industry usage. For example, a financial services firm could define “Account” as a repository for financial assets. They could describe a person doing business with their firm as a “Client.”

An Opportunity for Misunderstanding

Suppose an organization implements Salesforce CRM without understanding the terms shown above. 

One stakeholder interprets Opportunity as a proposal and confuses it with Quote. 

Another stakeholder thinks of Opportunity as a potential order, not realizing Order has its own definition. 

The two stakeholders work at cross-purposes when discussing opportunities. Distinguishing the meanings of Quotes, Orders, and Opportunities clarifies their conversation.

Discovering Business Terms

Most business terms emerge during discovery. Ideally, the business analyst can uncover these terms from documents and reports before the first discovery meeting. He or she should pay attention to nouns: people, places, and things the business manages within the solution scope. For example, a non-profit organization could deal with donors, donations, and event venues.

When a business stakeholder introduces a term open to interpretation, the glossary owner should ask the stakeholder what he or she means by the term. For example, a stakeholder mentions the word “staff” after previously referring to “employees.” What distinguishes ‘staff” from “employees”? It could turn out that “staff” includes employees and contractors.

The glossary defines terms only to clarify communication between stakeholders. The glossary is not a data dictionary. It could serve as a reference for a data dictionary later during solution design. The glossary owner should focus on all stakeholders agreeing on the meaning of terms.

If stakeholders have different interpretations of a term, they should reconcile those differences before the term goes in the glossary. Then, the glossary owner will capture and acknowledge the reconciled definition in the glossary, recording the common understanding of the term. Thus, the glossary lays the groundwork for clear communication and understanding of business needs through the entire development process.

Becoming Clear on the Concepts

Once the glossary owner has compiled the business terms, how can he or she show understanding of the terms? Reviewing the glossary term by term with stakeholders will likely drain their energy and attention. Besides, there’s more to business terms than their definitions.

Each customer term (noun) expresses a concept. For example, the six Salesforce terms listed above identify key customer relationship management concepts. Each concept has a relationship with one or more of the other concepts. 

For example:

An Account employs a Contact, enters into a Contract, presents an Opportunity, and places an Order. 

A Contact receives a Quote and negotiates a Contract. 

Account and Contact have seven relationships with the other concepts, which relate to each other.

Showing Concepts and Their Relationships

How does a business analyst show concepts and their relationships to the other stakeholders? By creating a diagram representing concepts in boxes connected by lines showing their relationships with each other. This diagram is called a concept map.

Here is a minimal concept map showing the relationships between all of the concepts listed above, except Contact:

The map shows each concept in a box. An arrow between two concept boxes shows their relationship. The arrow’s direction shows how to read the relationship between the related concepts. For example, an Account presents an Opportunity.

A minimal concept map like this works well to introduce concepts and their relationships. Showing a few concepts and relationships makes it easier for stakeholders to comprehend the concepts and their relationships.

Adding Contacts to the concept map introduces four relationships with the Contact concept:

Showing the Way to Deeper Understanding

Let’s say a business stakeholder asks what a contact does regarding opportunities or contracts. They want to know which contact makes a purchase decision, who influences the decision, and who negotiates the contract, among other things. In some cases, contacts play the same role in all opportunities. In others, contacts have multiple roles. Contract negotiation can involve several contacts in various roles.

The business analyst shows the Roles relating Contact to Account, Contract, and Opportunity:

Agility Starts Here

Incrementally creating a concept map takes the same approach as agile software development. It starts by showing stakeholders a minimal design and collecting feedback. The model development continues in cycles showing incremental changes. The stakeholders focus on fewer changes rather than deciphering a complex map revealed a long time after the last discovery meeting.

Concept Map Considerations

A concept map works hand in hand with the glossary, which defines each concept in the map. The glossary serves as a reference for understanding. The concept map illustrates comprehension. For example, a new stakeholder reviews the concept map and asks what a concept means. He or she finds the definition of the concept in the glossary.

Someone familiar with the Salesforce Sales Cloud data model may notice a resemblance between it and the example concept map shown above. Those very familiar with the data model will see differences between the two. A concept map is not a data model, even if it resembles one. It can inform the design of a data model later in the development cycle. A concept map does not require the details nor is subject to the constraints of a data model.

To some, a concept map may resemble a process map with its boxes and labeled arrows. However, it does not show process flow, only relationships between people, places, and things shown as concepts on the map. Process mapping typically happens later in the development cycle.

Putting It All Together

A business analyst compiles a glossary for stakeholders to agree on the meaning of domain terms that emerge during discovery. This agreement prevents misconceptions from working their way into solution development.

An analyst presents a concept map to reflect his or her understanding of domain-specific business concepts and their relationships. Business stakeholders have an opportunity to explain, correct or complete that understanding when reviewing the map. A shared understanding of concepts and relationships among all stakeholders clarifies their communications. In addition, this shared understanding prevents misunderstandings that result in a solution not meeting customer expectations.

Additional Information

I created the concept maps using Elements.cloud.  It is intended for drawing process maps but works well for creating concept maps.

For information about glossary challenges, see Overcoming common business analysis challenges related to glossaries.

For more information about creating concept maps, see Business Knowledge Blueprints by Ronald G. Ross.