Who Confirms What in Your Ontology Pilot? A Responsibility Matrix That Tracks Expert Time and Handover Readiness

The Problem: Vague "Expert Support" Stalls Pilots

An after-sales service ontology pilot is planned with modelers, developers, and a project manager. The schedule simply says "Week 2: business expert confirms rules." When week 2 arrives, the expert is handling customer complaints. A meeting yields a few exceptions; the modeler revises. The next review brings a different person who says "that was the old practice, the new contract doesn't allow it." Code and models are ready, but the project stalls at confirmation — not because the business is uncooperative, but because the plan never specified who reviews what, what preparation is needed, how much time is allocated, or who decides when opinions conflict.

"Assign an Expert" Is Too Vague

The pilot's first scope: the assistant only checks whether equipment falls within free on-site service; final confirmation stays with the original process. Checking this one item requires reading contracts, equipment records, and special promises made by sales. Customer-service staff know the intake flow but may lack authority to confirm contract exceptions; regional managers know past promises but may lack authority to extend them to all customers; system engineers know field sources but cannot decide service liability. Before recruiting, define the exact task: recall a ticket's handling, confirm which contract type maps to which rule, or approve check results for the service workflow. These need different experience and authority. The same person can cover several, but seniority alone shouldn't grant sign-off for every department.

Use a Deliverable Checklist to Assign Owners

At kickoff, list deliverables and assign preparers and confirmers for each. The article provides a "Ontology Pilot Responsibility & Effort Checklist" with seven deliverables:

Deliverable | Who Prepares | Who Confirms | Often-Missed Effort
--- | --- | --- | ---
Scenarios & acceptance goals | Business analysts, user roles | Designated business owner | Discussing out-of-scope items, collecting failed tickets
Service definitions & exceptions | Modelers organize; contract & service experts supplement | Authorized rule approver | Cross-checking contract versions, handling special promises
Object identity & data mapping | Data & source-system staff | Data owner verifies facts; business verifies relationship meaning | Looking up field meanings, requesting permissions, verifying history
Business model | Ontology engineers (AI-assisted drafting) | Engineers check expression; business confirms meaning | Revising drafts, checking exceptions and affected definitions
Queries & business interfaces | Application & integration staff | System owner confirms technical conditions; business confirms usage results | Integration testing, exception handling, legacy-system support
Acceptance samples & results | Testers organize; business provides evidence | Testers verify actual results; business owner confirms expectations & acceptance conclusion | Not copying model answers; adding exceptions and evidence-gap samples
Release & ongoing maintenance | Ops & capability maintainers | Enterprise-authorized release owner | Monitoring, error handling, version changes, personnel handover

These are seven work items, not seven new hires. Small projects can combine roles, but required reviews and approval authorities don't expand just because one person wears multiple hats. If the enterprise already uses a RACI matrix (Responsible, Accountable, Consulted, Informed), plug these tasks into it. The checklist is not a full RACI; multi-party confirmations must be split — e.g., data owner confirms source facts, business owner confirms relationship meaning — not blurred into "joint signature." At release, the release owner can decide timing per authorization but cannot use a single sign-off to paper over unfinished contract rules or data confirmations.

Break Expert Time into Schedulable Work

"Expert supports for three days" looks scheduled but hides whether those days are for reading, meetings, or waiting for missing contracts. The author recommends engineering teams send review materials beforehand: rules to confirm, source references, changes, unresolved disputes, plus sample normal and exceptional tickets. When using OPM (Object-Process Methodology), diagrams can explain equipment, service tasks, and state changes without requiring experts to learn modeling syntax.

Each review should target one decision. Example: "Does this contract type's free on-site service cover this failure?" Put the clause, equipment data, and dispute points together — more effective than dumping hundreds of model elements and asking "overall okay?" Engineers must filter duplicates, invalid references, and obvious expression issues first; list unsupported candidates separately. Don't make experts hunt for truth in a long LLM-generated draft. Every confirmation must carry its evidence and open points; allow answers like "insufficient evidence," "exception exists," or "question is framed wrong" — not just "agree/disagree" for easy counting.

After confirmation, record: rule version, applicable contracts, evidence, confirmer. If engineers change business meaning, send affected parts back to the responsible owner for re-review; don't reuse a previous "no issues" on a new version.

Estimate time by piloting a small rule batch — mix easy confirmations with exceptions and cross-department disputes. Log reading, discussion, evidence-gathering, and re-review durations, then extrapolate. Ten easy rules passing in 30 minutes doesn't mean 100 rules take five hours.

Record actual expert hours separately from calendar wait time. The former informs effort estimation; the latter informs scheduling. Lean management distinguishes Processing Time (actual work) from Production Lead Time (end-to-end including waits). Example: materials submitted, five business days pass, expert spends 15 minutes reviewing. The lead time is not 15 minutes. Investigate whether the delay came from scheduling, evidence gathering, or another department's decision. If multiple experts review in parallel, sum their person-hours but don't equate that to elapsed time. If the team stays occupied during the wait, log that effort separately. Adding more developers rarely solves a rule stuck awaiting approval.

Put the Project on the Expert's Calendar

If the project demands expert time, their manager must prioritize that window. Experts evaluated only on daily operations, with unchanged workload, cannot sustain "on-call" project demands. A new KPI isn't mandatory, but review effort should be recognized and existing tasks coordinated — not left to ad-hoc nagging. The pilot lead should agree with the business manager on review slots, priority, and backup plans. A substitute who can explain the business may lack confirmation authority; their role must be explicit. Time allocation depends on scope; don't budget "free business support" by default.

If a dispute can't be resolved quickly, continue evidence gathering, escalate to the authorized decision-maker, or temporarily remove the item from scope — and disable any logic that depends on it. Don't delete the rule from the review list while the assistant keeps answering based on it. The time saved should come from eliminating experts' repeated document searches and re-reads; faster model generation doesn't help if experts must re-review from scratch each time.

Before Quoting Timeline, List What You're Still Waiting For

Two projects with the same dozen business concepts can have vastly different timelines: one has reliable interfaces and clear rules; the other must re-verify historical contracts. Before quoting, estimate model curation, business confirmation, data prep, system integration, trial testing, and ongoing maintenance separately. Note what's missing and who you're waiting on. Source-system cooperation, business re-reviews, and trial-error correction all count as effort — not just the implementation contract's person-days.

When core rules and interfaces are still fuzzy, run a scoped, time-boxed discovery sprint with budget and deadline to produce candidate models, open issues, and a refined estimate. Know where the difficulty lies before committing to the full pilot timeline.

The implementer can prepare materials, build models, and create tools, but formal definitions, confirmation records, and acceptance evidence must be owned and accessible by the enterprise. These belong in the delivery package — don't discover at acceptance that explaining a rule requires bringing back the original consultant.

Can the Handover Team Operate Independently?

After go-live, service policies change, system fields shift, people rotate. Schedule a handover drill during acceptance: give the designated handover team a simulated, unpracticed policy change in the test environment. The original consultant observes but does not operate. The team must use delivered artifacts to locate sources, confirmers, affected applications, and test records; then execute revision, re-review, regression test, and simulated release per their permissions. Business rules still require authorized confirmation — independent operation doesn't mean ops staff can unilaterally decide.

Record actual time, sticking points, help requests, and outcomes. Verify rollback capability on publish failure. Correctly stopping when authority or evidence is lacking is also a tested capability. This drill validates handover readiness, not speed, and doesn't touch production.

If every step needs the original consultant's verbal explanation, supplement handover materials or training. The incoming team needn't know all business immediately, but must know where to find evidence, what they cannot decide alone, and whom to escalate to. When customer service finds a scope misinterpretation, there must be a clear path: who diagnoses whether it's data, rule, or code; who handles it — not a generic "try rephrasing the question."

Summary

The pilot's gap wasn't another expert; it was making "Week 2: confirm rules" concrete: who prepares materials upfront, who has authority, when reviews happen, how disputes are resolved, who re-reviews after changes. Put those times into the plan, and the project stops waiting on "please business support."

Where does the evidence for review come from? The next article discusses organizing documents, system records, and expert experience around a single business question.

References

Carkenord et al., Partnering for project success: project manager and business analyst collaboration , PMI Global Congress, 2010. Used to explain RACI's Responsible, Accountable, Consulted, Informed roles; this checklist is tailored to the after-sales ontology pilot, not a standard RACI template. URL: https://www.pmi.org/learning/library/business-analyst-project-manager-collaboration-6512

Lean Enterprise Institute, Cycle Time , covering Processing Time vs. Production Lead Time. Used to distinguish actual handling time from end-to-end cycle; the 15-minute/5-day example is hypothetical, not from the source. URL: https://www.lean.org/lexicon-terms/cycle-time/