Part II: Next Practices for Selecting an Enterprise Quality System

Note: In part one, we looked at how to approach the selection process. We assessed vendor capabilities and found the right philosophical “match” for your particular organization. In Part Two, we’ll guide you through the next steps for scoring vendors. Also, we will conduct an effective vendor search, and clearly define project scope and costs.

Scoring Vendors Without Overcomplicating the Process

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

Using Business Scenarios to Evaluate Vendors

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. Then, review the outline with key vendors. This may result in a more detailed scenario for each vendor to demonstrate. Alternatively, simply request the vendors to show how they would support the original description.

Validating Vendors Through Customer References

Once the team has narrowed down to the final one or two vendors, it is advisable to speak with customers. However, 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.
• Ensure the reference company has the correct person available.
• Do 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.

Establishing Project Plans, Costs, and Approvals

At this point, the team should have firm costs and establish (possibly with the vendor’s help) a project timeline. If it has not already been done, a business case justifying the project is often 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 typically require review and/or modification. This may necessitate the involvement of procurement and legal resources. Vendor setup, approvals, and possibly background checks may also be required. Depending on the company, a separate plan to navigate this stage can be helpful.

Building a Business Case for Executive Approval

Often, your project is vying with other capital needs for funding. Furthermore, few members of the capital committee or approval executives will likely be familiar with your project. It can be useful to create a summary presentation. This presentation should describe the business need for this software and the vendor selection process. Include the general project plan, the benefits, and when they will begin to accrue. Include the alternatives as well, and the recommendation. 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?

Final Tips for Successful EQMS Implementation

Embarking on the implementation of a new EQMS is much like any project where change is necessary. Success will hinge on consistent effort, working through obstacles and resource limitations, as well as overcoming 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.