Determining User Requirements Prior to EQMS Selection | Blog
Blog & News

Determining User Requirements Prior to EQMS Selection

EQMS - 27 February 2014

The realization that a growing life science organization has a need to automate its quality processes is often first identified by a manager or a director of Quality Assurance within that organization. What will often prompt that realization is the fact that the organization is growing and the current manual methods will be too cumbersome in a larger business. Another motivator might be a less than satisfactory FDA audit that prompts interest in an EQMS for automation of Controlled Documents, Deviation Reporting, CAPA, etc. Unfortunately, these QA executives may not have any previous experience in the selection of an enterprise software solution. The first step in this selection process is ‘internal facing’ and involves the development of a user requirements document to help guide the software/vendor selection process.

The cost of failing to determine user requirements in advance of vendor & software evaluations can be quite high. These costs may be seen as ‘hard costs’ to the organization (actual dollars that are wasted) as well as ‘Soft Costs’ (impeded productivity) once the implementation of a poorly selected solution begins. Incomplete or total lack of user requirements can result in:

    • Expensive customization of the software workflows during the installation process, resulting in budget overruns as well as extended implementation periods.
    • An ill-fitting solution for the problem that the organization was attempting to address in the first-place
    • Dissatisfied users (and senior executives)
    • Extended rates of adoption among users

Development of user requirements can be highly detailed and exhaustive, or more simply developed on an excel spreadsheet. Whichever approach your organization chooses, it should still follow this basic development model:

    • Identification of ‘why the project is being undertaken’ (What is the overarching objective of the project?)
    • What will users be able/expected to do (identified by their role in the organization) once the project is completed? Once this is done, an organization can more concretely identify its selection criteria for a vendor and a solution
    • Complete the evaluation of vendors that are capable of meeting the requirements that have been identified

In conclusion, a software vendor should be able to assist with sample user requirement templates that can be used as guides in this first step. Here at SOLABS for instance we have assisted many life science businesses with the development of their user requirements for automating quality operations, referrals to clients that have been through this selection process, as well as a consultative selling approach that involves a review of your organization’s existing challenges with potential solutions.

If you would like assistance in this process, I’d be glad to help!

Ericka Moore
Question or Comment?