Why Buy QMS Software 

Whether they realize it or not, most organizations have some form of Quality Management System (QMS).  When they don’t realize they have a QMS, it’s undoubtedly not providing potential benefits of effectively managing quality. However, even recognized QMSs often fall short of their potential. 

Because QMSs tend to be document-intensive, automating their handling usually is a key way to increase QMS benefits while reducing their costs. While some organizations prefer to develop their own QMS software, many choose to use a commercially-available QMS software product. In general, using a commercial software product is quicker, cheaper, and less risky than developing one’s own software.  

Caution, though, successful QMS automation doesn’t happen automatically. There are many available QMS software products that perform needed QMS functions. Yet, each differs in ways that can affect its suitability for a given organization. Online forums are full of QMS automation veterans sharing unsatisfactory experiences with one QMS software product or another. In fact, a surprising percentage of organizations seeking to acquire QMS software are replacing an existing QMS software product! 

Why So Hard 

Acquiring software is more complicated than many, if not most, acquirers appreciate. Some approach it the same way they’d shop for a shirt. They go to a store, or seller’s website, and pick whatever strikes their fancy from what’s available. In a store, they might try the shirt on, but usually not; and that’s not an option when buying online.  

Often their purchased shirt is fine; but it’s common to be unhappy with it later. It may not fit properly, look right with other clothes, or otherwise fall short. Problems mount when someone else buys the shirt for you. The same types of issues afflict QMS software acquisitions, only more so. You see, buying QMS software is not the same as buying a shirt, especially not the same as when your favorite aunt buys it for you. 

Much more than with a shirt, there are many ways in which a QMS product must fit. Chances of a successful fit are largely a function of how well the requirements for that fit have been identified. Requirements for a shirt usually are relatively simple and obvious, although apparently not always to your aunt. It’s for work, or leisure, or playing football, or attending a wedding—as the groom! It matters! 

Requirements for QMS software that fits are more numerous, more complex, and often less obvious than for a shirt. Moreover, unlike a shirt, the impacts of QMS software’s fit can be extremely significant. Besides the costs of acquiring and using the QMS software, it can make all the difference in how well and economically the organization functions. It really matters! 

Some QMS software acquisitions fail because requirements are essentially not defined much more than for a shirt: We need a QMS. How to improve the acquisition success is obvious—actually define your requirements. Unfortunately, difficulties still can arise when requirements are defined less effectively than needed. Part of the lack of effectiveness is also failing to recognize the requirements’ inadequacy and therefore failing to improve them. 

Requirements definition falls short for several common reasons. First, it’s just plain hard. Even experienced (and presumably trained) requirements specialists (usually called “business analysts” but titles vary) exhibit wide ranges of skills, too often at the lower end. Second, too often such specialists aren’t even involved, so definition is left to those without suitable skills and knowledge, including and especially higher-ups. Third, whoever is defining requirements frequently follows mistaken models and processes. 

Requirements for Acquisitions 

Acquisitions involve two types of requirements. Some relate to the acquisition process itself. However, most refer to the content of the QMS being acquired; and these are what we’ll discuss further in this article. Contrary to many popular opinions, these are the same regardless whether the QMS software is being developed or acquired. 

A valuable way to reduce acquisition difficulties is to begin with a feasibility analysis comparing respective alternative acquisition approaches for meeting one’s requirements. These need to reflect the organization’s specifics but at relatively high level. They can guide whether and how to proceed but don’t include sufficient detail to compare vendor offerings. Many acquisitions get into trouble because they select a vendor/software product based on high-level requirements that are only suitable for comparing QMS approaches. 

QMS Content Requirements--Mistakes  

The basis for vendor proposals and comparative evaluation of them is more-detailed requirements. Besides general business analysis weakness, which afflicts almost all projects, I find three practices that commonly sandbag software acquisitions.  

1. Window Shopping. Many acquirers define requirements by reviewing commercial vendor products’ sales literature and watching product demos. Seeing features can prompt inquiry but should not substitute for it. Focusing on products easily leads to pre-picking a particular vendor’s QMS software product. Thus, I’ve seen requirements stated only as, “XYZ product or equivalent” or copied verbatim from XYZ’s sales literature. Both are basically placing an order for XYZ, so why go through the acquisition exercise motions? Meaningful inquiry about your needs, not what is available, is what enables a proper fit. 
2. Overlooking Stakeholders. Stakeholders, which is an all-inclusive term, are the source of all requirements. Overlooking a stakeholder means missing all their requirements. Quality specialists are obvious stakeholders, but they are by no means the only ones to query. Nor are IT folks, whose needs are relevant but seldom pertain to the business’s needs. While not all stakeholders have equal interests relevant to a QMS, it’s better to expend the effort to become more fully aware of their needs and consciously decide to exclude some than miss a needed capability due to not knowing about the stakeholder and their needs. 
3. Product Specification. When acquiring a QMS software product, acquirers often think their requirements are supposed to specify the product they hope to acquire. That almost always occurs when inquiry is simply, “What do you want?” Product design is usually not an acquirer’s area of expertise, whereas what they’re actually acquiring is the vendor’s more expert product specification (design) and implementation. When a vendor delivers a product specified by the acquirer which fails to provide the acquirer expected value, it’s the acquirer’s legal problem, not the vendor’s liability. 

QMS Content Requirements—Success  

Take the time to identify relevant stakeholders and learn their needs. Don’t expect them to specify a product. Instead, dig to discover what I call their REAL Business Requirements—business deliverable whats that provide value when satisfied by some product how. Don’t expect them to spout out fully-formed whats either.  

Rather, you discover their whats by learning and analyzing how they do their work, what they need to accomplish, and what stands in their way. Business rules, laws, standards, and regulations are key whats elements. So too are performance, capacity, safety, security, and other quality factors regarding the functioning they need. Research, including learning features of commercial QMS software products, can prompt inquiries about particular topics. 

Many think of their QMS as an onerous time-and effort-consuming necessary evil busy work. If that’s how you conceive it, that’s what you’ll get. Smart organizations view their QMS as a positive contributor to achieving strategic objectives. Ask, what do we need to know and do to enable us to reliably and repeatedly deliver consistently high-quality products and services that satisfy and delight our customers?  

Recognize too that adopting a new QMS will often involve changing mindsets and accustomed ways of working. Along with training and post-implementation support, prospective vendors must address requirement whats about guiding and facilitating changes that enable your workers to use the QMS software product to maximal advantage. 

Engage a vendor who shows you how their QMS software accomplishes these whats and thereby delivers your needed value.