EN
Transparent mechanical model connected to four small modules through blue components and lines.

How to validate that an architecture represents real work

Before using a skills architecture to assess people, validate it by testing its definitions against real decisions, deliverables, and situations.

PRYSMAP5 min read

Before you begin, define the scope of the validation. Select one track, the roles it contains, and the uses the model will support. Trying to review the entire organization at once turns a verifiable test into an endless debate about names.

The goal is not to prove that the catalog can describe every activity. It is to determine whether it represents the relevant work precisely enough to distinguish contributions and support the intended decisions.

Choose situations that demand different things

Gather examples of frequent work, exceptions that required judgment, and uncommon situations with significant consequences. A final deliverable provides information, but it rarely lets you reconstruct on its own how the work was produced.

For each situation, identify the expected outcome, the constraints in place, and the decisions that changed the course of events. Record who had authority, what information was missing, and when support became necessary.

The Office of Personnel Management connects job analysis with actual tasks, required competencies, and the relationship between them. That link directs validation toward observable demands rather than limiting it to opinions about labels. U.S. Office of Personnel Management: Job Analysis.

The cases should be sufficiently different. If all of them represent routine operations, the architecture may appear sound yet fail when an exception arises. If only extraordinary incidents are selected, it may overrepresent capabilities that rarely organize everyday work.

Reconstruct first; classify later

Ask the people involved to explain the full sequence. What happened? What alternative did they consider? What was the difficult decision? What consequence did they need to anticipate?

Do not open the catalog yet. When labels appear too early, people tend to fit their account into familiar categories. That process can conceal contributions the model does not represent well.

The same situation may combine analysis, coordination, risk management, and communication. First understand how those contributions related to one another. Then examine which skills can describe them without duplicating names or artificially fragmenting the work.

If two participants remember different episodes, preserve the discrepancy until it is clarified. A disagreement about the facts cannot be resolved by negotiating a shared classification.

Test shared skills and differences between roles

Roles within the same track should retain the same set of skills. They differ in expected depth, autonomy, complexity, scope, leadership, and impact.

Take a representative situation and present it to people in two roles within the track. Ask what they would resolve directly, when they would need support, and which consequences they would be accountable for.

Two technicians inspect and adjust a mechanism on a workbench in a bicycle workshop.

If both roles describe exactly the same contribution, the distinction in level may be nominal. If one integrates more variables, resolves exceptions, and is accountable for broader effects, the difference lies in the expectation, not in a separate catalog. The distinction among breadth, depth, and integration makes it possible to test whether the configuration responds to demand without fixing an identity.

Also review the path in reverse. Select a skill and ask for evidence of where it appears. When no one can connect it to identifiable decisions or outcomes, it may be misplaced. The selected cases may also have excluded a relevant situation.

This check extends the distinction developed in A list of skills is not an architecture: the model’s relationships become valuable only when they explain recognizable work.

Diagnose disagreement before changing the model

Two specialists may assign different levels to the same episode for very different reasons. One may have observed the result while the other knew the process. They may also have used ambiguous anchors or compared contexts with different degrees of autonomy.

At least four possibilities should be separated:

  • information about the episode is missing;
  • the definition allows incompatible interpretations;
  • the cases involve different levels of complexity;
  • the responsibility belongs to another role or track.

Each cause calls for a specific response. Gathering evidence, refining a definition, and changing the scope are not equivalent decisions. Nor should we turn an absence of information into a demonstrated deficit.

Record the change and test again

Document the situation examined, the problem detected, the information gathered, the decision made, and who will be accountable for following up. Keep the record limited to the agreed purpose.

The OPM checklist includes documenting relevant tasks and competencies to support subsequent decisions. In a corporate architecture, that traceability makes it possible to explain why a definition is retained, changed, or retired. U.S. Office of Personnel Management: Job Analysis Checklist.

If a shared skill changes, review the effects on every role in the track. Then repeat the test with a different situation. A modification that fixes an exceptional case but makes routine work harder to understand is not ready.

A validated architecture does not need to anticipate every future exception. It must represent known work, distinguish contributions, and make missing evidence visible when a new situation arises.

To extend this reading, see The org chart is not a map of the work and How to scale beyond the pilot without losing quality, which develop complementary dimensions of the problem.