If you are currently trying to get usable requirements out of someone who holds all the domain knowledge but has forty other things on their plate, you are dealing with the central challenge of working with a subject matter expert in project management. The relationship between a BA and an SME is not a passive information exchange. It is a working relationship that needs structure, clear expectations, and occasionally a degree of diplomatic firmness on your part. Get it right and your requirements are grounded in operational reality. Get it wrong and you are writing requirements in the dark.
I have worked with SMEs across government, utilities, health, education, and enterprise environments over the past 25 years. What I have learned is that the mechanics of the relationship matter as much as the quality of the questions you ask. Before you can capture what an SME knows, you need to understand what they actually contribute, how to engage them productively, and what to do when things get complicated.
What a Subject Matter Expert Actually Contributes
An SME is an individual with deep, specific knowledge in a domain that is critical to the project. In project management, that domain could be regulatory compliance, a technical platform, an operational process, a geographic region, or a specialist service area. Their contribution is not decorative. It is foundational. Without their input, requirements tend to drift toward the theoretical rather than the operational, and that gap always surfaces during testing or go-live when it is most expensive to fix.
In my experience, the SME’s contributions cluster around five distinct areas, though not all SMEs operate across all five on every project:
- Domain knowledge for requirements: SMEs provide the detailed process, policy, and technical context that shapes what the solution actually needs to do. This is the input that differentiates a useful requirements document from a generic one.
- Early risk identification: Because they know the domain well, a good SME will spot risks that neither the BA nor the project manager would find through desk research alone. They know where the exceptions live, where the regulatory tripwires are, and which processes break under pressure.
- Stakeholder translation: SMEs frequently act as a bridge between technical delivery teams and operational stakeholders. They can reframe technical proposals in terms that frontline staff understand, which reduces resistance to change.
- Quality review: In regulated industries particularly, SMEs serve as a check on whether deliverables meet established standards. This is not a formality. In a health or financial services context, a missed compliance requirement can invalidate an entire system build.
- Knowledge transfer and capability building: When the project ends, the institutional knowledge an SME has shared with the team does not disappear if it has been properly documented. It becomes part of the team’s capability going forward.
SME Involvement: Where They Add the Most Value
Not all SME involvement is equal. The table below shows where SME input tends to have the highest impact across the project lifecycle, based on my own practice. This can help you prioritise when to request SME time and how to frame those requests to a sponsor or project manager who is managing the SME’s availability.
| Project Stage | SME Contribution | Impact if SME is Absent |
|---|---|---|
| Discovery and scoping | Defining what the project actually needs to solve; validating problem statements | Scope is set against assumptions, not operational reality |
| Requirements elicitation | Providing process detail, exceptions, data rules, and regulatory constraints | Requirements are incomplete or theoretically correct but practically unworkable |
| Solution design review | Validating that proposed designs reflect how work actually happens | Solutions are built to a model of the business that does not exist in practice |
| Testing and UAT | Confirming that edge cases and exceptions are handled correctly | Defects in exception handling only found after go-live |
| Training and transition | Validating training materials; supporting knowledge transfer to operational teams | Training reflects the system, not how users will actually use it |
A Worked Example: When the SME Pushed Back on the Requirements
On Project X, a regulatory reporting initiative for Organisation B in the utilities sector, I was working as the lead BA responsible for capturing requirements for a new data submission process. The SME assigned to the project was the organisation’s senior compliance manager, a person with 18 years of domain experience and a very clear sense of how things should be done. She was also extraordinarily busy and deeply sceptical of the project’s timeline.
Three weeks into elicitation, she reviewed my draft requirements and told me, bluntly, that they were wrong. Not incomplete. Wrong. Specifically, she said the data validation rules I had documented did not reflect how the regulator actually interpreted the relevant legislative framework, and that if we built to my specification, the submissions would fail compliance checks before they ever reached the regulator’s system.
My initial reaction was to defend the documentation. I had based it on the policy documents she had pointed me toward in week one. She acknowledged that, and then explained something that is not in any policy document: the regulator had issued informal guidance at a sector briefing two years earlier that effectively overrode certain published validation rules, and that every compliance manager in the sector knew this but it had never been formally written down anywhere.
This is the kind of friction that does not show up in a smooth-running case study. I had to go back to the project manager, explain that three weeks of requirements work needed to be revised, and request an additional two sessions with the SME to capture the informal guidance properly. The project manager pushed back on the time. I held firm, documented the risk of proceeding without the revision, and escalated to the sponsor. The additional time was approved.
The revised requirements included a supplementary section on regulatory interpretation, cross-referenced to the sector briefing notes the SME provided. That section became the most-referenced part of the document during UAT. Without it, we would have built a system that was technically functional and regulatorily non-compliant. That scenario is entirely typical of what happens when SME knowledge is not captured at sufficient depth.
This kind of situation also illustrates why requirements elicitation questions need to go beyond the obvious. You are not just asking what the system should do. You are asking what the SME knows that is not written down anywhere.
How to Structure Your Collaboration with an SME
The practical question is not whether to involve SMEs but how to make the most of limited access to them. Here is how I approach it:
- Get access formally agreed before the project starts: SME availability should be named in the project plan or business analysis approach document, not assumed. If an SME’s time is not ring-fenced, it will be consumed by business as usual before you ever get a session in the diary.
- Prepare structured agendas for every session: An unstructured conversation with an SME is an expensive way to gather fragments of information. I always send an agenda at least 48 hours in advance and frame it around specific decisions that need to be made, not open-ended topics.
- Distinguish between what they know and what they assume: SMEs sometimes present assumptions as facts, particularly when they have been doing something the same way for years. A useful habit is to ask “Has that always been the case, or is that how it works currently?” and “Is that documented anywhere?” These questions surface tacit knowledge and distinguish current-state reality from historic practice.
- Document in real time and confirm immediately: I take notes during every SME session and circulate a summary within 24 hours. This is not just good practice. It gives the SME a chance to correct misunderstandings while the conversation is still fresh, and it creates a paper trail that protects both of you if the requirements are challenged later.
- Push for written sign-off on domain-critical requirements: In regulated environments particularly, verbal confirmation is not enough. I ask SMEs to sign off formally on requirements that fall within their domain. Most will do this without complaint if the ask is framed professionally and the document is clear.
When the SME Relationship Becomes Difficult
Not every SME relationship is productive. I have encountered three recurring patterns that complicate the collaboration, each of which needs a different response.
The first is the unavailable SME: someone who is formally assigned to the project but practically unreachable. The response here is escalation, but escalation framed around risk rather than frustration. Document what decisions cannot be made without SME input, quantify the impact on the project timeline, and take that to the project sponsor. This is not a complaint. It is a risk register entry that happens to require a human response.
The second is the over-controlling SME: someone who wants to shape the requirements to reflect how things have always been done rather than how they need to work in the new environment. This requires patience and a clear framing of the difference between current-state documentation and future-state requirements. I have found that involving these SMEs in structured workshops where multiple stakeholders are present can be more effective than one-to-one sessions, because it distributes the authority for decisions across the group.
The third is the SME who contradicts other SMEs. On complex projects, you will sometimes have two domain experts who give you conflicting information. Document both positions, identify the gap explicitly, and take it back to both parties together. Do not arbitrate between them yourself. The decision about which interpretation is correct belongs to the business, not to you.
Preserving What the SME Knows
One of the most undervalued contributions a BA makes on any project is converting tacit SME knowledge into documented organisational knowledge. When an SME leaves, retires, or moves to another role, the knowledge they held in their head goes with them unless it has been captured in your requirements, process documentation, or knowledge articles.
I make it a practice to maintain a running knowledge log during every project where I am working closely with an SME. This is not a formal deliverable. It is a working document where I record process rules, regulatory interpretations, exception cases, and contextual decisions that explain why certain requirements exist. When the project closes, that log feeds into the business analysis documentation pack and, where appropriate, into operational guidance for the team inheriting the system.
If you are working to produce formal documentation from these sessions, articles on business analysis documentation and stakeholder engagement can help you think through how to structure what you capture and how to keep SMEs engaged through the documentation process.
The SME relationship is, at its core, a knowledge management challenge wrapped in a stakeholder management challenge. The BAs who handle it well are not necessarily those who ask the best questions, though that matters. They are the ones who treat the SME’s time as a finite and precious resource, who come prepared, who document rigorously, and who are willing to push back when the project tries to move forward on incomplete domain knowledge. That combination of discipline and advocacy is what separates requirements that hold up in testing from requirements that collapse the moment a real user touches the system.
Frequently asked questions
What is a subject matter expert in project management?
A subject matter expert in project management is someone with deep, specialised knowledge in a specific domain that is critical to the project’s objectives. They provide the operational and technical context that shapes requirements, informs risk identification, and validates that deliverables meet domain-specific standards. Their input is particularly valuable in regulated industries where compliance requirements are complex and not always documented in publicly available sources.
How does a BA work with a subject matter expert?
A BA works with an SME by structuring elicitation sessions around specific decisions, preparing agendas in advance, and documenting outputs promptly for SME review and sign-off. The goal is to convert tacit domain knowledge into requirements and process documentation that the delivery team can act on. When access to the SME is limited, the BA needs to prioritise the highest-impact knowledge gaps and escalate availability issues through formal project risk channels.
What happens if a subject matter expert is not available on a project?
If an SME is unavailable, requirements risk being based on assumptions rather than operational reality, which typically surfaces as defects during testing or failures at go-live. The BA should document the dependency formally as a project risk, quantify the potential impact on the timeline and deliverables, and escalate to the sponsor to secure the access needed. Proceeding without adequate SME input is one of the most common and avoidable causes of requirements failure.
How do you manage a subject matter expert who pushes back on requirements?
When an SME pushes back on requirements, treat it as a signal worth investigating rather than a challenge to manage. Ask them to identify specifically what is incorrect and what the correct interpretation should be, and document both the original position and the revision with the SME’s rationale. If the revision affects scope or timeline, escalate formally rather than absorbing the change silently.
What is the difference between a subject matter expert and a stakeholder in project management?
A stakeholder is anyone with an interest in or who is affected by the project’s outcomes, while a subject matter expert is a specific type of stakeholder whose value to the project lies primarily in their domain knowledge rather than their organisational authority or interest. All SMEs are stakeholders, but not all stakeholders are SMEs. The distinction matters because SME engagement is structured around knowledge elicitation, whereas broader stakeholder engagement focuses on communication, change management, and alignment.
Try Ash, Your Virtual BA
If you are working with an SME right now and trying to turn what they know into structured, usable requirements, Ash can help you move faster. Ash is built for exactly this kind of work: it can help you frame elicitation questions by domain, draft requirements from session notes, and structure the outputs into a format your delivery team can act on. You do not need to start from a blank page after every SME session. Try Ash Virtual BA and see how quickly it gets you from conversation to documented requirement.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.