How Should We Staff Regulatory Operations Teams? A Strategic Perspective
Let’s face it – resourcing for Regulatory Operations is hard. Really hard. Having worked in organizations of various size during my tenure in life sciences, I can honestly say that there is no mathematical formula, no algorithm, nor any other sort of objective measurement to best determine how to resource internally. I wish it already existed because it would make budget forecasting much easier. Accounting for peaks and valleys of various activities, more often than not in parallel with other programs, is only one aspect of determining the most efficient makeup of your Regulatory Operations team. And, to be honest, that’s a completely different conversation altogether. But, having ‘fought in the trenches’ with some of the most outstanding colleagues spanning many functional groups during my career has refined my perspective on internal operations staffing and related strategy behind best practices. Not so much the ‘how many,’ but the ‘who.’
From the perspective of smaller, start-up pharma and biotechnology organizations, there are so many unknowns that ultimately affect corporate strategy and goals. This leads to constant shifts in priority, sometimes on a weekly basis. It’s simply the nature of the industry, and there is no escaping it. Instead of trying to fight against the grain, we must accept the single truth that affects all of our operations teams regardless of our separate corporate goals: When submissions must get out the door… they must get out the door.
So, how can we accomplish this while integrating our unique role, one whose function has evolved substantially over the past ten to fifteen years, into the overall framework of drug development strategy? It starts by taking a hard look at three key elements that we can help quantify and interpret our understanding of the inner workings of organizational process, technology and cross-functional relationships. These elements include quantifying the submission load, selecting the right technology, and determining the scope of practice.
Quantifying the Submission Load
One of the first steps is to gain the bird’s eye view of your current and planned submission applications. Accounting for major original filings, amendments, supplements and variations alongside these applications in the maintenance phase is a seemingly reasonable activity, but it’s surprising how many organizations skip this crucial step of baseline regulatory informatics. This is often overlooked due to resourcing constraints or a lack of understanding of potential value obtained from this exercise. Parsing out how many submissions each application consists of on a weekly, monthly and quarterly basis – coupled with the estimated effort values (hours or other KPIs) required to complete each – is a critical step in determining your current and potential future submission volume. Factoring for different application types, regulatory commitments, annual and regional reporting requirements among other aspects can establish the baseline of effort required to manage your entire application portfolio. I highly recommend leveraging tools such as pivot tables to stratify these data best as the ability to filter, slice and manipulate based on different variables is key to understanding your applications.
One common issue is only thinking (and subsequently working) submission to submission without trying to grasp the big picture. This leads to shortsightedness and tends to negatively influence long-term planning efforts. Leveraging metrics related to organizational, product and application trends helps calculate these measurable effort levels that assist in much more than just resourcing strategy. Visualizing these metrics best illustrates what you have already accomplished and what is potentially beyond the horizon while justifying resource levels at the same time.
Selecting the Right (Sized) Technology
Smaller organizations are simply strapped for resources. It can be very difficult to secure budget to support the technology requirements of a full operations staff. Costs to onboard an entire suite of tools to support submissions may by unobtainable, especially when IT resources are limited or exist solely for core technical support. IT Infrastructure simply doesn’t exist as budget line items to support a full systems model for many small organizations when accounting for system implementation, validation and maintenance (not to mention that these are full-time jobs). Thankfully, Software as a Service (SaaS) solutions have become ever-increasingly commonplace and reduce the burden of onboarding critical systems. Coupled with more easily justified costs such as authoring templates and PDF publishing tools, operations teams can quickly ramp up to support, lead and engineer processes that would simply be out of reach without the use of the cloud. Additionally, the decentralized approach to systems management is gaining much steam, especially within the regulatory arena. Embedded systems specialists within functional groups can best manage technology requirements and tools which ultimately supports critical timelines and corporate goals. These individuals should possess both expansive systems backgrounds alongside a fundamental understanding of regulatory processes to make the most gains.
Personally, I gravitate towards a robust and scalable Content Management System that is capable of handling both documentation and information as the first major capital expense beyond core IT. Supporting content within regulatory, clinical, quality and adjacent functional areas pays for itself many times over when implemented correctly and for the right reasons. As a bonus, coauthoring and review tools that integrate easily with content management solutions can amount to a huge boon for overall efficiency. Specific to submission building, I tend to stray away from bringing eCTD compilation activities in-house for smaller organizations. The right cloud tools exist within this space, but it’s the increase in functional scope that tends to worry me from a resourcing perspective. Will you onboard FTEs or contractors specific to this role? What if there isn’t enough work? What if it turns out your team simply can’t handle the submission load due to unforeseen circumstances? These are some of the most difficult variables to consider and account for which leads me to offload the primary eCTD compilation to a vendor with flexible resourcing prebuilt into their operating model.
By implementing key systems to support baseline operations activities, organizations gain incredible value and control over content (consisting of both documentation and information) at reduced costs over time.
Determining the Scope of Practice
As mentioned above, the role of Regulatory Operations changed dramatically over the past decade and a half. I once believed there was a stigma related to the field because of the perception that the role was relegated to hyperlinks, bookmarks and more hyperlinks. Yes, we have our share of navigation to manage, but this pales in comparison to the strategic advantage a RegOps group can offer if built correctly. The potential is only unlocked when we step back and look at the various touchpoints that exist between RegOps and numerous other functional groups. It’s not a far leap to change our paradigm of thought from solely document publishing and submission (what I would consider ‘classic’ RegOps) to that of Regulatory Informatics, Operations and Technology. Taking a step even further back, it’s easy to attach standalone functional modules such as Regulatory Business Operations, Vendor Management, Regulatory Project Management and elements of Regulatory Intelligence & Research. Fulfilling every role listed above isn’t likely. But, choosing from related disciplines can form an operational core that can expand strategically over time. A simple ranking exercise of each potential function helps prioritize the two to four that makes the most sense right out of the gate both within the Regulatory department framework and organization as a whole. There is incredible untapped potential for smaller organizations who allow RegOps groups to organically grow with the right amount of seeding.
I have found an efficient starting combination is to perform document-level publishing in-house alongside authoring support (template usage) coupled with content management (CMS or eDMS) and higher-level submission management. This lends itself to a nice mix of classic operations, informatics (think document management & metrics) and technology management. This model tends to mitigate the endless back and forth between the sponsor and publishing vendor during ‘deep publishing’ while adequate ensuring version control and utilizing powerful CMS tools. Additionally, direct relationships with content generators internally allow for a more efficient workflow from an approved document (content) to one that is submission-ready. When document issues arise, it’s much easier to work with allies within functional groups than effectively become the middleman between your vendors and authors – it’s an unnecessarily challenging and time-consuming position to find oneself in. This also tends to support critical timelines while offloading the heavy submission compilation to your vendor. You will still participate and most likely lead submission management, but harking back to the points regarding technology, there simply isn’t time to manage GxP-heavy systems that require complex IT infrastructure alongside additional submission publishing resources. The most important point is that this will change over time as new functional modules are either picked up or dropped based on various needs. Remaining flexible in this respect is as important as being able to adapt to the ever changing direction of company strategy and goals.
This leads us right back to our primary question – how do we staff an operations group? Selecting the right level of expertise in-house becomes much easier once we’ve determined the estimated submission load, technology onboarding and possible scope of practice. Initially, individuals must be those within the experienced ranks of what the planned core operational function. But, it is not ideal to load up on one ‘pillar’ over others. The group will need to be nimble, cross-trained and bring critical ancillary skills to the table.
Document publishers may lend themselves for business analysis activities based on previous roles and education. Systems and technology managers with backgrounds in quality and training might be rare, but exceptionally impactful for onboarding and audit-readiness. A project manager who has hacked away at a large filing until the early morning hours (on multiple occasions) probably has picked up some amazing soft skills such as negotiation, emotional intelligence and up-managing. Ultimately, the staff will need to become functional chimeras – hybrid experts in your current and future scope of practice to succeed as a team, group and department.
Keeping an open mind when filling these critical roles is critical to continued success. Here’s my recommendation - slot an individual for 60% of their core proficiency and leave 40% for innovation. This method allows you to best develop star staff members over time and avoid the common pitfall of placing individuals into functional siloes. If you want team members to stick around, allow them to help develop their ‘reach goals’ and be constantly challenged! This is the secret to being strategic, remaining relevant and perhaps even becoming industry trail-blazers.
Join MassBio’s HR Working Group and MassBioEd on January 26th for its Forum on this topic – Regulatory Affairs: Find, Hire, Retain will be a lively and interactive discussion on the challenges of regulatory affairs hiring and best practices in the training, retention, and ongoing professional development of incumbent workers.
Guest postings on the MassBio blog in no way represent the opinions or endorsement of MassBio or its officers, directors, employees, agents and/or consultants. MassBio does not represent or guarantee the truthfulness, accuracy or reliability of statements or facts posted under the guest postings on the MassBio blog. MassBio accepts no liability for errors, omissions or representations. The copyright of guest content belongs to the author and any liability with regard to infringement or intellectual property remains with the author.