When implementing a software system, the decisions made during the planning process impact the future for the lifetime of the system. With a heavy emphasis on the software selection, installation and implementation, Validation is often overlooked as a key and critical component. Here are some fundamental questions you should be asking yourself when implementing a new software:
- Which documents are necessary, and which are nice to have?
- Can all the validation tasks and activities be company driven and executed successfully?
- Will the validation be more successful if it is Vendor driven with key in-house participation?
- If there is a lack of qualified company resources, can this be successfully outsourced to a competent and proficient vendor/software partner?
- When seeking external resources, does the company have a solid reputation? Are they recognized as a Partner by the software vendor?
- What are the pitfalls if you contract for a validation package wrapped with a bow with little to no input from your company?
Consideration must be given to objectively evaluate the health of the SDLC process in place in your organization and determine if it is robust enough before the project begins. Resources must be evaluated for their time and expertise. Deciding when to invest in house and when to utilize a third party has become a critical business decision as limited resources must be diligently allocated to a wider range of needs. Third party companies are being actively leveraged across all stages of the system development lifecycle, from development to validation to launch. Below we explore a few of those scenarios, sharing experiences, and points to consider when making these critical decisions.
KEY ITEMS TO LOOK FOR WHEN SUPPLEMENTING YOUR INTERNAL TEAMS:
If your organization decides to outsource tasks and deliverables associated with your validation initiatives, ensure that the third-party resource’s team understands your business process. Other consideration includes items such as, do their resources have first-hand experience with your specific application or software? Do they provide qualified technical writers to author your documents? Are test cases electronically generated or mass produced based upon a mail-merge process and a standardized template?
Often low budget vendors rely on entry-level employees to keep their overhead and resource costs low. While it is common and cost effective to include a portion of ‘green resources’ with minor experience who can gain knowledge on the job under strict guidance, it is important that novices don’t constitute an overwhelming percentage of the project’s resources pool.
Ensure your third-party resource provides the desired level of industry experience among the resources assigned to your project. It’s important to request expertise as opposed to solely looking to augment your staff. Your externally sourced validation team should consist of professionals who can provide expert advice, understand the regulations of your sector as proficiently as the most competent Quality Associates in your organization. They must be familiar with and trained on the software being implemented. This is particularly critical when developing a mitigation plan for observations.
UNDERSTANDING THE PURPOSE AND VALUE OF YOUR VALIDATION DOCUMENTATION:
It’s important to remember that validation begins at the planning phase of the project, not at the end. Documents should not be produced merely because they are expected to exist in the package. It is critical to not only understand the purpose of each validation document but also understand where each comes into play during the process. It’s important to realize not all User Requirements may be met and have a comfortable way to explain this.
In our experience, we have witnessed both organization and Auditors that have found themselves confused when reviewing externally produced Validation documents created by validation teams that don’t have the experience to do it right. Here are some key questions to ask when evaluating externally sourced validation documentation:
- Just because a test step references a requirement, is it really testing that requirement?
- Are test steps written against the configuration or against the requirement?
- If a Functional Requirements Specification (FRS) is generated as the output of software already configured, is it really an FRS or is it just a ‘check in the box’ FRS?
- Is a late entry in a Risk Assessment document just an excuse for an omission due to time constraints?
- Under what circumstances should a Requirement legitimately be modified after Validation has begun?
- Does testing include negative testing scenarios?
- If there is no Test Plan, how can it be determined what is missing?
YOUR SYSTEMS ARE LIVE, BUT WHAT ABOUT YOUR VALIDATION PACKAGE?
Once the system goes live, the Validation is approved and the monitoring period is over, the Validation package is vaulted and forgotten, right? Absolutely not. Ask yourself, these key questions in reference to post go-live maintenance of validation:
- Who owns the Validation package, Quality or IT?
- Is it sustainable and easily updated? Who drives the Change Controls when updates are made to the system?
- Who supports/defends it in an Audit? Are these individuals comfortable with the documentation?
- What happens to institutional knowledge when the consultants leave, and the internal resources involved with the project move up in the company or leave?
- Is it acceptable to implement approved changes without updating your core Validation documents?
Thought must be given during the planning stage not only to the end product, but how easily it can be maintained, supported and updated. During development and execution, company representatives must be comfortable with the testing performed and able to communicate the rationale behind risk-based decisions. The package must be easy to update and re-execute as the system is modified. Most of all, it must provide the confidence to be easily explained and defended to Audit scrutiny.
As more companies are outsourcing their IM and IT departments and Quality units are stretched to their limits, partly because they are not revenue generating departments, it becomes critical to leverage skilled and experienced external expertise who can work with your team to provide industry guidance and fully dedicate their expert time and attention to your project documentation. Then, when an auditor requests a review of your system validation, you should feel confident to present and defend your entire validation package and the role of its components.