Re: FW: Deming and software development and information quality

[Worthington.Jeffrey@epamail.epa.gov]

I have been spending considerable effort in the last year to both 
categorize and organize the issues related to "information quality" 
overall, of which software is a subset.  One observation, is that not all 
software development activity ensures the quality of the "information" or 
"data."  Many software development quality activities focus primarily on 
the testing of the software functionality.  What has really struck me 
about this situation is the popular notion that we are in the information 
age and the growth and development of the entire information industry, 
with only a limited focus on the quality of "information" itself.  Pure 
conjecture might be that this issue could be a root cause of business 
failures in this new industry.  The relationship between data and 
information and quality is based on at least four possible functional 
relationships between the enterprise and the information:
- information and data as a product of the enterprise
- information and data which supports product development
- information and data which supports the quality system
- information and data which is used by the enterprise to represent itself 
to its clients (internet, etc.)

This is a little complicated by the fact that you don't really need a 
computer to have an information system, computers are just the latest 
twist in the game.  In fact, as members of this discussion group know, 
information systems were the subject of Deming's work on the census.  All 
the same principles still apply of course; however, with the "database" 
approach and the move to electronic communications, many quality systems 
may not be robust enough to accommodate this new twist.

One useful method to divide the quality issues is to look at the following 
possible subsets:
1. data design (structure of the data itself, whether in a computer or 
not)
2. data production (development of data to populate the spread sheet or 
computer database)
3. data entry "collection." the entry of data into the system, there is a 
lot of quality experience in this particular area
4. database management - looking at the data in the system for it's 
overall consistency, etc. to meet the needs of use of the data
5. data distribution area - hardware, software, 
6. data/information delivery - reporting formats, webpages, outputs, etc.

I am confronting these areas professionally simply because the USEPA is 
either the owner or conduit for large quantities of "environmental 
information" which includes measurement information.  This is a curious 
situation because measurement information includes both the data value and 
associated measurement data (precision, accuracy, etc.) and then once the 
information moves into a "system," measurement of the information quality 
is measurement of measurement information.  Let's not discuss this, it can 
get confusing fast.

I am at the Annual Quality Congress now, we are fortunate to have 
attracted two knowledgeable authors of this general subject area and I 
recommend their books to any quality professional attempting to 
incorporate these elements into their quality efforts.  Larry English's 
book was recently translated into Japanese, and Tom Redman who has two 
books and also two chapters in the Juran handbook..  Larry walks through 
the Deming steps and discusses their applicability in his book.  Both are 
talking in a session tomorrow.  Another prolific author in this area is 
Mike Brackett.  MIT has done some work also.

An interesting resource for people who are actually measuring the quality 
of basic company information in databases is in the Data Managers 
Association of America (?) DAMA.  Also, the Statistics Division of ASQ had 
some topical information in their recent newsletter.  The COBIT process 
can be found on the internet which focuses on control objectives for IT, 
they do propose a process and measures, but you might have to check your 
quality credentials at the door to fully adopt their approach because the 
terminology is "spun" for convenience.

I don't know how close this came to answering questions about software, 
but if any are interested, send me a note directly and I will provide a 
matrix of possible measures for each area in my list above.  I don't have 
a great deal of historical measures that could form the basis for 
expectations of information quality and would welcome any hint toward 
other resources. 

The amount of "scrap and rework" in information system development is "off 
the scale."  I have seen very little direct measurements of the failure 
costs, but IT folks report general observations of failure of more than 
50%, the money is spent and the systems are not used because they are not 
really needed, or they don't interact with other system, or they cannot be 
easily modified to be used.  Can anyone think of a greater productivity 
failure in the history of US business?

A lot of the solution might be found in the "new" works of Spewak and 
Zachman who talk about "enterprise architectures" for information systems, 
similar to the architecture for a building.  This approach permits logical 
development of a quality system on a broader basis, not just for 
individual software systems.  I haven't seen too much discussion in the 
Deming group about these processes but would welcome all input.

Jeff Worthington
Director of Quality
USEPA Office of Environmental Information
202-564-5174