by Mary V. McAtee

Endless variations of compliance management software compete in the marketplace today. In terms of features and functionality, these products run the gamut from fill-in-the-blank forms that function as electronic paper to extremely sophisticated and integrated modules that support serious business management objectives beyond ISO/TS 16949 compliance.

Given the choices, it’s not surprising that the criteria companies consider when deciding which application to use are as varied as the available products. Some companies seek very targeted functional solutions to fill the gaps in their existing systems. Applications are available that concentrate on document management, corrective and preventive action, or calibration and gage management. Some full-spectrum quality management systems are so comprehensive that users are tempted to flip a switch and hang out the “gone fishing” sign.

However, even the best paperless compliance management solution is useful only if it’s reliable, accessible and useable by employees. Once you’ve selected the system that’s right for you, your best assurance of success is a strong, well-thought-out implementation plan. Companies that have invested significant time and energy in selecting the right software often fail to institute basic planning and training, which ensures that their efforts and the system will fail.

Software salespeople let their customers down by insinuating that a product is so intuitive it will leap from the box, embed itself in the server and download into users’ brains while they sleep. All software solutions are tools, and they’re useful only if they’re accessible to a knowledgeable user. Even selecting an application service provider doesn’t eliminate the need for planning and training.

Plan for successful implementation

Developing and executing a solid implementation plan doesn’t have to be a time-consuming drain of resources. If the software provider or your own internal resources forecast a complicated implementation project that rivals the building of the pyramids, step back and do your own reality check. Consulting and service dollars are important revenue sources for software companies, but some “value price” their software, anticipating that they’ll gain most of their revenue on consulting and implementation fees. Likewise, internal resources, particularly in these uncertain times, see long projects in which they control the timeline and dispense the knowledge as a safe haven from downsizing.

There are some easy hedges against inflated project plans for both contracted and internal implementation projects:

Accurately state the size, locations and populations of all the sites involved in the implementation as part of your proposal request. Specifically request detailed timeline breakdowns for vendor-suggested implementation efforts and associated costs.

If you’re starting with a limited implementation, provide details about the current scope you want and potential growth of the project over time. If you’re beginning with only one business unit, be clear about this limited scope but be sure to request a quote for all the other business units, countries and interested parties. This strategy serves two purposes: It lets you accurately scale cost expectations to your management, and it motivates the software provider to dig a bit deeper for additional considerations and incentives to ensure it gets the future business.

Request and contact references from like-sized organizations. Discuss their implementation and rollout experience in general. If they tell you that the application is fantastic and was well worth all the pain and effort to implement it, zero in on the “pain and effort.” Try to determine whether it was an inevitable part of the process or partially self-imposed. If the organization had a great experience, try to get names of the resources involved and the process used by the organization. Encourage those in the organization to share lessons learned and things they would do differently; such information can be invaluable.

Request all advance planning materials that the software company can provide. The provider probably won’t supply you with training materials in advance; these are usually protected and copyrighted. If the company tells you no materials are available or that the product is so simple that training materials aren’t necessary, proceed with extreme caution.

Request information about the size and qualifications of the software provider’s training and implementation group. Request the biographies of key staff members. You want more than someone who will tell you which button to push. You should be looking for experienced professionals who understand the concepts of quality management, registration requirements and compliance management--and the role the software plays in making these concepts a reality.

Internally select a project leader who’s self-directed and broadly informed about your business processes. A good project leader should know how to work your internal systems to garner the necessary time and resources without being so abrasive that people resist working with him or her.

Rollout planning and information technology

Other considerations can speed the process and help ensure success. Your project will need an internal champion. This person might function in an advise-and-consent capacity totally removed from the daily activities. The key component for a good champion is that he or she understands, believes in, and can articulate the project elements, business goals and anticipated returns to the most senior levels of management.

Usually two elements are required for any significant software implementation:

Functional rollout planning. This concerns how, where, when and what parts of the software will be used by whom. This portion of the project includes timeline development, end-user training and the application’s cultural configuration to reflect your business.

Application rollout. This concerns the IT environment required for the application to run effectively. It includes network, security, accessibility and data integrity concerns.

Resources selected for the implementation team must represent and understand both interests. If the IT representative’s interests aren’t clear from the proposal stage through implementation, the project has a vastly diminished chance of success. Quality directors have been placed in the uncomfortable position of restating cost figures and timetables to senior management because they didn’t initially understand existing network and infrastructure limitations.

Working with your IT department from the beginning should minimize unexpected project costs because of additional software and hardware requirements not superficially apparent in the vendor proposal.

One of the first internal tasks that will really help to characterize the project is developing an internal information map. Information maps can be created in several different ways--from simple team notes on a white board to spreadsheets. The important thing is that you end up with an accurate portrait of the following:

Who will access the software and what level of access will they need? Will they be administrators in the system? Do they need to enter data, or will they only need to access and read data entered by others?

How will these users access the system? Do they currently have access to a computer with sufficient power and appropriate network connections to do the job? Do they have an e-mail address to permit system messaging, if required? Are other software installations and/or licenses (such as browsers, operating systems or Microsoft Office components like Word or Visio) required for these users beyond the application itself?

Are there designated IT resources sufficient to support the rollout on site or remotely?

What portions of the software will be used by what locations and groups? Do they have sufficient and correct network access at each location? Are required servers in place with sufficient power and storage capacity? Is there a disaster recovery and backup plan to support each one of these facilities?

If you can confidently answer these questions, you should then be able to put together a very accurate plan with associated costs.

A study commissioned a few years ago by a leading software provider concerned the mindset of organizations buying technical or business software systems. The study found that these purchases usually represent a decade-long decision, but organizations begin to scan the horizon for new technologies at the five-year mark. Your planning should be developed around a five-year lifecycle with an implementation plan that looks forward in six-month increments.

Incremental implementation and training

Organizations that attempt to swallow large software systems whole tend to choke on them. If you train employees on every module and attempt to roll out every functional piece at once, displacing existing systems, the result is seldom satisfactory. Apply some logic to the rollout process. If the software has a single purpose, such as document control or CAPA, your task is simpler. However, if it’s a multifunction, comprehensive system, it’s particularly important to order the rollout stages.

The first increments are usually driven by your organization’s immediate needs, for example, legacy systems with a clear sunset date that must be replaced. Gaps or findings in previous audits that must be addressed by portions of the software are another early-deployment candidate, as is upgrading registration to a new standard or a new version of a standard addressed by the software.

Planning in six-month increments will allow you and management to take stock at defined intervals to assess the effectiveness of both the rollout components and the software itself.

Training is usually the “neglected stepchild” in most software implementation projects. Typically we see too much training too quickly or too little training to support the project. A good axiom to remember concerning software training is that if people aren’t accessing within three weeks the software functionality for which they’ve received training, they’ll rapidly forget what they’ve learned.

Keep in mind, too, that one-size-fits-all training is rarely effective. Training should match the makeup of the group and its comfort level with computer technology in general. People who’ve never used a computer shouldn’t be paired with confident users. Someone will walk away from that class with their needs unmet. Conversely, don’t discount new computer users and those learning computer skills late in their career. These people, properly instructed and encouraged, will take readily to the new opportunity and tools you’re providing to them.

Training a trainer is often a more cost-effective and preferable long-term alternative to direct end-user training by the vendor. This involves selecting in-house subject-matter experts and providing them with sufficient training to permit them to train others on select portions of the software application. This quickly makes an organization self-sufficient, permits just-in-time training, allows fast assimilation of new system users and minimizes “How do I?” questions to the vendor’s technical support organization.

One of the questions you should ask software providers early on is if they have bilingual trainers. Even if your people will be using the software in English, it can be helpful if the trainer speaks Spanish, for instance--particularly if that’s the first language of the majority of the user community.

Best practices also include limiting those who are permitted to call the vendor’s technical support organization to a few knowledgeable users who can weed out true technical issues from user-training issues. This will ensure that responses from technical support are faster and training gaps are addressed appropriately.

The final consideration is potential for system-integration. Even if your immediate-use plan for the software is simplistic and stand-alone, your long-term vision should include the potential for using the maximum functional return. This could mean sharing data between sites outside the current scope; allowing access for your customers and supply chain via an extranet; integrating with your ERP systems, such as SAP; and eventual graphical data reporting from the system. Ask enough questions early on to ensure you understand what’s doable, feasible and practical for the software application you’ve purchased beyond its core functionality.

The very minimum you should expect is the ability to transform all the data you’re capturing into management information:

Does the system have a reporting package? How does it work? What are its functional limits?

Can you develop reports in addition to the reporting formats provided? Can you use other reporting packages your organization already owns, such as Crystal Reports or Cognos?

Will the software work with your company’s existing database standards, such as Oracle or DBII, or are you adding another component that must be supported to the mix?

Is it compliant to 21 CFR part 11 for electronic signatures if that affects your industry?

These are all considerations that will ensure you select a package that has the potential to grow with you and that will support your drive for continual improvement over the long haul. Sadly, organizations frequently buy systems that become “shelf ware,” gathering dust because the implementation failed or evolved into a dysfunctional technological solution with overlapping functionality selected by different groups.

Every major project undertaken by most companies today gets lots of scrutiny and discussion before the check is ever cut to purchase the software or services. Prudent planning and attention to detail can mean the difference between presenting either a painful explanation or a bottom line-enhancing success story to management one year later.

About the author

Mary V. McAtee is vice president of implementation services for IBS America. A 25-year quality management professional, she has a decade of experience in leading successful software implementations in large corporations. Letters to the editor regarding this article can be sent to letters@qualitydigest.com.