© 2000 James A. Ward, www.jamesaward.com
Reprinted from Information Systems Management, Auerbach Publications, Summer 1994.
Total quality management is a commitment to the continuous improvement of work processes with the goal of satisfying internal and external customers. It’s the customer that matters in TQM; the process is only the means to satisfying the customer.
Customers are only satisfied if their requirements are consistently met. To be competitive, we must meet these requirements in a timely and cost effective manner. TQM provides the organizational focus and mind set, as well as specific tools and techniques, to ensure meeting customer requirements, first time and every time.
A key principle of TQM is intense focus on customers and their satisfaction. What does this mean and how do we go about accomplishing it? We can use three principles in creating this focus.
Customer focus
First, I.S. must identify, measure and "design in" the product and service attributes that the customer cares about. How do we know what these attributes are? As a start, we can certainly ask the customer. However, this is only a start. Organizations which have become adept at TQM are able to go well beyond asking the customer to anticipating the future needs and desires of their customers.
Second, we must continually monitor customer satisfaction. The only determination of "quality" that really matters is the customer’s perception. Customer feedback and participation in the process is essential. Formal and continuous monitoring will keep the organization focused.
Third, management must make sure that everybody knows their customers, both internal and external. Further, it is essential that everybody can "see" the ultimate customer using their products and services. Employees at all levels of the organization should be given opportunities to observe the customer using their products and services. All employees should understand how each process used in producing products and services adds value for the customer.
If these three principles are understood and applied at all levels of the organization, the customer focus will be pervasive.
Levels of customer satisfaction
Customers, both internal and external, have basic requirements which must be satisfied if they are going to do business with your organization. These represent the absolute minimum that must be done.
Beyond that, customers have expectations, both expressed and implied, that must be met if they are going to desire to continue to do business with you.
Top notch, or "world class" organizations, delight their customers by consistently exceeding both requirements and expectations. This then becomes a continuous process as each level of performance creates higher expectations.
It is extremely gratifying and rewarding to be associated with an organization that consistently delights its customers.
Applying TQM to information systems
To successfully apply TQM to I.S., we must concentrate on three things:
Identify all our customers, both internal and external.
Define customer requirements and expectations.
Deliver information products and services which meet, or exceed, defined requirements
Who is the customer?
You cannot invest too much time in learning about your customers.
Customers for an information system are many and varied. They include, of course, those individuals who directly use the system to perform their work tasks. These are the "users," and are normally easy to identify. For example, clerks in the Personnel and Accounting departments are users of a Payroll System. For TQM purposes, all users are customers.
Those in management who authorize, request, budget and approve information systems are customers. Without their participation, there would be no systems work to perform. These individuals are most often different from the users of the system. Many levels of management may need to review and approve the decision to implement a new Payroll System, and while they may never interact directly with the system, they certainly have requirements.
Many customers may receive outputs from an information system. These are indirect customers, and they may have very specific requirements. Employees receive their paychecks from a Payroll System. Government agencies have requirements for a Payroll System, as do banks, auditors and providers of employee benefits, to name just a few.
Those individuals who must operate and maintain a system are also customers and have specific requirements. These are internal customers whose requirements must be met if they, in turn, are to meet the requirements of their customers. The computer operator must be able to accurately print paychecks and payroll reports if the requirements of users and employees are to be met. Likewise, the maintenance programmer must be able to implement necessary changes over time if the Payroll System is to continue to meet the needs of other customers.
For most systems, the organization’s external customers are at least indirect, and increasingly direct, customers. Strategic systems and systems which have direct external customer interface, such as Electronic Data Interchange (EDI) in Purchasing or Order Processing, impact the external customer. Vendors of information systems and services constantly interact directly with external customers.
The I. S. organization must be thorough in identifying all potential customers for an information system if they are to have any possible chance of meeting customer requirements.
What are the customer’s requirements?
This is the area which often presents an insurmountable hurdle to implementing TQM in Information Systems. Defining customer requirements is usually the most difficult task we face.
How can I. S. professionals be expected to meet customer requirements, first time and every time, when no one, including the customers, knows exactly what these requirements are? Many systems development professionals believe that TQM simply cannot apply to them. They never develop exactly the same system twice. They believe that "Zero Defects" is totally unrealistic.
I once had a sincere Programmer/Analyst tell me: "You never know what the user’s requirements are until you get into the testing phase, so the thing to do is code something and see what happens."
Fortunately, TQM offers tools and techniques which can be used in conjunction with sound systems analysis work to assist us in properly and completely defining customer requirements.
How do we ensure that requirements, once known, can be met?
The only method which produces quality information systems on a consistent basis is a "Life Cycle" approach. In our last column we discussed those stable, measurable, repeatable processes which must be in place to ensure quality in systems development and maintenance. Lacking these processes, meeting customer requirements is a pure crap shoot. Sometimes we will win, but more often we will fail. Worse, there is no way to predict what the result will be on our next project.
Defining customer requirements
Why are information systems requirements so difficult to define? Why do documented requirements often turn out to be not even close to defining the system which ultimately gets implemented?
There are two major reasons why requirements definition is so difficult. First, the customer/user may have only the vaguest idea of what an information system should look like prior to actual implementation and use of that system. Second, system developers commonly lack sufficient knowledge of the business functions a system must support to define how the system must be configured.
This dilemma is usually addressed by developing systems which automate the organization’s currently existing manual processes.
The problem with this approach is that automation of manual processes does not add significant value nor make use of the greater capabilities of information technology. Worse, where manual processes do not exist or are poorly understood by the users, systems efforts commonly fail to produce usable results. This historical approach to systems development goes a long way to explaining the need for the massive reengineering projects we see in many organizations — finally we are beginning to truly leverage information systems to improve business processes.
Requirements definition is so important and so difficult. How can we make this process easier and less error prone?
Know your markets
Organizations with mature TQM functions have become proficient at satisfying and delighting customers. They invest a great deal of effort in learning about their customers. They work with customers on joint problem solving teams. They participate with customers in product design and development. They conduct extensive surveys. They have excellent intelligence about their competitors. They are aware of their customers’ strategic direction.
You cannot invest too much time in learning about your customers and the business. Information Systems organizations have been too isolated from the mainstream of the business enterprises they serve. I. S. management cannot be concerned primarily with technology if they are to meet customer requirements.
Obtain theoretical business knowledge
In his book, Rethinking Systems Analysis and Design (Boston: Little, Brown and Company, 1982), Gerald Weinberg talks about the time it takes someone who knows nothing about a field to amass knowledge comparable to that of an entry level graduate student in that field. The period is somewhere between one to three months.
You can’t develop good inventory management systems if you don’t know inventory management. You can’t develop good accounts payable systems without a knowledge of accounting.
Do not assume that your customers/users possess this theoretical knowledge. As W. Edwards Deming, the most famous of the quality gurus, has said, "Experience teaches nothing unless studied with the aid of theory." It is very often sad and dismaying to encounter the absence of even basic theoretical knowledge among practitioners about the business functions they are involved in every day of their working lives.
Study existing systems.
Use existing systems as a starting point in developing requirements for a new system. Analyze the system to be replaced, but also include other systems. These may be systems you have worked with in the past, systems available from vendors, systems used by competitors. The best analysts can see similarities between systems used for different business purposes and extrapolate these to apply to the existing environment.
Analyze the using environment. The most logical and complete method for obtaining requirements is from a complete analysis of the environment within which the system must be used. Observation of this environment, and, if possible, actual working experience in the environment will be invaluable in developing information requirements. However, this is true only if the analyst comes to this task armed with sufficient knowledge of the business, theoretical understanding of the business functions and familiarity with existing systems (as described in the preceding paragraphs).
Interview customers/users.
The junior analyst typically begins by asking the customer/user what is wanted. Analysis very often stops at this point. In 1975, I delivered a speech at an Information Systems Conference where I discussed promoting Programmers to Analyst positions. I used an example of the Analyst who was proud to be able to code the solution before anyone had defined the problem.
Interviews should not take the course of asking customers what they want. They should be used to mutually define problems and opportunities for information technology application. Discuss problems with users. Clarify issues which were identified in observing the environment. Make suggestions and observations based on theoretical knowledge and familiarity with other systems. Get users to talk about their jobs – the challenges and opportunities of their business functions. Interviews should therefore take place well into the requirements development process.
Prototyping is a fall-back position in requirements definition, not the answer in and of itself.
Prototyping. Prototyping seems to be all the rage just now. It can be the latest and greatest way of avoiding the previously described analytical work, allowing the Analyst/Computer Technician to work more with the computer than with the business functions. Tools, techniques and methodologies are always very poor substitutes for business knowledge during requirements definition. This is true of Structured Analysis, Rapid Analysis, JAD, as well as prototyping.
Prototyping is most useful in an environment where no one knows the answer. Where a model does not exist for a system, where theoretical knowledge is lacking (because for whatever reason it is unobtainable) or where the environment in which the system must operate cannot be observed (because presumably it does not yet exist), the analyst, in conjunction with the customer, must fall back on an iterative approach to information systems requirements definition.
Always be aware that early attempts are likely to miss the mark. Don’t be dismayed by repeated failures and throwaways. After all, you are sailing in uncharted waters. If this weren’t true, you wouldn’t need to do the prototyping.
We are fortunate to have software tools available that allow us to build prototypes and mock ups quickly and relatively inexpensively, thereby supposedly avoiding the expensive systems development fiascoes we have built in the past. However, two cautionary notes in using prototyping.
First, just because you can prototype something doesn’t mean you can build it. Last year, I worked on TQM principles with a software firm that introduced a prototype in 1989. Customers went wild. This was totally new, it would revolutionize a whole segment of their business.
The software firm budgeted one year and $1 million to turn the prototype into a working system. Three years and almost $4 million later, they still had not delivered a satisfactory system. The firm lacked the system development methodologies to ensure that they could develop quality systems once they had a defined prototype.
Second, resist the prevalent trend to use prototyping as a substitute for business knowledge, analysis of existing systems, analysis of the business environment and user interviews. Prototyping is a fall back position in requirements definition, not the answer in and of itself. Sure, to the computer technologist, prototyping is a lot more fun than studying inventory management, accounting, production control or other business functions. Maybe we should consider others for the job of requirements definition.
Summary:
How TQM can help TQM tools and techniques can be invaluable in the analyst’s arsenal when developing information systems requirements.
TQM provides a basis for a common language in problem definition and problem solving. Concentration on elimination of root causes of problems and on such TQM concepts and team building, empowerment and continuous process improvement can ensure that information systems address the "true" customer requirements rather than slap a band aid on symptoms of problems. These TQM tools are tremendously powerful in getting all parties to focus on the requirements of the business and its ultimate customers.
When applied within the Information Systems function, TQM can help the organization maintain the focus necessary to ensure that systems, as developed, meet customer requirements first time and every time. Continuous process improvement, constant feedback, elimination of the cause of errors make the process visible and responsive. Work which is not directed at meeting customer requirements can be identified early in the systems development process and corrective action can be initiated.
Applying TQM to the system development process can produce immediate and dramatic dividends. Start by identify all your customers. Then ensure that customer requirements are completely defined, understood and agreed upon. The process of developing systems which meet customer requirements will not be easy, but it can only be undertaken once we know what those requirements are.
TQM is not a program or a methodology. It is a philosophy of doing business. Fortunately, TQM also provides enabling tools and techniques which, when consistently applied, ensure that Information Systems organizations can meet customer requirements — first time and every time.
The author
James A. Ward is an independent consultant specializing in systems development project management and implementation of TQM. He can be reached at (201) 656-7886 or soozward@bellatlantic.net.