Making the decision to select new software for implementation in your organization is no simple feat. While it’s easy to get excited about the potential outcome new software could bring, selecting software systems without the proper planning, and a defined process for evaluating and selecting a system can lead to oversights and bad investments.
As a leading software vendor of collaborative content management tools with an experienced consulting division, we’ve been involved in many software selection processes with and for our clients. Over the years we’ve become familiar with some of the common pitfalls that arise when bringing in new software, and we’ve been working hard to develop best practices for these vendor assessment projects.
Prior to even looking at available software options, it's best to thoroughly define your needs and what the application you select should do for you. Life science organizations, for the most part, are process-driven. They receive vast amounts of information and content on a daily basis and are responsible for complex business processes that not only have ethical considerations, but also regulatory requirements.
Its true technology will facilitate the way your organization manages these processes, but a successful software implementation will not only make this work easier but more streamlined and ultimately more effective. It is important to remember that a new system that doesn’t take into account your processes and needs will only make running your organization and managing these processes more difficult. This is where defining your requirements begins.
In the next article and the articles that follow, we will be outlining some key steps and important advice for when you look to acquire new software applications at your organization.
Assemble a Vendor Selection Team
Defining your requirements begins by assembling a Vendor Selection Team whose responsibilities lie in appropriately selecting the right software application. It’s important to select individuals from your organization who have a common interest in the vendor selection process, and have expertise and understanding in the area of the business that the software application will support.
Begin developing system requirements
The first mandate of the Vendor Selection Team is to review the high-level features needed for the software system from the original business case and to produce a set of requirements by gathering additional information from stakeholders.
There are numerous ways to prepare these requirements and we won’t be delving into this topic in great detail as it could be a book on its own. To begin - requirement lists, use cases or whatever tools you are most comfortable with can work, however, just remember that the goal at this stage is to be able to clearly communicate your needs to the potential vendors, and have a baseline to evaluate the options that will present themselves. You should not be looking to produce a detailed system requirements specification to pass to a team of developers at this stage.
The most common mistake at this step in the vendor selection process is to design the system, instead of defining the business needs. Try writing requirements with your users in mind. Below is an example of how you can begin to write clear vendor requirements by staying business-focused and keeping away from system design:
Don’t over-engineer your requirements (yet!)
Generally speaking, in most scenarios, it would make sense to separate functional and non-functional requirements, however, at this stage of the process its best to keep it simple and adapt later. Now I know you’re burning to ask - Why is it that we should not be producing a full-blown set of system specifications?
Firstly, system specifications documents take a significant amount of effort to put together. Secondly, not all companies have the knowledge or the available skills to do this in-house at this point in the process. Last and not least, detailed system specifications are overkill if you are just initiating a vendor selection exercise.
With a large list of detailed requirements, you will most likely forgo solutions that would have met business needs because they couldn’t fit into the requirements filter you created for yourself. It’s very easy to fall in love with your own creation and consequently slow down the vendor selection process significantly.
Remember, If you find that most out-of-the-box solutions don’t meet your specific business needs, you can start thinking about custom development, but only then should you be creating complete system specifications.
Key Requirement Categories that you should be evaluating
Although we recommend staying away from detailed system specifications, we still suggest you develop a list of clear and verifiable requirements. We recently released an article highlighting the key requirements categories you should consider that included some key requirements categories that should be evaluated when defining your future paperless system:
- Process: What specific business processes will you be supporting? Documentation management, system change control, corrective and preventive actions, etc.?
- Reports: What specific reporting needs is your system required to meet? Will you necessitate dashboard or live reports to make important decisions?
- Regulations: What regulations is your system subject to? 21 CFR Part 11, Annex 11, ICH E6, 21 CFR Part 820, etc.?
- Standards: What standards must your system meet? (ISO 13785, SOX, GAMP 5, etc.)
- Integration: Are there any other systems your new system must integrate with? If so, how should they integrate?
- Support: What type of support do you expect from this new system? Will you need a Help Desk you can interact with?
- Documentation: Will you be requiring training documentation, user guides, deployment guides, or validation scripts? Do you already have the minimum level of procedural controls in place to manage your system post-go-live?
- Migration: Will you need to migrate some of your existing records in the new system? What are the data sources and data formats for those records?
- Expend-ability: Is the required to support other key feature areas you might want to include in the future? For instance, if the system supports the management of procedural documents, is the same vendor offering different modules grouping other sets of functionalities, such as training or CAPA management to grow your system into a complete Quality Management System?
- Language: What languages will the system need to support? Is it sufficient for the systems to accommodate different document languages or must the interface match the language preference of the users?
- User base: Will you be supporting remotely dispersed users? How many users? Will you be managing internal (employees) and external users (partners, suppliers and external consultants)?
- Partnership: Are you looking for a long term technology partnership or a deliver-and-go vendor? Are there certain characteristics you would like to see in your new technical partner? Are you looking for a good cultural match and/or a complementary fit to your business?
- Product Maturity: How long as this product been out for? How large is the user base? Are you willing to be an early adopter of technology or are you looking for something everyone else is already doing? Will you be requiring references to be provided?
- Cost: What is the total cost to deploy the system, including licenses and consulting services? What will it cost you to maintain it? To upgrade it?
- Adaptability: How configurable is the new system?
- Dependency: Is it acceptable for this new system to create a dependency with your new vendor or would you eventually want to manage and update the system on your own if you so choose? Is the system built using widespread technology that you can adapt to your need or is it proprietary to your vendor? Would it be relatively easy for you to find technical experts for the said system?
- Deadline: Do you have any specific implementation schedule needs for the solution. A hosted solution? Maybe a cloud-based solution with minimum configuration could be ready in a matter of weeks whereas an on-premise deployment could take months.
As you can see its best not limit yourself to the technical solution when identifying requirements during a vendor selection effort. Requirements can include anything that is related to the product offering you are hoping to find and it can go far beyond functional and non-functional system requirements.
Don’t forget to think about items such as; services (deployment, validation, migration, training and general support), supporting documentation (procedural templates, validation documents and training materials) and organizational characteristics (quality maturity level, industry-specific expertise and geographical location).
Weighting your requirements
With a complete list of requirements on hand, you will need to assign the level of importance that each of the requirements carries forward. This can be done on a 1-2-3 scale with 1 being “Nice to Have”, 2 being “Important” and 3 being “Critical to Operations”. This determination should be kept for yourself and not be communicated to the vendor during the RFI (Request for Information) process but it should be determined before passing to the next step.
In summary:
- Assemble your vendor selection team
- Define your requirements of the system/vendor you are looking for. (Remember your target audience: vendors and stakeholders OR developers?)
- Rank all requirements for future scoring
