3 common pain points and how to avoid them. As I explored recently, digital transformation can surface a series of perplexing data challenges for most organizations, but particularly those operating in life sciences. Such has been the inertia in the sector previously around system modernization that, when a project is finally approved and chartered, stakeholders often rush toward the benefits without looking back. This can result in disappointment and frustration when the ‘as is’ data migrated to the new set-up turns out to be in a poor state and largely unusable.
In this blog, I want to focus on 3 particular takeaways from such experiences which companies can extrapolate from to avoid making the same mistakes.
1. Technology is just one piece of the puzzle in a successful system migration
The successful execution of any project involves equal focus on people, process, and technology, so that everything is aligned to deliver the expected outcomes. Certainly, it’s as important to line up sufficient resources to plan and manage the transition, and to build engagement and momentum among all stakeholders and users, as well as any new skills and resources they might need.
But another element that’s often neglected is the data the new system will draw on to deliver the expected process streamlining, and improved visibility. However fast and feature-rich the new technology platform, if it’s dependent on old and inadequate data quality it won’t be able to fulfill its promise. If the new system can’t fulfil future-state governance or meet new standards for regulatory compliance, then the ‘retro-fitting’ burden could be immense as teams try to massage and improve the data after the fact. Unplanned data enrichment is hugely time-consuming.
The lesson here is about scoping system projects thoroughly and planning them early enough so that every dimension is well catered for in plenty of time.
If delivery is scheduled close to a deadline for adhering to new health authority submissions standards, companies will want to be sure that the data coming across is in good shape and fit for purpose to allow that deadline to be confidently met. Filling CMC Module III in eCTD submissions is already a hot spot, highlighting where existing system data typically falls short. Companies can learn from this by doing their due diligence and performing a detailed data assessment up front, to help them mitigate these kinds of risks.
2. Time & resources are critical success factors
Unless a project has a sufficient runway leading up to it, pressures will mount, and good intentions are likely to give way to compromise and the cutting of corners. Even if they plan to bring in external help, the key project stakeholders will need to set aside their own people’s time to do the vital groundwork. That’s in understanding old and new data governance parameters, so that any data preparations and actual data migration is in line with current and emerging requirements. Without those parameters, and a clear picture of the ‘as is’ status, project teams risk investing their time and budgets in the wrong places and setting themselves up for a big clean-up operation later on post migration.
So, even before performing a data quality assessment, it’s a good idea to seek a bit of preliminary strategy advice from a trusted expert – almost as a Phase 0 – to understand the bigger picture and how everything needs to align to deliver against it.
This isn’t about engaging specialists prematurely, but rather about making sure that any investment that follows (and any external help brought in) is well targeted, so delivering maximum value.
3. It’s important to allow and plan for failure
Despite the best intentions, projects can go awry due to the many moving parts that make up the whole. So, it’s important to factor ‘the unexpected’ into all planning.
This includes allowing for a certain number of iterations based on the finding of data quality assessments, to get the data to fit the required data governance standards going forward. If the data coming across is in a disastrous state, a planned migration phase duration could quickly turn into a material schedule delay. Underestimating the work involved is very common. I have seen this in many client projects. For example, if the ‘happy path’, where everything goes to plan, was expected to take 10-12 months, the real-life route situation took 18 months– so to de-risk the project, allow for contingency. If in doubt, take the forecast number of days and double it.
All of the preparatory work recommended above should help contain delays and protect against timescale or budget shocks, but it’s better to plan properly so that the journey goes as smoothly as it can. Although, ultimately, the client company is responsible for the quality and integrity of its own data, technology vendors and service providers will need to plan their involvement too and ensure they have the right skilled resources available at the right time.
Our experts can provide guidance on all of the above. Ultimately, this is about setting the right expectations and a realistic schedule, and resourcing projects so that they optimize the time to value. A little foresight can go a long way.
To discuss your own data migration journey, please fill out this contact form and we’ll put you in touch with our experts.