From: John Conover <john@email.johncon.com>
Subject: Re: IT uses
Date: Tue, 17 Aug 1993 01:00:27 -0700 (PDT)
John Conover writes:
>
>
> Let me explain what I am doing with the archive/retrieve/info programs
> that are being developed...
>
Allow me continue with an application of IT, specifically to
program/project management, ie., a "how to" application. This will
make use of the email system to hold asynchronous group conferences,
and the archive/retrieval system to document the activities of the
individuals in the group (or team, if you prefer.) Or in other words,
the email system will be used to decide/communicate what is going to
be done, who is going to do it, and when. The archive/retrieval system
will be used to document what was done, who did it, and when it was
finished. It will exploit the self documenting capabilities of email,
to establish accountability and responsibilities for the activities
addressed by the group. (BTW, what we call email is, technically, not
an email system at all-technically it is an "asynchronous electronic
conferencing system," or AECS, for the record.)
Let me first address the semantics, to avoid confusion. There are two
essential semantic definitions that concern us. The first is the
difference between supervision and management. The other is the
relation between information, knowledge, and capability.
The difference between supervision and management is that supervision
is the administration of pre-defined activities (usually handled by a
supervisor or foreman.) Management, on the other hand, is the
intellectual process of deciding/defining what activities are to be
executed (and in what order, etc.) Obviously, intellectual processes
are closely related to information/knowledge/capability issues.
Knowledge is information in context. Knowledge in context is
capability (capability being defined as knowing what to do.)
Capability is the the objective. This is a key point. For example,
corporate databases (technically "content databases,") can provide
information on the status of the company, but they can not provide
insight as to why the status is the way that it is-that is left to
interpreter. To do that, you have to put the information in context,
or perspective. Once you have the established the perspective (ie.,
gained knowledge,) then you can proceed to decide what must be done,
and how to do it (ie., establish an agenda, or a capability.)
Although this application has an electronic database, it differs from
content databases in that the context, (or acquisition of
perspective,) phases of interpretation are automatically documented
and, therefore, subject to scrutiny (through context framed
searches)-ie., it automates the documentation of the decision making
process. Note that this directly relates to OD and TQM issues.
Although the concept is consistent with contemporary management
principles, a word of caution is in order. The system documents
appropriate and inappropriate decisions with equal impunity. It is
important to realize that it is not a question of whether a decision
was "bad" or not, but whether it was made intelligently (ie., the
"quality" of the decision is the issue.) Since this is a "perspective"
issue, it is important that all decisions be rationalized within the
system so that context searches can be initiated to discover the
perspective under which the decision was made. Maturity and
objectivity is order when judging the appropriateness of a decision.
In an ideal sense, the database contains a collection of the "point of
views" (POV) of the participants. The system "brings together" these
different view points so that management can reconcile appropriate
tactics and strategies (ie., activities) that make up an agenda.
It is important to understand that the essence of the system is that
it documents the process that a decision was arrived at, and not the
decision itself (although it does that too.) It is equally important
to understand that discipline must be enforced in submitting all of the
justifications/rationalizations for all decisions into the system. It
is a key point. Bear in mind that the system is not for the timid or
weak. When you submit a POV to the system, you are going on record
as saying "in my opinion, we should consider..."
With these issues in mind, I will present "how to" implement and use
such a system:
1) Management decrees that the system would be used as a
management tool, and all data has to be entered, or
transcribed into the system (including the minutes of
meetings, etc.) If it doesn't exist in the system, it does not
exist. All discussions, and reasons for decisions have to be
placed in the system. ALL team members and upper management
(across functions) have identical access to ALL transactions.
(Mail can be used for private correspondence, such as
politicking, etc. but all decisions, and the reasons for the
decisions have to be placed in the system.) The guiding rule
is that at the end of the project, the system will contain a
complete play by play chronology and history of all decisions,
and reasoning concerning the project, and, by the way, who was
responsible for the decisions. On each Monday, everyone enters
into the system, his/her objectives for the week, and when
each objective was finished, she/he mails the milestone into
the system-ie., all group members and management can thus find
out the exact status of the project at any time (ie., a
"social contract" was made with management and the rest of the
members of the team.) At any time, a discussion can be
initiated on problems/decisions in the system by anyone. The
project manager is assigned the responsibility of "moderator,"
or chair person for his/her section of the system. Each
Friday, the system is queried for project status, and the
status plumbed to a text formatter, and printed for official
documentation. This document was discussed at a late Friday
people-to-people staff meeting. (Note that in some sense, it
is similar to a very fast, dynamic, MBO scheme.)
2) Marketing is responsible for acquiring all pertinate data
on magnetic media, (from services like Data Quest, the
Department of Commerce, etc.) and each document is "mailed"
into the system so that the information is available to
everyone. They have access to the progress made by
engineering, and can contribute information on pertinate
issues as the program develops-ie., this is a "concurrent
engineering" environment.
3) Engineering is responsible for maintaining schedules, and
reflecting those schedules in the system-if slippages occur,
then the situation can be addressed immediately by management,
and a suitable cross functional resolution can be arrived at.
and so on for the other teams involved in the project.
--
John Conover, john@email.johncon.com, http://www.johncon.com/