Identify Data Subject-Matter Experts
Key Takeaways
- Domain III, Task 2 exists because schemas and data dictionaries never record that a status code was repurposed during a migration, that a field is populated by one region only, or that a null means 'not asked' rather than 'no'.
- The enablers name four distinct expert populations — domain experts, business users who create or consume the data, data stewards and governance, and technical system experts — and they hold different, non-substitutable knowledge.
- SME access must be a named resource commitment with stated hours, line-manager agreement and a backup name, recorded in the RACI and resource plan; 'she said she would help' is a single point of failure.
- Every SME answer goes into a data decision log with the question, the person, the date and the ruling, so Data Preparation does not re-ask the question and get a different answer.
- When the data contradicts the documentation, the project manager takes the discrepancy to an SME before concluding the data is wrong, cleaning it or excluding it — anomalies are usually real events the model will meet again in production.
Documentation Does Not Know What People Know
A schema tells you a column's name and type and almost nothing about its meaning. Only people know that a status code was repurposed in 2021 when the CRM was migrated, that a field is populated diligently by one region and left blank by the other four, that a null in 'household income' means not asked rather than zero, or that the operations team has been keying a workaround value into a free-text comment box since the last release. None of that appears in a data dictionary, and every one of those facts can invalidate a model. Identifying data subject-matter experts (SMEs) is not networking; it is the control that stops you building on a misread field.
The task also protects your schedule. SME time is the scarcest resource in CPMAI Phase 2, Data Understanding, and it is almost never planned. Discovering in week six that the only person who understands the legacy claims status flags retires in three weeks is a risk you created by not asking in week one.
Four Kinds of Expert, Four Kinds of Knowledge
The enablers name four populations, and they are not interchangeable.
| Expert type | What only they know | Question to ask them | Risk if you skip them |
|---|---|---|---|
| Domain expert (process or subject authority) | Why the business behaves as it does; which patterns are real and which are artifacts of policy | 'If the model flagged this record, would you agree with it — and why?' | Features that encode a policy quirk instead of customer behavior; a model that simply reproduces last year's rules |
| Business user (creates or consumes the data) | What actually gets typed into each field, which workarounds exist, what a blank means | 'Walk me through what you enter when the customer will not give a date of birth' | Silent data-entry conventions read as genuine signal; nulls misinterpreted as zeros or negatives |
| Data steward / governance | Authoritative definitions, lineage, retention rules, classification, consent basis and approved uses | 'Which system is the system of record, and what are we permitted to use this for?' | Building on an unapproved copy; a permitted-use or privacy failure discovered after the model works |
| Technical / system expert (DBA, integration or platform engineer) | Schema history, migrations, load timing, key structures, what the overnight batch job does | 'When did this table change shape, and what happens to records that fail validation?' | Broken joins, silent truncation, and history that quietly starts on a migration date nobody mentioned |
Two people are usually missing from the project org chart and worth naming explicitly: the person who fixes the report when it breaks, and the long-serving operations supervisor who remembers every policy change that altered the data.
Locating Them
- System ownership records and the CMDB give you the technical owner. That is a starting point, not the meaning.
- The data catalog or dictionary — the steward name on the entry is often more valuable than the entry itself.
- Follow the process, not the org chart. Trace a transaction from the moment a human creates it to the moment it lands in the warehouse, and interview someone at every hand-off. Each hand-off is where meaning changes.
- Ask who gets called when the report breaks or when a number looks wrong. That person is a data SME whether or not their job title says so.
- Ask each SME who else you should speak to, and stop when the names stop being new.
Secure Their Time as a Commitment, Not a Favor
Domain II closes with identifying project resources, and data SMEs belong in that plan alongside engineers and modelers. Convert goodwill into something you can hold: a named individual, a stated commitment such as four hours a week through Data Understanding, explicit agreement from their line manager, and a named backup. Record it in the RACI and the resource plan, and reflect it in the schedule as a dependency. Where an SME sits with a vendor or contractor, the commitment belongs in the statement of work. An informal promise from one helpful person is a single point of failure with a holiday already booked.
Be specific about what you are asking for, because SMEs are more generous with bounded requests. 'Ninety minutes to review a data profile and answer twelve questions' gets accepted; 'we will need some of your time over the next few months' gets deferred.
Channels and Decision Capture
Establishing communication channels means standing arrangements, not ad-hoc messages to whoever answered last time:
- a shared channel per data domain, so questions are visible and anyone free can answer;
- a short recurring working session during Data Understanding rather than one long workshop nobody can attend;
- a named escalation path when a question stalls, and an agreed response expectation;
- a single place where profiles and open questions live, so SMEs are not chasing attachments.
The part that pays for itself is decision capture. Every answer goes into a data decision log — the question, the SME who answered, the date and the ruling — and, where it changes meaning, into the data dictionary itself. Without this, Data Preparation re-asks the same question of a different person, gets a different answer, and nobody can explain during Model Evaluation why a field was filtered. That log doubles as the accountability evidence Domain I expects you to keep.
Exam Behavior: Ask Before You Assume
When the data contradicts the documentation — 12% of records carry a status the dictionary does not list, volumes fall off a cliff in March 2021, a supposedly mandatory field is 40% blank — the exam's correct answer is to take the discrepancy to the SME before concluding the data is wrong, before cleaning it and before excluding it. Anomalies are usually real: a system migration, a merged business unit, a regulator-mandated new code, a policy change. Deleting them destroys signal and hides a fact the model will meet again in production. The pattern to carry into the exam is profile, then ask, then decide, then log the decision. A project manager who cleans first has usually thrown away the most informative thing in the dataset.
While profiling claims data, an analyst finds that 12% of records carry a status code that does not appear in the data dictionary, and almost all of them predate March 2021. What should the project manager do first?
A project manager has strong support from the data engineering team, who can explain every table, join and load schedule in the warehouse. The sponsor asks whether additional subject-matter experts are really necessary. What is the strongest justification for engaging more SMEs?
A data steward mentions in passing that a null in the marketing consent field means the customer was never asked, not that they refused. The project manager agrees this materially changes how the field must be treated. What should the project manager do next?