It’s difficult to find a business or industry that isn’t driven by software applications. From phones and laptops to manufacturing systems to validated applications for regulated industries, software drives many of our business processes. Following deployment, the onus for overseeing and maintaining software frequently falls upon the customer. Given the need to be able to modify the system to meet evolving demands and updated business processes, a quality management infrastructure is essential for maintaining the software application.

Modern software applications are highly configurable and capable of numerous customizations, which present a unique set of challenges. Specifically, customers responsible for maintaining the software, or elements of software applications, must do so deliberately and with control. This includes having quality processes for ongoing maintenance efforts, robust configuration management and change control, risk-based decision-making, and a documentation infrastructure for executing changes in a reliable and prescriptive manner.

To carry out the quality management activities related to software maintenance, it is advisable to establish dedicated resources in the form of a technical team and a business process owner (BPO). The technical team can be an individual or a small group consisting of power users or administrators – people who function as subject matter experts and are intimately familiar with system operation. In addition to maintaining the system, the technical team provides system-level documentation. Minimally, this should be an administrative guide describing how user accounts are provisioned and how security and access are managed.

The BPO is one who understands system processes and provides a big-picture perspective when considering modifications. The BPO assists in setting new or revised software requirements in support of configuration management. System modifications involve gathering requirements, which are then passed on to the technical team to assess for viability. Close communication between the technical team and BPO is essential, beginning with documenting requested system changes, evaluation, assessing system and user risks, and ultimately creating an implementation plan for approved requirements.

Customers must be prepared to address modifications to the system and technical documentation from go-live. The importance of a robust change control process cannot be overstated. These packets of information show the evolution of the software application and supporting documentation, and demonstrate changes are taking place in a controlled and justified manner. Does every change to the system need to be documented to the same degree? The answer largely depends on business practices and risk to the system. Routine changes or those not impacting system functionality can be documented in the administrator’s guide as not requiring a change control. The technical team, BPO and QA can consult on those approved for omission from change controls and a comprehensive list documented to justify their exclusion.

Besides basic information identifying the change control (i.e., number, title, description), include detailed information identifying the impact, the implementation plan, a thorough risk assessment explaining impact mitigation and provide an area to summarize the execution results.

Risk can be assessed multiple ways; be it by following a company’s risk management process, industry best practices or through tools such as a Failure Modes and Effects Analysis (FMEA). The level of assessed risk drives the extent of testing, objective evidence and supporting documentation. Verification of low-risk changes may be satisfied by a second party with appropriate access and expertise confirming the change; high-risk changes may require verification through user acceptance testing (UAT) where QA and the BPO approve executed UATs.

Depending on change scope and associated risk, additional documentation may be warranted such as a dedicated protocol document, migration plan or test plan. When such materials are generated, write a summary report to document the results of the change effort. In all cases, define the process being followed in system-level documentation or change management procedures.

ASQ’s Software Division provides an excellent resource for discussing best practices and meeting with industry peers to gain knowledge and insight. Software owners may also consider the ASQ CSQE certification to gain additional depth of knowledge into software development lifecycles, testing and management.

In summary, customers are responsible for protecting their investment in software applications, demonstrating through quality processes that oversight is in place and changes are executed in a state of control. Regulations, industry guidance and best practices should all be considered when formulating business processes. Through careful and dedicated effort, customers can reap the full benefit of their software acquisitions and be prepared to demonstrate the depth of their software quality program.