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
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
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
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.
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
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
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
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.
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
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.
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 firstname.lastname@example.org.