February 12, 2013

Note: In part one, we looked at how to approach the selection process, assess vendor capabilities, and find the right philosophical “match” for your particular organization. In part two, we’ll take you through the next practices for scoring vendors, conducting an effective vendor search, and clearly defining project scope and costs.

Beware of how to measure. Companies frequently will devote significant effort and elaborate scoring methods to grade vendor functions resulting in very precise but ultimately irrelevant scores. Academic studies of software project success indicate that product functionality contributes less to success than the customer and vendor implementation team and process.  Keep the assessments simple and double-check major variances with the team members and the vendor.

One approach to avoid feature/function obsession is to develop scenarios for vendors to demonstrate. Select one to three primary areas of business improvement (CAPA, Customer Complaints, etc), develop an outline of how the team would like these processes to be, and review the outline with key vendors. This may result in a more detailed scenario for each vendor to demonstrate, or simply request the vendors to show how they would support the original description.

Once the team has narrowed down to the final one or two vendors, it is advisable to speak with customers, but first, consider what questions you would like to have answered. This will achieve at least three things:

  • Focus the team on the primary concerns with the vendor/product/project.
  • Assure that the reference company is appropriate.
  • Allow the reference company to have the correct person available.
  • Not miss any key points during the meeting.

This can be an excellent time to hear the lessons learned by the customer – not just about the product or vendor but the project itself and how it has evolved over time.

Quality WhiteboardDefined Project Plan and Costs

At this point, the team should have firm costs and establish (possibly with the vendor’s help) a project timeline. If it has not been done already, a business case justifying the project is frequently required to secure executive approval.

The most common source of frustration and delay at this stage is the team not knowing the internal process for getting the project approved. In many companies, capital requests and presentations are required. Contracts and agreements usually must be reviewed and/or modified requiring procurement and possibly legal resources. Vendor setup and approvals and possibly background checks may also need to be done. Depending on the company, a separate plan to work through this stage is sometimes helpful.

Often your project is vying with other capital needs for funding. Furthermore, few members of the capital committee or approval executives will know much about your project. It can be useful to create a summary presentation describing the business need for this software, the vendor selection process, general project plan, the benefits, and when they will begin to accrue. Include the alternatives as well and the recommendation and consider framing the presentation to address these questions:

  1. Why do anything?
  2.  Why do it now?
  3. Why this recommendation/alternative?
  4. What does the company need to invest – not just money but what resources?


Embarking on the implementation of a new EQMS is much like any project where change is necessary. Success will hinge on consistent effort and working through obstacles and resource limitations as well as resistance to doing things differently.

Here are some final tips to help ensure success:

  • Secure solid management support – make sure the project leader has been given the time, the resources and organizational support necessary.
  • Get requirements defined, agreed upon and documented – reference and revise frequently.
  • Avoid the geek factor –  beware of flash. Remember, features can often be added later.
  • Don’t let perfection be the enemy of the good – a version 2.0 can come later.
  • Strong team and communication – better to get issues out early.
  • Focus on small wins, quickly – iterate, test and refine along the way.