News Stay informed about the latest enterprise technology news and product updates.

The struggle to create quality software

Software quality practices have been sacrificed as a way to improve a company's bottom line. But those sacrifices unnecessarily increase the risk to clients.

John Scarpino
John Scarpino

Information management has seen a breadth of change in the past 10 years. Different technologies, faster networks, quicker computers and brighter individuals have revolutionized the way we view IT. As a director of quality assurance, I have noticed a consistent downward trend within companies of all sizes in regard to information management. Issues dealing with process, requirements, change management, quality with ownership and direction are now brushed aside with little or no importance attached to them. The root cause of such comes from the American business model: Increase the bottom line as much as possible by cutting costs and expenditures. Unfortunately, the practice of maintaining quality throughout production is typically sacrificed as a means to this end.

I've found that one of the underlying reasons why an IT corporation may decide to remove (or completely overlook altogether) the steps associated with quality production is because these steps are wrongly regarded as the most lucrative to relinquish. This kind of mentality has been a constant, problematic issue for me throughout my past employment. It starts with a lack of direction and ownership where it is most necessary. A blind eye is usually turned to the idea of hiring an individual whose main function is to take ownership of overseeing company and department process and procedures, requirements, change management and quality. Of course, these four aspects are imperative for the creation of a suitable product or service. When these are combined with sufficient support from a "go-to" person, the scope of the project will most likely will turn out to be a success.

To their credit, IT businesses generally do a satisfactory job at filling the main positions in the corporation: managers, developers, network individuals, salespeople and help desk/support. But those roles don't always provide sufficient support for the project and clients.

If IT managers continue to overlook the importance of process, requirements, change management and quality control, corporations will continue to unnecessarily increase the risk for clients.

Similarly, the need for fluidity in process and procedure is almost never addressed. Process outlines the business flow from department to department, the types of internal and external documentation that is needed, and the rules of how to conduct business in every division. When business transactions are made, all stakeholders must be aware of the timeline from start to finish, as well as follow-up procedures. Executives in most of companies I've worked did not find this an important task due to the fact that it is not directly connected to a monetary payoff. Instead, they believed that changing the way an IT process was handled would be too costly due to the amount of time it would take to revamp it. What my previous employers didn't understand was that the long-term benefits to such a change greatly outweighed the time that would be lost during reorganization.

Issues that can occur because of a poor IT process include ineffective or misleading communication between departments and/or clients, lack of project responsibility and flow from start to finish, workflow documentation issues, aggravation on the part of clients and various departments when specific documented material is expected and then not received, and the lack of employee knowledge of supporting business tools and how they are to be used. The list can go on and on.

The one saving grace of a weak process or procedure is the kind of technology an organization uses to support it. On the other hand, technology can create an additional problem because before it can be used, it needs to be centrally managed and agreed upon by employees of the company. If a greater importance were placed on process in the first place, rebuttals such as "I did not know" and "It's not our responsibility" would be less of an issue. But as so often happens in business, corners are cut, and the ants are left scrambling to pick up the pieces.

Poor requirements gathering
Corporations that have few concrete requirements for each service or product are another trend I have seen time and time again in the IT business world. Often, the creation of legitimate documents that outline requirements is not a high priority. A reason behind this is due to the fact that analysis of requirements and design take time to generate -- time that, again, is not directly tied to a profit. If a client's objectives for the project do happen to be noted, they are often written in erasable marker on white boards or typed in emails, but almost never put into a formalized document.

The adherence to clear-cut requirements during the analysis phase can assist in troubleshooting any issues that could occur before development. For example, if changes do arise within the development process, the client must review the requirements, decipher the best course of action and provide proper authorization for the change. Therefore, critical errors will not be easily overlooked, and traceability is created from analysis to development, from QA to the client.

Proper change management procedures essential
Change management is an important part of both the business and technology lifecycle. When the function or condition of a technology changes, it is up to the change manager to assure a smooth transition and implementation. Without proper change procedures, too many people have their "hand in the cookie jar." Having checks and balances of how a situation can be changed and who is authorized to change it is ideal.

More information on improving software quality
The state of software quality, part 1: Problems remain, but all is not doomed

The state of software quality, part 2: The challenge of building quality into the development life cycle

Project signoff: It isn't over 'til the customer says so

Here's an example: When a problem occurs in a production system, the developers in charge of creating a fix are not authorized to fully implement it. Instead, the developers must go though the change management department, which assures that changes are made properly. This division also must document any and all modifications to the system for auditing purposes or in the rare case that the system needs to be reverted. Many tools are available to aid with change management, but it is important to acknowledge that this practice incorporates aspects of process, documentation, software, security and hardware.

I have spent most of my career as a QA professional, building up the skills to become an expert in the field. Unfortunately, what I have found is that an independent QA department is often ignored and all effort is concentrated on how to cut costs instead of risk mitigation. Within the IT profession, QA can be realized in two ways: quality in business and quality in development. Quality assurance is truly an asset to the way a business is run as well as to the condition of a product as it becomes ready in production. The purpose of QA in an IT organization is to certify that all of the defined business practices/process, requirements and change management procedures follow the correct business function. Sometimes within a development lifecycle concerns may arise regarding timely execution of various phases. It is the responsibility of the QA team to find those issues before they become a problem or fix them when they transpire.

Much of QA's time is spent adjusting and auditing business process and standards and correcting process issues that the corporation shouldn't have made to begin with. Most of the organizations I've worked for have cut corners in order to save money and expect one person to be pulled in two or more directions. I believe the roles of the QA professional need to be separate from that of direct profit generation. Biases will exist if an individual is both a developer and quality analyst, and not enough time can be aptly devoted to either role.

The function of QA is to review and analyze business requirements, create test plans, execute the test plans against the developed product, report and analyze issues that were found and create metrics from the actions performed against what was tested. Often QA professionals are thought of as "testers" instead of what they truly are: analysts. Due to the fact that the need for a quality process occurs after the development stage, QA is not viewed as an essential division. Bringing QA in early in the lifecycle, especially during analysis, will help decrease risks associated with the project.

Presently, I have observed two extremes in relation to information management. One is where companies decide to invest in quality process and procedures up front because they are able to see the need to cut potential risks. The second is where an IT firm spends too much attention to "billable" and "non-billable" hours, without devoting enough attention to their product or services. All too often, the latter prevails in America's IT corporate world. There must be a wakeup call for all information managers for them to see the implications of how they conduct business. Organizations must review every piece of process rather then focusing solely on profit. Of course, the bottom line is important. It's what investors thrive on. Nevertheless, if IT managers continue to overlook the importance of process, requirements, change management and quality control, corporations will continue to unnecessarily increase the risk for clients.

About the author: John Scarpino is director of quality assurance and a university instructor in Pittsburgh. You may contact him at

Dig Deeper on Software Quality Management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.