As described by their creators,
Concept maps are graphical tools for organizing and representing knowledge." 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. 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:
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.
Propositions are some statement about some object or event in the universe. 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.
Concept Maps have a number of uses in the Business Analysis domain, including:
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.
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.
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.
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.
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.
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):
Fully Automated Report
U.S. Retail Fund
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.
U.S. Retail Fund
Fully Automated Report
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.
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:
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.
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
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
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 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". 
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.
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.
sentences in a box. If you can't label a concept with a 1-3 words, you probably need to break the concept down more.