Data Representation

General technique · See it on the map

Guide only — An umbrella group; its members are the runnable ones.

The general term for turning analyzed data into a picture a reader can absorb quickly.

When to use it

You have a finding or a data set and the audience needs to see the relationships in it, not just read a description of them — grouping, hierarchy, cause-and-effect, or a two-axis comparison are each easier to absorb visually than as prose.

When to avoid it

When a plain sentence or a single number says everything the audience needs — building a matrix diagram for a decision with one clear answer is decoration, not communication. Also avoid picking a format for its polish rather than its fit: a mind map dressed up to look rigorous doesn't make a fuzzy idea rigorous.

Steps

1. Identify the relationship in the data that matters most — grouping, hierarchy, cause-and-effect, sequence, or a two-axis comparison.
2. Pick the format built for that relationship: affinity diagrams for grouping loose ideas, cause-and-effect diagrams for tracing a problem to its sources, flowcharts for sequence and branching, hierarchical charts for structure, matrix diagrams or a probability-and-impact matrix for two-axis comparison, SWOT for a four-quadrant internal/external view.
3. Build it from the data you already analyzed — don't let the act of drawing the diagram substitute for having done the analysis.
4. Label every element; an unlabeled box or arrow forces the reader to guess what you meant.
5. Check the diagram against the underlying data once more before it goes into a deliverable — a mislabeled node is easy to introduce while drawing.

What it produces

• A diagram or chart that carries the finding, plus the data it was built from.

Common pitfalls

• Picking a format for how it looks rather than what relationship it's built to show — a fishbone diagram for data with no cause-and-effect structure.
• Skipping labels and leaving the reader to infer what a box or axis means.
• Treating the diagram as the analysis instead of a representation of analysis already done.
• Letting the diagram go stale after the underlying data changes.

Worked example

After the root cause analysis on late deliveries turns up five contributing factors, the quality lead builds a cause-and-effect diagram grouping them under supplier lead time, internal scheduling, and inspection delay, so the steering committee can see which branch to attack first instead of reading a five-item list.

Where it comes from: this technique is named by the PMBOK Guide, 6th edition. No clause number is recorded for it here — a guessed citation would be worse than none. An umbrella technique group PMBOK-6 names in many processes' ITTO tables across knowledge areas; its members carry the clause numbers, it does not.