In this article, I will go through some of the considerations a pharmaceutical, or otherwise regulated, company should go through before selecting a software vendor.
First a little about my background. I have a Master Degree in Software Engineering and have been developing validated GxP software for the last 11 years. During that time, I have gained extensive experience as a consultant for companies buying or validating software. I have been involved in everything from validating spreadsheets to being project manager for the validation process of a cloud-based QMS system. I consider myself to have a solid background regarding this subject – and, most importantly, experience from both sides of the table.
In my opinion, bad requirements leads to bad software. Good requirements leads to much greater chance of a successful software project. Therefore the requirements are very important, so lets talk a little about requirements.
The quest for software usually, and hopefully, starts with a need within the organization. Based on this need, ideas start to form and soon after new needs arise. At some point a set of requirements are written for the software.
I have seen companies where one person sits down in front of a PC and writes all the requirements alone. This will often produce a list of requirements with a lot of gaps, misunderstood functionality and a one-sided focus – and that often turns into a disaster of a system.
I have also seen companies where every employee, external consultants, partners or anyone else just remotely associated with the process, are asked for requirements and opinions. Everything is then combined into a huge list and provided to the vendor. It is needles to say that such software most likely doesn’t exist and the development costs would exceed the value of the system by a huge margin.
The optimal way of writing requirements is by compiling a combined list of requirements from all parties directly affected by the system. Then assemble a small group of max. 5 people to sort through the requirements and rewrite as needed. Each requirement should then be evaluated carefully with regards to necessity. Do this by ranking them where the highest rank is a deal-breaker and the lowest ranking is just an annoyance if not included in the software. When developing software, a rule of thumb is that 20% of the requirements cost 80% of the money. So the more realistic and flexible the requirements are, the bigger are the chances of getting a system with a decent return of investment.
Another important aspect regarding requirements: Specify what you want, not how it should be implemented. Of course there are exceptions to this, but consider the following two requirement descriptions
- The background in the testing environment must be red on all pages
- The testing environment must be clearly distinguishable from the production environment to avoid mistakenly using the incorrect environment.
The two requirements essentially solves the same problem, but the first one dictates how it should be implemented.
A requirement I often encounter, are “Should integrate with SAP”. This requirement is extremely vague. It could mean polling an SAP server to verify it is still running, or it could mean a dynamic interface where the customer can define their own integration logic.
It is very important to be as precise as possible, especially with regards to integration as it can affect both the price and the match in a very high degree.
When writing a requirement regarding integration, specify what should be achieved by the integration and specify which product should initiate the communication and if data is going in or out of the system. If a description of the interface for the system exists, include it in the requirement.
It is also important to realize that even integration to well known systems can become a time consuming task. Many systems, especially frameworks like SAP, can be configured and used in many different ways – so chances are high that the integration needs to be custom developed even thou it is a standard system.
It should also be noted that data retrieved from a non-validated system will not become validated just because it enters a validated system.
Custom product vs. off-the-shelf product
When all the requirements are defined, it is time to find a match. It will likely involve talking with a lot of vendors that present their product – you might even send them your requirements so they can supply an answer for them.
If you encounter a situation where none of the vendors meet your requirements – carefully reconsider your requirements again based on the knowledge gained during the process. You might be in a unique situation where custom software is needed – but quite often it just means your requirements are too rigid or that you want to do too much in one system.
Also consider carefully if a vendor system is considered Category 4 or Category 5 according to GAMP5. This will affect the validation costs – both for the initial validation and for future updates and changes. Some well known QMS systems will tell you they are Category 4 – but the fact is that the templates for e.g. Change Control are custom coded – not configured. Which requires a completely different level of validation. So make sure to make your own assessment regarding this.
In-house development or external development
If you end up with a custom development project, or a project based on a framework that requires customization. It is likely that someone within the organization, probably someone from IT, will tell you that its much easier, cheaper and flexible to develop in-house. This is very rarely true. Primarily for the following three reasons:
- Development project require a huge amount of man-hours – are those kind of resources available in-house or would you need to hire a new team? If you need to hire a team, are they already experienced with GxP and are they even available in your location? Hiring 10 or 20 developers with a special skill-set can be difficult.
- They will probably suggest to implement it in SharePoint, SAP or another framework – is that system validated? You cannot have a validated system running within a non-validated environment – and are you interested in validating the corporate SAP installation along with all its future updates?
- Does you company have prior experience with this kind of development? If so, how did it go?
I am not saying it can’t be done internally – but more often than not, it fails or becomes incredibly expensive.
If you are looking at an external development project – make sure you have dedicated project management resources on your end to follow up on the development, handle contracts e.g. An external project can also go awry – but if your contracts are in order, then you are not the one paying for it.
Audit before selecting supplier – also internal audits
Whether developing internally or externally – make sure you do a thorough audit before settling on that vendor. At the very minimum, ensure that:
- Their validation documentation actually lives up to your demands so you can base your validation on their validation. This will save you a lot of time and money.
- They have proper SOPs both for development, release management, update management and change management.
- They have proper and documented training of employees
- That you have some kind of fail-safe if the company goes bankrupt or is acquired by a competitor.
I hope you enjoyed this article. It ended up being a lot longer than anticipated, but I guess that I just had a lot on my chest