Assess a New Research Center Before Copying a Pilot Setup

A center director calls you a week after a strong pilot readout and asks for a quick expansion to a second research group. The data looked clean, the pilot lab liked the platform, and copying the same setup feels like the fast path. You should not dampen that enthusiasm, but you do need to treat the new group as its own decision. A different lab often has different sample intake, different users, and different support needs, and none of that gets resolved by reusing a pilot file.

Why This Conversation Goes Wrong

Directors think in outcomes, not workflows. From where they sit, the pilot proved the platform works, so extending it looks like a formality. You know better, because you have seen how much of a pilot's success depends on details that never make it into the summary slide, things like who submits samples, how many hands touch a result before it reaches a scientist, and what the support team already knows about that specific lab.

The failure mode is predictable. You agree to move fast, someone copies the pilot configuration, and the new group hits a wall in week one because their samples arrive through a shared repository instead of direct bench submission, or their users are core lab technicians instead of principal investigators, or their idea of readiness has nothing to do with the metrics the pilot tracked. Now you are troubleshooting a rollout instead of running one, and the director who pushed for speed is the same person asking why it broke.

How to Prepare Before the Call

Before you agree to anything, pull the real facts from the pilot. Write down how samples entered the workflow, who the daily users were, what training they needed, and how the customer defined success. You need this list not to defend the pilot but to compare it honestly against the new group.

Then find out who actually owns the new group's workflow decisions. A center director often speaks for a lab without being the person who controls sample handling, user access, or acceptance sign off. If you skip this step, you end up scoping a rollout with someone who cannot commit the people who matter. This is the same problem covered in Map Collaborator Decision Roles in a Shared Research Evaluationand the habit applies here just as much as it does in a formal evaluation. Ask the director directly who leads the new group's workflow, who supports it day to day, and whether anyone outside the lab, like a core facility or a sample repository, has a hand in it.

Before you get on a call, request a short list of contacts. You want the lab lead and whoever owns support for that group. Do not schedule a rollout date until you have talked to both.

What to Say

The director opens with, "Can we just copy the pilot setup for the new group. It worked well there and I want to keep the momentum going."

You answer, "I want to keep that momentum too, but the pilot answers questions for one lab, not for this one. Before we talk about a rollout date, I need to understand how their samples arrive, who will use the platform every day, and what they will use to decide it is working. Who owns their workflow, and can we set up a short session with their lab lead and support contact this week."

The director says, "Fair point. Their samples actually come in through the central repository, not straight from the bench like the pilot lab. I can bring in the repository coordinator."

You respond, "Good, that is exactly the kind of difference we need on the table before we scope anything. Let us hold a short assessment with the repository coordinator and their lab lead. We will compare workflow entry point, user group, training needs, and their acceptance criteria against what we saw in the pilot, then build a plan around what we actually find."

Notice what happened in that exchange. You did not say no, and you did not slow things down without reason. You gave the director a concrete next step, named the people who need to be in the room, and kept ownership of the assessment instead of letting the request turn into an instant commitment.

Mistakes to Avoid

A few habits sink this conversation even when the intent is good.

1. Treating the pilot as proof rather than as one data point. A single successful pilot tells you the platform can work somewhere, not that it will work everywhere.
2. Agreeing to a timeline before anyone has talked to the new group's support contact. Support gaps show up fast once real users start relying on the system.
3. Letting the director's excitement set the scope. Directors are optimizing for speed and visibility, and that is a fine thing for them to want, but your job is to make sure the plan holds up once people start using it.
4. Skipping the question of who owns acceptance. If nobody has agreed on what readiness looks like for the new group, you will find out the hard way, usually after launch.
5. Assuming similarity because two groups sit under the same center. Shared leadership does not mean shared workflow.

If a mismatch does surface after rollout starts, you want a plan for handling it without letting the account relationship take the hit, which is exactly the situation addressed in Coordinate an Account Communication Escalation During a Research Disruption.

How to Practice and Score It

This conversation rewards a specific skill, asking good questions under pressure to agree quickly, and it is worth rehearsing before it happens with a real director. Build a comparison sheet with two columns, one for the pilot and one for the proposed expansion. Fill in workflow entry point, user group, training needs, support dependencies, and the evidence the customer will accept as proof of readiness. Practicing against that sheet forces you to ask about the parts of the new group's workflow that a pilot summary never covers.

DealSpeak works well for this kind of rehearsal because it lets you run the conversation against an AI director who pushes for the fast path, the same way a real one will, and it scores how you responded. A manager reviewing the session should look for three things. Did the learner ask about sample intake and users before discussing a rollout date. Did the learner name a specific next step, like a scoped assessment, instead of a vague promise to look into it. Did the learner identify who owns the new group's workflow and get that person into the conversation. A learner who copies the pilot setup on request, without asking a single question about the new group, should score poorly no matter how confident they sounded doing it.

Run this scenario more than once, and vary the difference between pilot and expansion each time, a different sample source, a different user type, a different support model. The goal is not to memorize one script but to build the reflex of asking before agreeing.

A pilot proves a platform can work once. It does not prove a second group is ready, and treating those as the same thing is where good rollouts start to slip. If you want more scenarios built around exactly this kind of judgment call, the Biotechnology practice conversations library has more to work through.