Setup and Implementation of Digital Validation Tools

• What neighbourhood has been identified for the build?
• How many people will be living in the house?
• What is the desired size and style of the house?
• What homebuilder has been identified to work with?

Similarly, a few additional things will need to be determined before starting to implement a DVT:

• What are the organization’s requirements?
• Who will own the system? Who will use the system?
• What information will need to flow into or out of the system?
• What system or product is desired for the DVT?

These considerations are outlined in more detail below.

Requirements

What are the organizational drivers for implementing a DVT? This could be any combination of efficiency, data integrity, visibility of data, metrics, standardization, cost savings, time savings, or other considerations specific to sites. It is important to understand these to define a clear business case for the company.

Who are the stakeholders that need to be onboard? This could be the validation or engineering departments responsible for delivering validation projects, quality team members responsible for oversight and approval of validation deliverables, documentation departments currently responsible for organizing and maintaining executed validation deliverables, compliance teams that are responsible for supporting regulatory and client audits / inspections, IT teams that are responsible for maintenance and support of the tool, etc. The list goes on!

Scope

The scope for DVT setup and implementation includes all the different uses planned for the system. One may think, “well, validation of course!” and he or she would be on the right track, but this is only the highest level of the true intended scope of the system. Think about the different validation programs an organization follows. This could be anything from commissioning and qualification of facilities and equipment, to process validation, method validation, cleaning validation, computer system validation/computer system assurance, etc. Organizations may see an opportunity to use their DVT to manage logbooks and general forms or to document changeover activities. Understanding the full breadth of the potential scope for the system will allow teams to both identify the scope of the initial implementation and plan for future expansion of the system.

User and Technology Landscape

As teams are developing the scope, they will want to evaluate and understand the potential user base and digital access strategy. Some questions to consider in this process include:

• How many team members are involved in the validation activities that will be included in the scope? The number of expected users can help determine which solutions can support one’s organization and will help determine the cost if there are license fees involved
• Are most of the expected users frequently involved in validation activities, or are they relatively infrequent users? Frequent users may be able to effectively use a complex tool, while infrequent users may need a more intuitive tool
• Are personnel familiar with the use of electronic systems, or will there be a steep learning curve for stepping into the digital world?
• What is the current digital state of the organization? Are there systems in place such as document management, entity management, testing tools? If there are, look for overlaps in functionality that will have to be evaluated and resolved.
• How will personnel access the DVT? Is there hardware for personnel that is appropriate to the areas in which the DVT will be used? Is there sufficient Wi-Fi or hardline access in these spaces?
• Is there an ownership model that includes both the digital team and the business area(s) that will be using the tool? Successful implementation will require effective sponsorship from within the owning business area and support from the digital team. This ownership model also plays directly into the governance model discussed below.

Processes to be Digitalized

The current state of the process(es) identified to implement in DVT is critical. The phrase “garbage in garbage out” is unpleasant but accurate. Digitalizing an inefficient, poorly designed, or non-compliant process will not inherently address any of those issues, but it is entirely possible that issues encountered after implementation will be incorrectly attributed to the design or use of the new electronic tool. Successful implementation of a DVT requires a robust business process with clearly defined requirements and templates. It is well worth the time and investment to optimize the process before beginning the digitalization process.

Electronic systems are based on a data structure and flow; DVTs are no exception. One must understand the data inputs and outputs that will be required to effectively execute and manage the in-scope programs and ensure the tool you select and the configuration you implement will support that data structure. Similarly, how this data must flow from system to system will help determine what kind of integration capabilities will be required.

Additional considerations that could affect your DVT selection criteria include information sharing and confidentiality requirements.

• Is there information or data that will be contained in the tool that is confidential?
• Will teams need to share information or data with third parties?
• Is the organization subject to additional controls due to governmental contracts?

Develop a Compelling Business Case

The above pre-work will provide the information required to develop a compelling business case to secure funding and resources and prioritize implementation of the DVT ahead of other competing initiatives within the company. One additional activity that needs to be completed in support of a business case is to identify anticipated savings associated with the efficiency and improved data integrity provided by the DVT. Data regarding the hours spent on impacted activities in the existing system or process will be needed along with an estimation of expected benefits.

Selecting the Product

Once a solid understanding of the organization’s current status and needs has been secured, the next task is to select the best product to meet those needs. Having user requirements documented can help drive an apples-to-apples comparison of the various tools that are available.

Consider the level of support needed from the supplier, including training support during implementation and ongoing technical support. A supplier that provides standard qualification, training and support materials can simplify future upgrades. It can be helpful to talk with existing customers to capture their experiences with a specific supplier.

Ensure the necessary technical and quality assessments and agreements are in place to support use. If using a Software-as-a-System (SaaS) solution, consider disaster recovery, agreements on acceptable downtime, response times to issues, and patching processes (notification and documentation).

Planning for Governance

Developing and implementing an effective governance model is a key step in the deployment of any digital system, especially one with as diverse a user base as a DVT. The goal is to create a light touch governance model that can provide consistency and effective change management without adding unnecessary levels of bureaucracy; after all, the goal is to improve efficiency!

One of the most important roles of system governance is to ensure that the system is implemented consistently across sites, including the adoption of consistent processes and terminology. This is especially important if the organization intends to utilize reporting data effectively or share information across the business. Some activities that can support consistent implementation include defining the dos and don’ts for the tool, enforcing the intended use and scope, and enabling a streamlined approach to change management.

• The scope of the DVT (the processes to be digitalized as well as the deployment user base) will impact ongoing funding requirements and so will need agreement and support at a senior level
• The terminology to be used, such as naming and numbering conventions, can be agreed at a lower level within the organization. Where possible adopt terminology used by the designated supplier as this will help when utilizing their supporting training material or documentation.

The Team

Effective governance of a DVT can require involvement from several different groups. Actively identifying and engaging the right team members early in the implementation process, as well as ensuring the team is scaled appropriately for the solution and organization, can increase the odds of effectively managing and maintaining the tool post-adoption.

Sponsors and Stakeholders: Senior stakeholder (or sponsor) engagement, especially from the System Owner and Business Process Owner, and the IT and quality teams, is required to deliver at speed. These stakeholders will need to be clear on the expected scope and timing of initial deployment (and any subsequent changes) and be prepared to intervene to ensure these are met.

Project Team: The project team has the primary responsibility for delivering the chosen solution, required supporting documentation and training materials during initial implementation. This team will typically include the IT function in addition to the functions directly supporting deployment (engineering, validation, quality, etc.); the supplier may also be considered part of the project team. It is important that those supporting deployment understand the process that is being digitalized, and the capabilities and limitations of the tool being deployed. If possible, engaging members of the initial project team in the ongoing governance team is valuable as they will bring a wealth of knowledge and experience. These individuals can provide continuity during the transition from implementation to “business as usual” operations.

Site Deployment Champions: Engaging early adopters of the tool to act as champions of the deployment process will be key to early implementation success. Where sites have legacy ways of working a single point of contact is useful to address changes to these ways of working.

Users: Creating a community of practice (CoP) as soon as the tool is deployed is helpful. This forum enables the governance team to communicate changes and facilitate the sharing of lessons learned among the user base. Early adopters sharing the benefits they have seen is often more compelling than presentations from a central team.

Central Control versus Local Control

Part of defining the governance model is determining what kind of structure will work best for the company. Is the team looking to drive a standardised process across multiple sites? Or is the goal to provide a flexible tool that can allow sites to adapt and develop their own processes? The answer to this question can help determine if the organization will benefit most from a centralized or a localized governance model.

Managing Change

As soon as the team has deployed the solution, requests will undoubtedly surface to change it; therefore, it is critical to have a process in place to manage this change. This process should be able to handle both relatively infrequent IT changes driven by the supplier (such as patches or version upgrades) and more frequent requests for change to content made by users (such as new templates or changes to existing templates).

Risk management can minimize this burden. Clarify what is considered IT change control versus what is considered content configuration change management (such as templates); understanding if and where these changes intersect with GxP change control is critical for maintaining compliance. The level of oversight appropriate for the creation or changes to templates must be defined, along with how these changes will be communicated. Leveraging the existing company processes for IT changes and GxP changes wherever possible will help standardize activities for users and will avoid creation of redundant processes.

Implementation

The implementation process for a new DVT has a huge influence on how well (or how poorly) the tool will be adopted by the end users. Giving the implementation process the same level of care and attention that you put into configuring the tool and developing your content will pay off in the long run.

Rollout Plan

The company’s size, structure, and governance approach will impact the deployment methodology, including whether the organization will approach this as a top-down (globally driven) implementation or a bottom-up (site-driven) implementation.

If the intention is to change ways of working at the same time as deploying a DVT, this should be made clear to stakeholders early and often as this will require additional management and can potentially slow deployment.

It is important to pick the right site(s) for the first deployment. (Large organizations would ideally identify multiple lead sites). The first site(s) to deploy should be able to provide feedback to the project team on what works and what doesn’t and act as advocates to the following sites.

It is best to have a plan for active change management across in the business, both as part of the initial implementation and as a means of responding to other changes within the overall organization. Validation is an area with multiple stakeholders and established procedural ways of working. Implementing a DVT within this area represents a change project where clear communication is key and recognition for those who embrace the change is required. Offering users clear benefits from the change, and compassionately addressing fears or pain points associated with the change can improve the odds that users embrace the new tool.

Identifying and engaging the right site deployment champions is crucial as they gain buy-in from the site teams. The quickest deployments with reduced ongoing support needs are seen where these site deployment champions are fully engaged and “own” the deployment.

It’s useful to start with an initial (or pilot) project for each site or workstream to build capability and shakeout any issues before full deployment. This gives everyone confidence and any site peculiarities are highlighted. This is not an opportunity to delay implementation; rather, it is recommend that clear cutover dates be set to prevent deployment drift which allows the extension of traditionally more comfortable legacy ways of working.

It is further recommended that teams keep templates simple at first and building on these as the implications of added complexity is better understood.

Tracking Benefits

A DVT will provide a lot more information than teams will have had available when utilizing paper. Teams will be able to see the number of documents approved, the approval times, the number of issues raised, what is pending approval, and who needs support to clear a backlog, just to name a few. It is unlikely this information had previously been available, but the more legacy data teams have, the easier it will be to quantify benefits. Often user feedback will simply be an anecdotal estimate based on similar past projects using paper.

Deployment Approach

Communicate clearly to sites the deployment steps and responsibilities. A standard deployment plan and tracker will give sites certainty over roles and expectations, and the ability to plan their project staffing effectively. Regular meetings during the deployment phase will keep the deployment on track.

If common templates are used, deployment will focus on user identification and training. The deployment will be more complex if the sites are setting up their own processes (See Example 2 in Governance Models above).

Training

Role-specific training will minimize training time required for the average user. It is recommended to utilize standard supplier training material (videos and guides) wherever possible, as this will minimize work for the project team when new versions of the software are released.

Any company-specific training material should be able to be delivered by local SMEs if the organization has selected a sufficiently intuitive tool. Minimize the time between training and first use during deployment wherever possible.

Providing access to a training environment for users during deployment and training allows users to find their way without fear.

Post Implementation Review

After all the work to implement the DVT is complete, it may tempting to extend congratulations on a job well done and head into the next major project. Not just yet! There is one more step to take – a post-implementation review. This kind of review is critical to demonstrate how the implementation of the project has benefitted the organization, and to determine where further work is needed to alleviate pain points or maximize efficiencies.

• Return on investment should be expected in year one. Benefits should be tracked in the early phases of deployment
• Consider what you will track from the start. Use a simple form for each initial project to capture feedback
• Identify savings in activity total duration as well as work hours consumed. Earlier completion dates are often the most significant as testing can be reviewed as it progresses and in parallel rather than in series upon completion as with a paper process
• If teams have taken the opportunity to simplify their processes when digitalizing, it is recommended that teams attempt to quantify the benefits associated with this simplification—all efficiencies will not be linked to the digitalized change
• Once implementation is complete teams will have access to data such as the number of documents approved and review and testing durations. This new data should be incorporated into routine system review processes and fed back to the governance team as indicators of ongoing system health

Conclusion

Implementation of a DVT involves planning, communication, execution, and likely some hard conversations as teams work to improve and digitalize their organization’s validation processes. The benefits of a well-planned and well-executed implementation process will however vastly outweigh the comfort of “doing what has always been done.” Taking some time to reflect on the overall project, the successes and lessons learned, and celebrating with both the project team and the user base can bring a sense of accomplishment and satisfaction. Reporting those improved metrics to the leadership team is always a wonderful way to highlight the project’s success!