In life sciences, we have systems subject to 21 CFR Part 11 and therefore subject to computer validation in compliance with FDA regulations. Computer validation isn’t just about checking boxes and creating a lot of documentation to meet compliance requirements. Computer validation forces good business practices in terms of defining what you need in a system, configuring or developing against those specific requirements, testing to ensure the requirements are adequately met, training users to use as intended, and then maintaining control over the system to make sure that you can rely on the data in the system (data integrity). And, all of this is documented because as we all know, to the FDA, if it isn’t documented, it didn’t happen.

Once the internal activities of system selection are complete, it’s time to move on to the external activities covered here. These include:

· Identifying potential vendors/solutions

· Preparing the RPF and facilitating the RFP selection process (if the team decided it was necessary and desirable)

· Conducting tailored demos

· Performing references checks

· Planning the project

· Negotiating and signing the contracts and agreements

This is the first post in a two-part series on system selection. The first part of any system selection focuses internally on what the business needs and how it wants to approach selecting a solution to satisfy those needs. This post focuses on these foundational elements:

· Defining business need

· Creating the selection team

· Performing the criticality and risk assessment

· Determining the system selection process and assessment criteria

· Defining the business requirements

When cars replaced the horse and buggy, the functions that were inherent to having a horse as the “engine” were not brought over when people switched to driving cars. Without a horse, you don’t need blinders, a horse whip, or apples to feed the horse — although thoughtful automobile drivers might consider the apples for hungry passengers.

The same concept holds true when implementing an enterprise system. Manual or paper-based processes or activities that were in place (even using something like Excel) are no longer necessary, nor do they fit well into a technological solution.

Bringing a project manager in after the agreements are signed is akin to bringing in a general contractor after the agreements with the subcontractors have already been signed. The general contractor, or project manager in my case, has expertise in negotiating those contracts and has experience around the best practices around the work. After the agreements are signed, not only have we lost all leverage but it leaves me as the project manager somewhat handicapped in doing my job and creates additional and unnecessary work (that the customer ends up paying me to do to clean up).

I prepared a one hour webinar for a select group of interested project management professionals and wanted to share the presentation and info here. I’ve spent the last 20 years managing IT related projects and have learned a thing or two and would love to help others to succeed and avoid some common mistakes. I also recorded a podcast on the subject which takes you through the slides and the process.

With the rapid adoption of SaaS solutions, a lot of the life sciences companies have opted to simply sign the SaaS user agreements without thinking about the their business requirements, the change in their business processes, and even ownership of their own data. They don’t take into account the intended use and validation requirements. I know that a lot of vendors really hate RFPs. They see them as a waste of time since they are generally sent out to check internal procedure boxes and not provide value to either the customer or the vendor. I had an implementation partner routinely challenge me on my processes. He thought that I should just recommend the best solution based on my experience and shortcut the process. What he didn’t appreciate was that I saw value in the process. It wasn’t just about selecting the solution. There is value associated with a good process for selecting a new system and that selecting the right system is only one aspect of the selection process.

Between 30% and 60% of IT related system projects fail. This doesn’t consider partial successes or disappointments associated with system implementations. Most IT related system projects don’t have clear criteria for success so the definition of failure is subjective. The costs of these failures could be in the millions of dollars and result in significant litigation in the billions of dollars. within Life Sciences companies, they can range from ERP system implementations to Quality systems to clinical trial management systems (CTMS), to lab systems. The cost of the failures isn’t just the cash outlay to vendors but includes internal resource and opportunity costs and can be in the hundreds of thousands to millions of dollars. Here are some examples of what can go wrong with IT system projects and then some suggestions on how to improve your chances for success.

SaaS (software as a service) systems appear to be the panacea for organizations wishing to reduce their overall IT costs and the burden of managing IT departments. Making IT someone else’s problem seems ideal when one’s core business is anything but IT: SaaS solutions allow companies to outsource the technology and get access to new functionality through frequent software updates. SaaS vendors position themselves in such a way to make it appear that with the ‘click of a button’, functional area managers can begin to use systems that used to take months to implement. However with systems subject to 21 CFR Part 11 compliance and validation in the life sciences space the companies must validate for intended use. The vendor cannot meet this requirement without some level of validation effort on the part of the life sciences company.