IT uses

From: John Conover <>
Subject: IT uses
Date: Thu, 12 Aug 1993 02:41:46 -0700 (PDT)

Let me explain what I am doing with the archive/retrieve/info programs
that are being developed. I am attempting to automate a lot of project
administration/execution. Let me tell you why. I will cite the failure
of IT at General Motors, (IBM is a similar failure,) as a reason to
not do it the way they did.

In the mid 80's, GM decided that IT was the way to go. It purchased
EDS from R. Perot, made Perot a bigshot manager, and put a terminal on
all of the middle managers desks (all 18 levels of them.) After an
outlay for direct expenses totaling billions of dollars, and untold
fortunes in indirect costs (training, lost data because some pressed
the wrong button learning to use the system, etc.) nothing really
changed. The org. was still a clumsy, bumbling giant that could not
get out of its own way. This is a classic example of how not to
automate admin. If you stand back and look at why the GM
implementation was a failure, you can see that the problem was that
although they automated memos (and did away with paper) the decision
process that determined the organization's agenda was really the
issue-and they did nothing to enhance the efficiency of that. (A key

Let me elaborate. Consider that the IT system at GM reduced the time
of a memo to be routed from 2 days to seconds. But the action required
to address the issues in the memo still required months ... well you
get the picture. The GM admin. was/is a marvel of efficiency. Look at
it this way. (The numbers quoted above are real numbers, BTW.) 60 days
divided by 18 levels of management, means that each level responded to
the issues addressed in a memo in a little over 3 days, including week
ends and holidays-very impressive (GM was proud of these numbers.)

The question is, how do you speed up things, and still maintain order
and control of agenda in a large organization.  Obviously, the number
of levels of management must be reduced. But if you eliminate some of
the levels of management, who is going to control/administer things?
Who is going to enforce the discipline of a consistent and continuous
agenda?  Won't important things fall into cracks?  The answer is yes.
(BTW, this number of levels of organization is justified at GM, they
actually, really do, need this many levels to coordinate things.) Note
that the flow of information in management was not the issue (GM's
failure proved that.) GM addressed the wrong issue, and obviously,
other organizations, irregardless of their size, have the same issues
to address.

IT must address the issues of agenda/project execution, and the
decision making process (as opposed to being an information provider.)
This is an important concept. Let me elaborate on this.

The traditional reason for memos is the formal documentation of the
decision making process-who decided what and for what reasons.(Memos
have nothing to do with communication-they are inferior to the
telephone-in all respects-except documentation.) The reasons that we
document the process is for accountability, so we can hold the
decision makers responsible for their decisions-and make sure that
the decisions are executed appropriately. Or to put it in other words,
really what we are doing is preserving a paper posterity, or history,
that we can do a literature search on in the future, to put into
perspective, the organization's agenda. But this can be done
electronically (which is a key point.) It is the organizational agenda
that is the issue, and NOT the information that flowed in the
execution of the agenda.  It is a subtle difference.

The way that you put into perspective what is going on in an
organization, is to search the communication flow for context (ie.,
agenda,) and not for content (ie., information.) This is a key point.

If we make a corporate archive (perhaps distributed throughout the
organization,) that contains pertinate information on all the
decisions that are addressed (ie., an email database archive) in the
organization (ie., we store the information,) AND, we permit realtime
automated literature searches of the database, (ie., we can put the
information into context,) then we can do the same thing-just with
incredible efficiency. (BTW, by context literature search, I mean a
full text retrieval system-one that can be cross-indexed, and collated
on demand.)

The archive/retrieve system that is being developed is such a system.
In point of fact, if you use the archive/retrieve system on machine
"john" you can see the thinking that lead to me writing this. (As a
simple example send an email to, with a
Subject: retrieve lapyun.) Kind of neat when you think about it.


John Conover,,

Copyright © 1993 John Conover, All Rights Reserved.
Last modified: Fri Mar 26 18:59:00 PST 1999 $Id: 930812094217.1631.html,v 1.0 2001/11/17 23:05:50 conover Exp $
Valid HTML 4.0!