Inside a Consultant's Notebook: What We Learn in the First Week with a Biotech

The kickoff call gives us a problem to solve. The first week tells us what the problem actually is.

---

Across every type of engagement, whether it’s an evaluation, selection, implementation, etc., we begin with a defined scope and a summary of the problem that the client wants to solve. When we meet the team, read the room, and start to see the distance between how a lab was described and how it actually runs, that's when we can actually start digging into the what and how of the problem we’re there to solve.

KC Laboratory Informatics Consultant Amanda Kailher asked the team what they look for, what they find, and what tips them off in those early days. Here are the takes of founder Talia Karchem and Laboratory Informatics Consultants Xandria Kovacic, Caitlin Tormey, Felicia Loi, and Brinda Kamalia. Four themes ran through nearly every answer. 

The first thing we ask for isn’t about the software

Before we log in to a single ELN/LIMS, we ask for an org chart, process diagrams, and communication channels. It sounds purely administrative, but it’s the fastest way for us to understand the two things that determine everything downstream: who the key users are, and where work will actually take place. 

For Talia Karchem, founder of Karchem Consulting, process diagrams are the fast-track to spotting “where critical handoffs occur, what bottlenecks might exist, and where we can add efficiencies. Comparing an org chart against the actual user list in the ELN or LIMS does something more subtle. As one consultant put it, even in a small company, that "who's who" helps identify who might become the Superuser or Champion of the changes we make later on, the internal advocate every successful rollout depends on.

Just as often, that person is not the one on the scoping call. Several of the team noted how quickly you learn to read past job titles to find the true subject-matter expert: the person who, in Brinda’s words, "keeps the lab running." Identifying them early tells us who to design around.

The stated problem/reason we’re brought on board is the tip of the iceberg

The issue a client brings us is real. It is also, almost always, only part of the picture. We find that the problem a team names is usually a small piece of the puzzle, with "three to five missing pieces you need to find and address before you can even start fixing the problem the client actually asked about."

Talia describes the same pattern from the other direction: something is always missing. Sometimes it is a pain point that never surfaced during scoping; sometimes it is an integration so routine that stakeholders forgot to mention it. In more than one case, entire groups of users were left out of early conversations entirely: their existence was discovered only after the team spotted their entries in the system.

None of this is a failure on the client's part. The people closest to a system stop seeing the workarounds they rely on every day. Surfacing those pieces before they become surprises is part of what we are there to do.

How a system is documented is rarely how it’s used

The gap between the documented workflow and the real one is where most of the rework lives, and it announces itself in small tells. For Talia, one of the clearest is missing structured data: if a client hands over a process diagram but there is no structured data behind each step, that is a red flag. The information almost always exists somewhere; the real questions are where, and how much effort it will take to store it correctly.

Environments tell a similar story. Clients may insist that their Dev, Test, and Prod environments are in sync, but, as Xandria notes, discrepancies usually do not surface until the first system change. And then there is the language itself. Felicia offered a warning that got knowing laughs from the rest of the team: be wary of a client's definition of "straightforward," which tends to arrive with multiple exceptions, legacy data, and a "simple" spreadsheet running to a dozen tabs.

When documentation and reality disagree, reality wins. Our job is to find where the truth is actually stored.

Adoption is a human challenge before it’s a technical one

You can build a flawless end-to-end workflow and still watch it stall. As one of our consultants put it, when the pressure is on it is faster to jot notes down and enter them later than to follow a full workflow in real time, and "if a workflow doesn't account for the shortcuts people take when things get hectic, adoption will stall." The lesson the team keeps returning to is to meet users where they are and make the desired workflow the path of least resistance, rather than aiming for a configuration that is perfect on paper and unused in practice.

Talia frames the same principle in terms of friction: if it takes more time to enter data than to generate it, something is wrong. It should not be a scientist's job to master every corner of the software; they need someone who can point them in the right direction and help them use the tools well.

The human challenge extends to the people we report to, not just the people at the bench. Caitlin pointed to how much “being in the weeds” each stakeholder wants: some are after high-level updates, lonely, while others want every detail and the reasoning behind each configuration decision. Figuring out that preference quickly, she notes, is important for building trust, which ultimately carries a project through the harder decisions later on. 

That is the throughline of the whole first week. The systems are technical. Whether they succeed is human. We are there to make the right path the easy one, so that good documentation becomes a byproduct of good science rather than a tax on it. Interested in a system health check or ready to select and implement a new software? Reach out today to get the conversation started.