Concept Map

This is only a mid-level overview of Concept Maps that applies them specifically to the world of Business Analysis. For detailed information, including research papers, background, and supporting software; please go to the archive of information on Concept Maps at the Institute for Human and Machine Cognition (where they were pioneered). Those web pages should be considered the ultimate resource for Concept Maps.

 

What is a Concept Map?

As described by their creators, Concept maps are graphical tools for organizing and representing knowledge."[1] More simply, concept maps are a way of showing the relationships between concepts within a domain of knowledge and how multiple concepts are interlinked to form a framework or foundation of knowledge in a specific domain.

They were developed in 1972 during research by Joseph D. Novak at Cornell University in which he was trying to follow and understand changes in children's knowledge of science.[1] They were struggling to identify specific changes in children's understanding of science concepts through interviews, and came up with the concept map idea as a way of modeling children's understanding of concepts and relationships, and how it changed over time.

Concept Maps are comprised of three different elements, which are:

Concepts
A concept is defined as a perceived regularity in events or objects, or records of events or objects, designated by a label. Basically, it's just about any thing, term, or idea that exists within a regular structure or framework (it's not unique). In a concept map a concept is typically represented by a box or circle that encloses the label.
Linking Words
Linking words or linking phrases specify the relationship that two concepts have to each other, if any. Linking words are indicated by an arrowed line leading from one concept to another, with a word or phrase on the line that indicate the type of relationship.
Propositions
Propositions are some statement about some object or event in the universe.[1] They are created by combining two or more concepts linking words to form a meaningful statement. Propositions, by demonstrating the relationship between two or more concepts, are the foundation of knowledge.
 

Why should I use Concept Maps?

Concept Maps have a number of uses in the Business Analysis domain, including:

Learning the Clients Language

In combination with Glossaries, Concept Maps are among the best ways for a business analyst to learn the language of a new client they are starting to work with, regardless of whether that client is internal or external to their organization. Essentially, the glossary is used to understand the meanings of terms and concepts used by the client, while the concept map is used to understand the relationships between those terms and concepts.

Depending on the circumstances, you may want to create a glossary and concept map for each different business unit or client you work with so that you have documented the way they speak amongst themselves and can be sure to speak to them in the way they best understand.

Establishing a Consistent Project Language

Similar to learning the clients language, concept maps and glossaries are very useful in establishing a singular project language that will be shared amongst all stakeholders involved in the project, so that everyone know what exactly is meant by the use of a term in a project document, meeting, etc. This is how glossaries are often described as being used in business analysis, and concept maps can supplement the glossary in documenting the official relationship between terms for project use.

Eliciting Tacit Knowledge

Working with an SME to create a concept map related to their specific area of expertise is a great way to identify and elicit tacit knowledge they may have. By working with them to identify the concepts they use, the hierarchy of those concepts, and the various relationships among them and presenting that knowledge back in a visual way; the business analysis can help the SME identify gaps in the information they have provided and clarify unconscious knowledge of relationships.

Identifying Potential Requirements Dependencies

A well-constructed concept map can also help the business analyst in identifying potential requirements dependencies based on the relationships between the concepts. Especially concept relationships that span across sub-groups within the concept map. These relationships often point to business rules and functional dependencies that may not be obvious. And if nothing else, the identified relationships help the business analyst in planning their elicitation activities so that they are aware of potential dependencies and can dive into more detail when working with SME's and others.

 

How do I create a Concept Map?

Step 1 - Select the Domain / Question

The first step in creating a concept map is to select the domain of knowledge or specific question you are going to map. The creators of the concept map idea believe that every map should try to answer a specific question, and one way of doing this is to specify a focus question, which clearly specifies the problem or issue the concept map should help to resolve.

However, I have found that just mapping a new knowledge domain can be a useful activity for business analysts itself. So you might decide to map the concepts and terminology commonly used by Business Team X or in support of "Business Process Y. Just be clear on what it is you are mapping or your map will lose coherency of purpose and be less useful.

 

Step 2 - Identify the Key Concepts

The second step is to begin to identify the key concepts that apply to the domain being mapped. If you have started work on a Glossary, you can start with those terms. But if not, start off with trying to list as many terms and concepts that apply to the domain you are exploring as possible.

As an example, here is the list of terms I used for the Glossary wiki entry, which come from a project I am working on about Institutional Client Reporting that is still early in the concept phase (at the time of writing this):

3c7

3c11

Account

Ad-Hoc Report

Attribution

Batch Report

Benchmark

Caveat

Chart

Chunk

Client

Commentary

Commingled Trust

Consultant

Content

Data

Digital Asset

Fully Automated Report

Holding

Institutional Client

Institutional Vehicle

Investment Vehicle

Manual Report

Partially-Automated Report

Private Fund

Product

Report

Reporting Period

Retail Client

Retail Vehicle

Scheduled Report

Separate Account

SICAV

Static Text

Template

Triggered Report

U.S. Retail Fund

 

Step 3 - Order the Concepts

Once you have the initial list of concepts, try to re-order the list so that the most general concepts are at the top and the most specific concepts are at the bottom.

Client

Institutional Client

Retail Client

Account

Holding

Consultant

Investment

Product

Investment Vehicle

Benchmark

3c7

3c11

Commingled Trust

Institutional Vehicle

Private Fund

Retail Vehicle

Separate Account

SICAV

U.S. Retail Fund

Report

Ad-Hoc Report

Batch Report

Fully Automated Report

Manual Report

Partially-Automated Report

Scheduled Report

Template

Triggered Report

Reporting Period

Content

Chunk

Data

Attribution

Caveat

Chart

Commentary

Digital Asset

Static Text

 

Step 4 - Map the Most General Concepts

The creators of concept maps say they should be hierarchical in design, although I think that factors such as the amount of presentation space, the number of concepts, and complexity of concept links can sometimes make achieving a hierarchical design difficult.

However, before you start creating your concept map it is usually a good idea to decide what your primary or core concept will be. This should be the highest concept in a hierarchical map, or is generally where you would want a reader of the concept map to start.

In the case of my example, the concept I am exploring is the Institutional Client Reporting activity domain of my employer. Institutional in this case is a type of client, and so is more specific than the term Client. Reporting is an activity, and is the primary activity being analyzed, but it is an activity that is done in response to a client. Based on that simple logic, I am going to start off with Client as my primary concept.

Place your primary concept at the top and center of your work-space. If whatever mechanism you are using to create the map supports it, I like to color this primary concept with a green background to show it is the "starting point" of the map. But again, this is not part of the standard process defined by the creators of concept maps.

Next, add a second concept below it somewhere, and draw an arrowed line between the two. Then add text to the line that describes the relationship between the two the concepts. This linkage of two concepts by an arrow and relationship form a proposition (discussed above).   The direction of the arrow should reflect the direction that the proposition should be read.

It is important to realize that almost any concept you are mapping can be related to any other concept you are mapping, because you are focusing on a specific domain or question. However, you should try to only map (at least initially) the most relevant and important relationships.

Taking the actions above results in a partial concept map like the one below.

A Concept Map Example - Step 4  

Step 5 - Add More Detailed Concepts

The next step is to add more concepts to your map that are of a more specific, less generic, nature. You can generally do this in two ways:

  1. You can take each of the more generic concepts you started with and add the next level of more detailed concepts that relate them. This has the effect of incrementally expanding the concept map overall.
  2. You can take one of your generic concepts, and build out that "node" of the concept map until you can think of no more related concepts or relationships. This has the effect of significantly expanding one section of the concept map.

If you clustered your concept list into related groups like I did in Step 3 above, the second option is often the easiest next step. So in this example I am going to expand out the area of the map that relates to Product since it is the largest group of concepts I created in Step 3.

One thing to be aware of at this stage is that the creators of concept maps say that examples of a concept in a map should not be in the same type of visual entity as a concept (for example, in the concept map below a Separate Account is really just an example of an Investment Vehicle and not necessarily a concept of its own, therefore it should not be contained in a rounded rectangle). I often don't follow that rule, but it's worth considering whether your concept map will follow that rule or not.

A Concept Map Example - Step 5  

Step 6 - Add More Detailed Concepts, Again

Repeat the same process you did in Step 5 above, but for a different generic concept. For this example, I am going to add more detailed concepts to the map that relate to the Content concept.

A Concept Map Example - Step 6  

Step 7 - Finish Adding All of Your Initial Concepts

As in the previous two steps, pick a generic concept that has more detailed concepts below it and expand the map. In this example, I will now add the more detailed concepts that are related to the generic Reports concept.

You would keep repeating this until you have added all of your initial concepts from the list in Step 3, but this will be the last of them from them for the example.

A Concept Map Example - Step 7  

Step 8 - Revise, Revise, Revise

A concept map will probably never be final. As you learn more, you will be able to add more concepts, more relationships between the concepts, improve the words used to describe the relationships, and change the layout of the map to make the overall map and the knowledge it represents easier to understand. The creators of concept maps say that in their experience, it usually takes at least 3 iterations of a map to achieve one that is "good". [1]

One thing to look for as you are revising your initial few drafts are for relational links that reach across the different sections, or clusters, of the map. These are usually non-obvious relationships that are often important.

 

What Should the Results be?

The final result below adds a label to the overall concept map, but it otherwise the same as what was in Step 7 above. Please realize that this map is the result of working with just the 2 core groups of my project. We haven't even started with the various support teams and those business units that are further away from the core activity. As I work with those groups, the map will likely change even more, or I may end up creating several maps that focus on specific questions.

Another really good example of the final result should be is this Concept Map about Concept maps.  For copyright reasons, I won't include the actual diagram.

But hopefully the example linked to above and the example below give you a good idea of how useful a relatively simple diagram like a concept map can be.

A Concept Map Example - Final Result  

Advantages

   

Disadvantages

 

Tips

 

References

  1. Research Paper: The Theory Underlying Concept Maps and How to Construct and Use Them. By Joseph D. Novak and Alberto J. Canas.  A Technical Report for the Institute of Human and Machine Cognition (IHMC). 2006.
  2. Web Page: What is a Concept Map? By Joseph D. Novak and Alberto J. Canas. Last Update: Sept. 28, 2009
 

Related Resources