Implementing new software in a company takes time and effort. In the Life Sciences area, the IT organization needs to deal with the procedural controls and documentation needed to adhere to regulations associated with ensuring product quality and patient safety. Any IT system failure could have a potential impact on the quality of the product and in the worst case could even cause injury or death.
Validating your software means making sure it works in a way that it complies with related regulations and the defined user requirements for that software. This can be a laborious process. It is estimated that for some software implementations 80% of the time is spend on creating documentation rather than on software development. I would like to share some ideas that may help streamline project work and to reduce the effort:
Right-Size your project
- If the (application) change you want to deliver is big, consider a phased implementation approach. Focus on the most needed changes and implement those first, if possible.Ensure that all project constraints are defined to avoid scope creep. It must be clear what we want to achieve and this needs to be written down early on in the business case and the user requirements. This reduces the need to revisit the requirements.
Manage your resources
- Chart the areas where expertise is needed. The earlier this is recognized and the expertise is involved, the better.
- Segregate duties: Ideally, the person who is responsible for the planning and progress of the project is not the same person responsible for the quality. If there is no way to avoid this, a strong mechanism should be in place for quality reviews. An independent reviewer could help to improve quality on deliverables. This is where Quality Assurance should be involved.
- Ensure the business members in the team are involved and credited for their involvement in such a way that they have time reserved for the project, away from their daily operations.
- Communication should be timely, unambiguous and include all the necessary stakeholders. A plan should be made to define communication formats and involved parties.
- Limit the information to those that need to know. This also applies to whom you invite to meetings. For some team members, receiving the project minutes or presentation is enough information.
- Assign tasks to action holders and be clear about the due date and dependencies for each task.
- Everyone in the project team should strive to be constructive and set a ‘good example’. Convince your team members based on logical arguments and not on sentiments.
- If the solution is developed in an agile way, the documentation for that solution should be updated for each increment to avoid losing information. However these increments don’t need an official new document version.
- Well-defined requirements and rigid testing that these requirements are truly met are at the core of software development. Criteria for success of implementation should be defined so everyone knows what the expectations are.
- Pre-test your application before you go into user acceptance testing. This way you can avoid anomalies that slow down testing and often require (documented) fixes.
- For testing a risk-based approach should be taken. Focus on items that pose a high risk for compliance or security reasons and on those that have the most business impact. Low priority items may not need a documented test.
Procedures should support the following:
- Documents delivered during the project should avoid duplication of information.
- Scalability of the number of needed deliverables, and their extensiveness should be possible considering the risk and complexity of the system at hand. Simple systems should not need complex documentation
- Leanness is key. If a procedure is lean, people are more apt to follow it and there will be less need to capture deviations. Revisit your procedures and processes if you find that these frequently lead to the same type of issues.
- There is the literal procedure and the intent with which it was written. It should be OK to deviate from a plan if it means you are still compliant and if there is a good justification for it. Within a project, the justification for such a deviation can be worded in a Validation Summary Report.
- It is best to discuss these deviations with QA the moment they occur. Communication is key and involving influencers from within the company can help you to convince others. Keep in mind that logic should win in the end.
- When you have a deviation from the agreed process, the Corrective and Preventative Action (CAPA) procedure should only be used if it is really needed. The CAPA investigation can be very time-consuming. I have seen CAPA investigations started over changes where the issues were discovered by IT early on, before they went to production. So there was no real threat. It may be wise to invest in an alternative, more lightweight, procedure to investigate such issues.
- Synchronize the Service Management and Computer System Validation/System Development Lifecycle processes, as best as is possible. These frameworks are often developed separately creating gaps that must be filled by unnecessarily complicated work instructions and the accompanying documentation. Define and detail these processes on paper with a group of experts. A good moment would be before or immediately after the selection and implementation of a new Service Management System.
- An automated, record-based validation system rather than a (paper)document driven solution may be a good approach. Solutions exist where test cases are automatically traced as new requirements are created.
The above is meant to be a guide for everyone involved in software validation projects. It is not complete and you will need to consider the maturity level of the organization. Nevertheless, some of this advice can be followed no matter where you are. Procedural changes are often harder to achieve and are also dependent on company hierarchy and culture.