This is the thirteenth in a series of discussions of quality guru W. Edwards Deming's Fourteen Points of Quality and their ramifications for data quality. Here I begin describing Deming's quality point 9, "Break Down Barriers Between Staff Areas," a requirement for enabling sustainable data quality improvement. Next month I conclude the discussion of information quality point 9. How is it that a company could fail when everyone was doing a good job and no one in the organization was having problems? Simple. A new company president found that each business area, while working well, was "sub-optimizing its own work but not working as a team for the company."1 "People can work superbly in their respective departments ... but if their goals are in conflict, they can ruin the company."2
Deming's 9th point of quality states: "Break down barriers between departments. People in research, design, sales and production must work as a team to foresee problems of production and in use that may be encountered with the product or service.3 A fundamental principle of organizational effectiveness is that all parts of the organization work as a team toward organizational goals for customer satisfaction and not for departmental goals that may be counterproductive. The conflicting objectives between the order sales and accounts receivable departments cited in point 7 illustrate the tragedy of sub-optimization. Who was looking after the interests and concerns of the customers?
Teamwork is intradepartmental as well as interdepartmental. Teamwork requires those who have strengths to help compensate for those who may not be as gifted. It is in teaching and coaching that people sharpen their own skills. Unfortunately, most traditional performance measures incent competition among employees, not teamwork.
Peter Blau studied two groups of interviewers in an employment agency. One group had a cooperative mind-set. The second group had a competitive environment in which to fill job openings. The workers in the competitive environment tended to "hoard" job notifications instead of posting them as the procedure dictated. The first group shared information. By working cooperatively, they filled significantly more jobs than the competitive group.4 It is this group performance, not individual performance, that is the "clear index of performance."5 Unfortunately, in a system that puts employees in the position of having to choose between enterprise objectives and performance-based objectives, unless employees are independently wealthy, they will choose to satisfy the objectives on which their merit and pay is based.
Building quality applications and databases requires teamwork between application development and data resource management, along with teamwork with and between business areas. Yet the majority of today's application development projects are plagued by a lack of cooperation, a lack of involvement due to time pressure, conflicting objectives or competing organizational units. But most application development and delivery or package selection methodologies today virtually guarantee low-quality applications and databases because they do not define requirements across the team of information stakeholders throughout the business value chain.
Application Development Teamwork
Teamwork in application development must happen at three levels: 1) within the information systems organization; 2) between information systems organization and the business organization that is the primary beneficiary of the application; and 3) among business organizations that are ultimate stakeholders in the information produced by an application. Let's examine each of these.
Within Information Systems Organization: Teamwork means the data resource management group and the application development group must operate as a single team. Historically, there has been much conflict between these groups. The goals of application development tend to be to deliver applications that solve business problems quickly with minimal costs. The goals of data resource management tend to be to develop reusable information architecture, data models and databases that can be shared across the enterprise. The goals of speed for narrow application development projects conflict with the goals of defining information with consensus for reuse and shareability.
Whose goals are right? The answer is both are right--yet neither is right. Why? It is possible to build an application quickly, within budget and with quality in the eyes of the business area for which it is built. That same application may fail to add value to the end customer, increase customer satisfaction, help accomplish the real enterprise business drivers and have high reuse and low cost of subsequent maintenance. It is also possible to build shareable data models with quality in the eyes of the knowledge workers who use it. That same data model may fail to contain the kind information that adds value to the end customer, increases customer satisfaction, helps accomplish the real enterprise business drivers and has high shareability and low cost of subsequent maintenance.
Both application development and data resource management groups must begin any development project with two goals in mind: 1) what is the mission of the enterprise, and 2) who are the ultimate customers (internal and external) and stakeholders. The enterprise mission gives the team the context. Knowing the customers keeps the team focused on who they are serving. The list of customers must always include the external customer and ultimate beneficiary of the organization's products and services. If not, the application and database will invariably fall short of improving product or service from the real customers' perspective.
Between Information Systems Organization and the Primary Beneficiary Business Organization: Conflict between information systems and the business likewise assures poor application quality. The business often views systems personnel as "technoids" who have no comprehension of the business or ability to translate business requirements to usable applications with any kind of timeliness. Information systems is simply a necessary evil they have to deal with but avoid when possible. The evidence of this is all the private applications and databases knowledge workers have developed for themselves because they cannot get the information "support" they need to do their jobs.
On the other side, information systems personnel often believe the business people are incompetent and do not know what they want in systems. All too often, systems personnel do not understand why the "users" do not "like" the applications they develop and complain about what they feel are trivial requests for changes in their application of perfection.
The attitudes described here are real. They are symptoms of the real problem. The problem exposed here is that there is a limited sense of partnership or team relationship, and there is not a common stake in the outcome of the application and data development process. A partnership is something that is either win/win or lose/lose. With a customer/supplier support-only relationship, I can divorce myself from the consequences of the resulting failure and point blame at the other party. Win/lose or lose/win scenarios can--and frequently do--result.
The relationship between information systems (IS) and the business must not be a distant customer/supplier relationship. IS does not simply provide "support" to business areas. IS must be a partner with business in the common goals of transforming work and improving processes.
A partnership or team relationship is the only viable relationship between the business and information systems. Partnering in application development means that both information systems personnel and business personnel join ranks for the good of their mutual customers in the development of applications and databases. They both assume responsibility for the outcome of the effort. If it is a success they each can say, "We succeeded." If it was a failure, they each can say, "We failed." Neither group can say the other caused the failure.
The application development and delivery process cannot be delegated. Business units cannot "define requirements" and expect information systems to bring back a "quality" system. Application and data development can effectively be achieved only when business and information systems work together as a team to satisfy their mutual customers. Outsourcing of data architecture and core business application development reflects a "support" relationship view of information systems that places the enterprise at risk.
Among Business Organizations: Organizations may develop the first two team relationships well, yet produce low quality application systems and databases. A business area must see itself as a team with other business areas that "supply" information to it and with business areas that are "customers" of the information it produces. The failure of this business teamwork has led to the myriad of standalone, unintegrated applications and databases that consume an inordinate amount of support resources and threaten to cause business failure.
This legacy of unintegrated applications and databases directly results from organizations failing to apply Deming's quality point 9. Organizations that ignore point 9 are characterized by the "my application" or "my data" syndrome. Everything may appear to be working satisfactorily, but the business areas may be achieving their business area goals while sub-optimizing the enterprise goals.This myriad of redundant databases increases the costs of data warehouse initiatives that must aggregate data from disparate data sources to support strategic and cross-functional analytical processes."Is it management's job to help staff areas work together? To promote teamwork? Sounds great, but it can't be done under the present system [of management by objectives and individual performance measures]. In spite of the system, you will find teamwork. But when it comes to a showdown under the present system and someone has to make a decision--his own rating or the company's--he will decide for himself. Can you blame him? People work in the system. Management creates the system."6
Management must change the system of performance measures to incent teamwork. It must break down the barriers between organizational units to increase the desire to share information rather than to hoard it.
1 Deming. Out of the Crisis. P. 63.
2 Walton. The Deming Management Method. P. 72.
3 Deming. Out of the Crisis. P. 24.
4 Aguayo. Dr. Deming. P. 196.
5 Kohn, Alfie. No Contest. Houghton Mifflin, Boston. 1986. P. 52.
6 Walton. The Deming Management Method. P. 75.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access