T System Failure
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 [1] and result in significant litigation in the billions of dollars[2].
Cost of Failures
As for the types of projects, within Life Sciences companies, they can range from ERP system implementations to Quality systems to clinical trial management systems (CTMS), to lab systems. Within other types of companies, they can range from ERP system implementations to CRM implementations. 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[3]. 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.
Example #1: Lack of Executive Support
In a small company, getting executive support is critical. A biotech company decided to implement a new PLM (product lifecycle management) system which included document management, deviation/CAPA management, and change management. The Quality group selected the system and implemented using what I would call a grass-roots implementation approach. They didn’t get buy-in from senior management and didn’t clearly communicate to the company the benefits of the system and how processes would change as a result. They encountered resistance as they were getting close to Go Live and as a result, encountered major issues with adoption. People didn’t want to use it and senior management didn’t make sure that staff used the system properly. This is especially critical in a regulated company in that this is the type of system the FDA will review during a pre-approval inspection (PAI). During the years that this company used the system, there remained resistance to the system and the processes around the system contributing to hundreds of thousands of dollars in wasted time and resources. While this wasn’t a complete failure, it was not a success and the company was forced to limp along with it for years.
Example #2: Lack of ERP Experience
Another diagnostic company chose an ERP system and signed vendor agreements before bringing me on as a project manager. Their selection team did not have previous experience with implementing or using an ERP system and relied on the software vendor to guide them on project scope, phases, and timeline. The vendor did insist on the customer having a dedicated project manager which was a good thing. Unfortunately, an experienced project manager should have been brought in to plan the project before any agreements were signed to ensure that the project and expectations were clearly defined and that what was being implemented made sense. As soon as I started, we had to renegotiate the contract because what the vendor suggested made no sense from a business perspective. My client also learned during the implementation that some of the functionality they assumed was there or were not yet aware that they needed, did not exist in the software they selected. The diagnostic company ended up limiting the scope of what they intended to implement and ended up with less than they expected. Once again, while this wasn’t a complete failure in that they were able to use the system, they did not get what they wanted, or could have had, and ended up simply making due.
Example #3: Lack of Vendor Audit
The Clinical Operations (ClinOps) group of a company I worked for selected a clinical trial management system (CTMS) and began the implementation. The system was to capture electronic signatures as defined in 21 CFR Part 11 and the vendor said the system was compliant. The ClinOps group believed the vendor when they said it was compliant and didn’t do a vendor audit prior to signing the agreement. The implementation started and I was brought onto the project part way through to validate the system in accordance with 21 CFR Part 11 . The first thing we did was conduct a vendor audit where we learned that the testing and documentation did not meet the minimal requirements and therefore could not be relied upon. This expanded the testing requirement and burden on the company extending the timeline and adding significant costs to the project. We also learned that the way that the system captured the electronic signature and generated an audit trail was not in compliance with 21 CFR Part 11 and therefore we could not validate the functionality and use it to capture electronic records and signatures. This resulted in significant change in the intended use of the system and manual workarounds. The system ended up being somewhat useless to the ClinOps group and was abandoned shortly after implementation.
Example #4: Misrepresentation of Functionality by Vendor
Another biotech company I worked with selected an ERP system based on defined requirements for the financial side but didn’t have experienced team members representing supply chain management (SCM) and manufacturing. As a result, they chose a system based on an incomplete requirement set that resulted in significant compromises on the part of the SCM and manufacturing. As we got started with Phase 2 of the project, we provided the vendor with a detailed requirements document and asked them to respond with how they planned to implement the functionality. This proved to be very helpful when we had trouble implementing the functionality and realized the functionality did not exist as represented by the vendor. We were able to use this documentation to hold the vendor responsible for cost overruns and for other costs incurred by my client as a result of attempting to configure for functionality that was promised but did not exist.
How you can increase the likelihood of success for you IT related system project
· Ensure you have buy in from key stakeholders including an executive sponsor and a business sponsor
· Clearly define your company’s requirements for the system and select a system based on the requirements
· Conduct reference checks on the software and the implementation vendor prior to making a final decision and signing any agreements
· When the system is business critical and/or will be validated (subject to 21 CFR Part 11), perform the vendor audit BEFORE signing any agreements
· Plan the project
o Clearly define expectations and roles of both internal and external resources
o Clearly define scope of the project including deliverables and timeline
o Build in time for training of project team members and end users
o Build in time for testing to ensure the system meets your company’s business requirements
· For external resources, have a clearly defined and documented statements of work with documented assumptions after the project has been planned
· Adequately staff the project and back-fill internal resources so they aren’t doing two full time jobs
· Use a trained project manager to manage the project
· Provide for regular communications and status reporting for project team members and other stakeholders
· Manage the scope of the project and have a formal process for managing scope and timeline changes
· If you are the customer, maintain ownership of the project to ensure your company gets what it needs.
Conclusion
While there are many variables in IT projects, following the steps outlined above will increase the likelihood of a successful IT related system project.