The Demo Worked. Now Who Owns It?

An AI connection that can answer one prompt has proved connectivity. It has not yet proved permission, readiness, or support.

In a demo, success arrives quickly: someone asks a question, the assistant returns an answer, and the room sees the potential.

That answer proves one thing: a request traveled somewhere and came back. It does not prove the assistant used the right data, that the user was allowed to see it, that the information was current, or that anyone knows what to do when the connection fails.

That is where the project begins.

One request can cross several boundaries

Imagine a sales team wants an AI assistant to summarize account activity and trends. One possible design brings Salesforce CRM data into Databricks, prepares it for analysis, and makes approved information available to an AI assistant through a governed tool or MCP connection. Databricks documents managed ingestion connectors for Salesforce and MCP options for agents; the actual design depends on the source, host, and approved platform choices. (Lakeflow Connect, Databricks MCP and agent tools)

That is not one connector task. It is a chain of decisions and handoffs:

One possible path starts with Salesforce CRM data. Databricks ingests and prepares it, then an approved AI tool or connector makes the relevant information available to the user.

Every arrow has an owner, an access model, a test, and a failure mode. If the project plan treats the whole chain as one task called “connect the data,” the missing work will surface late.

The questions I want answered before a pilot

What job is the assistant helping someone do?
“Summarize account health” needs a shared definition. Which account signals matter? How current must they be? Which sources are authoritative? What should the assistant say when information is missing or conflicting? The project needs a use case the team can test, not just a prompt that sounds impressive.

Whose permissions apply at each step?
A person’s access to a Salesforce record does not automatically answer what they should be able to see after data is ingested, transformed, and exposed to an AI tool. The team needs to agree on the downstream access rules and test them with users who have different permissions. “It worked for the admin” is not an access test.

What happens when the happy path breaks?
The pilot should check stale data, failed ingestion, denied access, incomplete records, timeouts, and unclear answers, not just the best-case question. Those cases help reveal whether the integration fails safely and whether users know what to do next.

These are technical questions, but they are also delivery decisions. They need the right owners in the room early: business and source owners, data and AI engineering, platform administrators, identity, security, privacy, and support.

Turn the unknowns into owned work

My job as a project manager is to make that chain manageable. I bring the teams together around a bounded use case, establish who owns each system and decision, sequence the dependencies, and make risks visible while there is still time to act.

I want a test plan that ties each important claim to evidence: the intended user can complete the task; access follows the approved rules; data freshness is known; errors are understandable; and the support team can diagnose a failure. If a decision or approval is on the critical path, it needs an owner and a date. It should not be buried in meeting minutes.

A successful demo is useful evidence. It is not a release gate by itself.

Adoption is part of readiness

Before a pilot, users need a short, honest guide. It should say what information the assistant can use, what the answer does and does not establish, how to check important details, and where to report a problem.

I prefer a focused walkthrough built around the real task. Let the team try an ordinary request, a request they should not have access to, and a case where the data is missing or old. That conversation gives users a useful starting point and gives the project team feedback they can act on.

The goal is not to teach people a new vocabulary. It is to help them use the approved capability with a clear understanding of its boundaries.

The question after the demo

After 25 years of leading projects, I still come back to a practical test: can the team name the data, the access owner, the evidence for readiness, and the person responsible when something goes wrong?

If not, the demo may be exciting, but the delivery plan is not finished.

That is the work between a promising AI connection and a pilot a team can use with confidence.