The conclusion must be that the confusion will only be reduced through an alignment of the theory and practice of Quality Assurance. What QA is expected to do must be better coordinated with what it is typically asked to do. Until this is done even the best QA organizations will struggle with inefficiencies and lack of true direction.
A common theme will run through the entire discussion; namely, that sound processes produce quality products. Quality Assurance professionals are more interested in the processes involved in the application of information technology than in the actual products created by those processes. That is not to say that the products themselves don't deserve a great deal of attention; but QA will focus in on the processes. Other quality management specialties will focus in on other aspects, including the product itself.
The System Development Life Cycle, in principle, is a set of procedures intended to guide the creation and use of information systems from the moment they appear as a simple idea in someone's mind, until they are permanently retired from service because they are replaced or become unnecessary due to changes in the business environment. In practice, however, potential information systems fail to be recognized by the information systems organization, and QA in particular, until they become an explicit request for service from one or more non-information systems organizations. In practice, an organization's SDLC begins at this point with the definition of the requirements to be served by the proposed system. The procedures in the SDLC are then used, more or less serially, to create the information system using a succession of project phases, each intended to define further detail on the proposed system until it can actually be built and tested during a late phase of the SDLC. Traditionally, once an information system is completed and in use by the target community, the SDLC ends. Many SDLC's contain processes for monitoring and supporting systems after implementation, but are actually rarely used in this capacity. As for the principle that the SDLC stays relevant until the ultimate retirement of the information system, this rarely occurs in practice. For this reason, the SDLC is often referred to as the 'development methodology' for the information systems organization; a distinction that only highlights the difference between the SDLC in principle and the SDLC in practice.
Regardless of the level of comprehension of an organization's SDLC, there is always a requirement to adjust its procedures and organization to the requirements of each individual project. This is the role of the management of the project. Project management is not a role that can be assumed by the Quality Assurance function, but there are areas of project management that are well suited to QA support because of their close ties to the SDLC, namely; project planning and project control. QA, because of it cross-project and cross- organization perspectives, is in an excellent position to offer a project manager support and guidance in the planning of projects. The selection of which tasks and deliverables within a methodology are appropriate to a particular project depends upon a thorough knowledge of the purpose and intent of each task and deliverable. The Quality Assurance analyst, as a specialist, is well suited to assist in this planning. In fact, if one were offered only one chance to get involved in a project from a Quality Assurance perspective, always choose to get involved in the planning of the project. No better opportunity exists to prevent quality problems and defects before they occur.
Project planning also depends, however, upon a thorough understanding of the purpose and intent of the project, including any underlying hidden issues, and the project manager, with a single focused view, is best suited to this need, which is why project management, as a function, could never be assumed by QA directly. The very qualities that make QA such a valuable resource to the project manager, are the qualities that would prevent QA from exercising effective project management.
As the project manager executes the project plan, QA is well situated, again through its thorough knowledge of the intent and purpose of the methodology, to assist in the control of project phase transitions, namely, determining that the requirements of one SDLC phase have been achieved, and agreed to by all involved, before a subsequent phase is initiated.
QA's cross-organization and cross-function perspectives make it invaluable in another area of process definition, this time in an area where its practitioners aren't particularly knowledgeable and experienced, namely, technical standards and guidelines. The vast majority of the staff of a large data processing organization are better situated to write some technical standard or guideline than is the typical Quality Assurance analyst to write any. However, what Quality Assurance offers to the picture is a non-biased view that is most likely to take the needs of the entire organization into account. As facilitator, guide, and explainer of the SDLC, the Quality Assurance function is well qualified to assist the organization in developing and adopting standards and guidelines against which an information system can be measured for conformance to those characteristics that the effected people in the organization value.
Quality Assurance continually monitors projects in this way, always working to assess the value and impact of the requirements of the SDLC, with an eye toward enhancing the methodology wherever and whenever shortfalls are spotted. QA always attempts to allow future projects to benefit from the experiences gained during existing and historical projects.
Through monitoring and reviewing project SDLC deliverables, shortfalls in the process can be identified and corrected before major problems result. As the environment changes, QA must be constantly aware of potential problems in the methodology that would effect projects. An SDLC can never be a static thing. QA must constantly be changing it to reflect lessons learned, changed organizational directions, new technologies and the business opportunities created by them, new approaches to old problems, as well as cultural changes that effect the organization and flow of a project.
A static SDLC quickly loses its appeal to the organization, and projects begin to invent their own means of accomplishing their goals. These individual, relatively uncontrolled, approaches tend to increase costs in the long-term, and directly impact the quality of the product produced.
Quality Assurance concerns itself with measuring and evaluating all of these costs within the information systems organization. The focus tends to be on identifying the relationships between the inputs to the processes and the outputs from the processes. This relates to the quality of the systems, as well as the productivity of the project teams that create them. QA attempts to track the quantity of functions that are produced for the users of the information systems being built. There is a growing trend away from measuring based upon the amount of technology used in the creation of the system; a number with no particular meaning when trying to assess value, and a number that is difficult to benchmark over time as the technologies being used change dramatically.
This minor controversy in measuring the outputs of a process is far overshadowed by the problems associated with the measurements of inputs to the process, the majority of which appear as labor time. In organizational cultures, that tend today to emphasize costs and schedules over quality, there exist disincentives to measure input labor time accurately. Project workers tend to be on fixed salaries organized against a typical 40 hour work week. Since compensation isn't tied to work time, and since an implicit objective is to look as productive as possible, the incentive exists to report no more than 40 hours per week, even if a typical week would actually exceed 50 or 60 hours.
When this cultural factor is coupled with the fact that this type of worker overtime is more likely to occur late in the project life cycle when work tasks are largely individualized, such as with programming and testing, as opposed to early in the life cycle when tasks are more group oriented, such as interviewing users and conducting analysis, it places increasing pressure on project management to reduce the time being spent in requirements definition and analysis in order to get on to the implementation tasks that are perceived to offer greater payoff per unit time.
With all of these measurement biases built into the environment and culture it becomes increasingly difficult to measure and evaluate the costs of implementing information systems. This makes it increasingly difficult to assess where QA should be focusing its effort to improve the quality of the overall process.
Along with increased difficulty, though, it becomes increasingly important that these costs be measured more accurately so that reasonable relationships can be identified between costs and quality so that the latter can be emphasized without completely disrupting the former.
This is the core problem faced by Quality Assurance professionals: If management really believed that the least cost approach was through the high quality processes, QA could act as guide and facilitator through the process. But because management doesn't really believe, QA is constantly placed in an adversary position of trying to coerce projects into concentrating on quality over costs. The fact that most management professes a belief in quality only makes matters more difficult since their actions clearly don't correspond to their statements.
For this reason Quality Assurance must constantly be promoting quality concepts within the organization. It involves an intensive effort to change the culture of the organization, often from the bottom up. As long as senior management continues to stress cost over quality, QA will need to continue to be active in keeping the quality discussion alive within the organization. QA will be successful when management sets organizational goals that include quality as a high priority.
Shifting the emphasis toward quality would allow quality work to be rewarded, and so quality work would be done. With management commitment, quality can become self-fulfilling, the more we have, the more we'll want.
This is what is so frustrating to QA specialists today, the fact that quality is the direct route to the most desired result and yet is perceived as one of the greatest obstacles. It represents a vicious cycle that, when broken by changing attitudes among organizational management, will eventually make quality the leading attribute of every successful organization.
QA organizations are often expected to perform QC activities. These activities, while necessary in the short-run, get in the way of the long-term activities of QA by consuming an inordinate amount of the allocated resources. And, because the QA effort is reduced, the need for QC fails to reduce over time, creating another vicious cycle. Unless QA can get out of the QC business to address the real problem, long-term management commitment to quality, the problems of quality will never go away.
This translates into a need for the QA organization to be placed into the larger information systems organization in a way that gives it the ability to resist the onslaught of tactical activity. QA benefits from reporting into the highest level management possible, for the higher the level of management, the less tactical the day-to-day perspective is likely to be. Lower level management will have too many short-term incentives to use the QA resources toward immediate tactical needs, as driven by cost and schedule perceptions. Functions that take years to provide payback are too easy to sidetrack for a few months for some shorter-term gain.
In practice, QA fights a constant battle against those who don't really believe that quality processes lead to quality products. QA must often coerce project staff to perform actions to which they don't feel committed, and that they would rather avoid.
It's a tough situation to be in. By the very existence of the QA organization, management can claim to be doing something about quality. By management's very actions, the role of QA is made ambiguous and difficult. It boils down to a problem that is rather simple to state, yet extremely difficult to solve: Management's actions need to be aligned with their words in such a way that workers will listen to the words as clearly as they react to their actions.
It's a tough problem, yet one that offers significant rewards to the individuals that take it on, and the organizations that see it through. And it takes a particular type of individual to take on such challenges. Individuals who believe strongly in quality, are extremely self-motivated, and can find rewards in indirect successes.
Once management comes to really believe that the quality way is the fastest and cheapest way, we will have entered a new era in data processing. Once practice is brought in line with theory, there's no telling what we'll accomplish.