Inside a Consultant's Notebook: The First 90 Days After Go-Live
Go-live day isn't the finish line, it's mile one
Go-live tends to get treated as the milestone that matters most. The system is configured, the team is trained, and the project plan says “done”. What we've found again and again is that this is where a different kind of work naturally begins, that has less to do with the software and more to do with the scientists who now have to live with it.
Laboratory Informatics Consultant Amanda Kailher asked the team to walk through what actually happens in the 90 days following a system's go-live. Here are the takes of Laboratory Informatics Consultants Xandria Kovacic, Devan Shell, and Tahrima Jubery. As with our last installment, a few themes ran through every answer.
Days 1-14: Stabilization
The first two weeks reveal what training didn't catch. No matter how thorough the training and testing, the first two weeks will surface the questions nobody asked out loud. Xandria points out that scientists can be quiet during the training itself, nodding along or holding back the "wait, how do you…?" questions until they're actually working in the system alone, which is why having FAQ-style resources ready to go on day one matters just as much, if not more than the training itself.
Devan framed the pattern slightly differently: alongside training gaps, the first few weeks will surface a subtler kind of friction that isn't really about training. Breaking old habits takes real effort, even if someone understands the new process perfectly. As he put it, "even with thorough training, breaking away from previous methodologies can prove difficult”, a struggle our team, being scientists themselves, has recognized and lived firsthand.
Xandria and Devan both acknowledged that frustration will show up in the first two weeks, and they landed on the same response: empathize first, explain second, solve third. Devan added that even when a system is technically performing exactly as designed, the goal isn't to identify that; it's to understand the concern well enough to see whether a genuine enhancement is hiding inside it.
Day 15-45: Adoption Reality Checks
By weeks three through six, the questions shift from “does it work” to “is anyone not using it the way it was designed?” Devan's answer here points to a specific and recurring culprit: edge cases that got waved off during design because they “hardly ever happen”. If flexibility wasn't accounted for early in the data model design, those rare occurrences can quietly undermine the system's integrity. It’s a big enough risk that our team changed the way we design around it, deliberately bringing up the edge cases and ‘what ifs’ to weigh our options before go-live rather than after
Day 46-90: Optimization
By the final stretch, the job shifts again. From keeping the system stable to figuring out what’s actually worth changing or expanding. Xandria's approach starts with ROI and level of effort for each item, with an eye toward bundling small fixes together whenever possible.
Tahrima runs a similar calculation, but frames it as a sequence of questions: Is this blocking someone from doing their job? If so, it can’t wait. Is it a small, reversible tweak, or does it affect a validated workflow or data integrity, or require retraining? Is it affecting one person’s preference, or is it a pattern across multiple users? Configuration tweaks and multi-user issues tend to move fast; one person’s discomfort with a new workflow takes longer and more conversation to resolve. As she put it, a real part of the job is to hold clients back from "their own instinct to fix everything ASAP.”
What clients don't see coming
Ask any of the three consultants what surprises clients most, and the answers point in a similar direction: the finish line clients expect isn't real. Xandria notes that in R&D biotech especially, science keeps evolving, which means the system has to keep evolving with it long after go-live. Larger benefits of a transformation take time to surface as a new foundation settles in, even as the team works to deliver quick wins along the way.
Tahrima adds a layer that's easy to miss: adoption isn't a straight line. The first week tends to look fine because everyone is paying close attention. It's week four or five, once the novelty wears off, when old habits start creeping back in if reinforcement hasn't kept pace, which is also why clients underestimate how often the team has to re-explain the reasoning behind a decision long after it was made.
And when asked whether day 90 ever reveals something that should have been caught on day one, Xandria's answer is a clear yes: no amount of user acceptance testing catches everything, because that's simply human nature. The practical takeaway is to weight design effort toward the things that would be hardest to change later, so that whatever does slip through is easier to fix.
90 days is a short window in which to judge a system, but it's long enough to reveal its truth. The first two weeks tell us where training didn't fully land. The middle stretch tells us whether adoption is real or just polite. The final stretch is about knowing what to let go of and what to hand off. The systems are technical. Whether they succeed is human, and that's the work that continues long after go-live.
Interested in a system health check or ready to select and implement a new system? Reach out today to get the conversation started.
