Re: IT uses

From: John Conover <>
Subject: Re: IT uses
Date: Tue, 24 Aug 1993 00:50:45 -0700 (PDT)

John Conover writes:
> 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.) ...

Continuing on with the application of IT, I will present an example
usage scenario in the day to day operation of the IT system outlined
above.  To reiterate the way things are setup, all members of the
group (or team) have a mail alias set up in their project account that
includes their self, all other members of the group, and the group's
project archive. (It would be appropriate to think of this as an
ongoing electronic conference.) As things are discussed, decided,
scheduled, and finished, an email concerning any and all issues of the
activity will be distributed to all members of the group, and the
archive. (Don't forget that these electronic correspondences
constitute a "documented social commitment," on the part of the
individuals of the group, to the group, itself.) It would be
appropriate to think of the archive as a "library," where you do
electronic "literature searches" in the conference digests, for
various subjects concerning the project.

Take for example, project scheduling and tracking. The group chairman
(ie., project leader, team leader, group administrator, or whoever has
been assigned to be in charge of scheduling,) issues an email,
periodically (say, every Friday,) with a "Subject: Project Status
Milestones," (or whatever else) to all members of the group. As all
members of the group reply about the week's progress, (simply by
pressing the 'r' key in the standard Unix mail system, and typing the
response) the person in charge of the scheduling system can update the
master project status (either by a "cutting and pasting" the sections
out of the returned project status reports into a formal paper report,
or automatically updating the schedule database, if a "forms" manager
was used to compose the project status request.) There is nothing too
different from classical management techniques, so far.  It is very
similar to an automated MBO system, and fits in nicely with other
project analysis/tracking methodologies (ie., like Pert Charts, Gant
Charts, Critical Path, etc.) Its only advantage, so far, is that it is
efficient-quick and requires minimal time/overhead from the group's

The system differs slightly in that the original requests and
responses concerning project status are archived in a manner that they
can be retrieved, electronically, within a "context framework," in an
expedient fashion (perhaps by upper management, or the managers of
other related cross-functional departments who have a vested interest
in the status of the project.)  By this I mean that since all of the
project status reports are available on demand, (and can be collated
by a search of something like "Subject: project status something,")
the history of the project status from any previous date to the
current date can be put into "context" or "perspective," (by simply
reading the reports that were retrieved by the "context search.")
This is the part of the system that upper management would use to
evaluate the "state of affairs" in the project. (If the upper level
managers are "information junkies," the machines can be programmed to
issue the "context search" command, automatically, every night, so
that the managers know the exact status of every project, to the
day-every morning.)  What this really enables the managers to do is
"precision management" (a Texas Instruments'ism.) Again, this is not
too much different than using traditional management tools (just
significantly faster,) but note that this is not a traditional
bureaucratic process-in a traditional bureaucracy, the various
organizations that had a vested interest in the project would be
"re'd" with memos (usually on a monthly basis) of status reports
(which are written in the context of the project managers,) and spend
time attending staff meetings (to get a "better" perspective on the
project.)  However, in this system, if other managers have a vested
interest, they have to retrieve the information from the archive their
selves (and thus draw their own conclusions.)  It is probably a key
point that the nature of the bureaucracy has now been changed. It
would be appropriate to think of the electronic bureaucracy as one
that a manager has the option of subscribing/un-subscribing to
(dynamically) on what is considered an appropriate basis. And if a
manager's attention has been focused elsewhere, the progress (or lack
of) made in the interim can be retrieved at any convenient time.  Note
that the objectives are not to replace paper memos, or meetings.
These are still important instruments in the group's dynamics. The
objective is to offer a better means of information/knowledge
dissemination through the organization (both to and from the project
group,) so that meetings, etc. can be "quality time," as opposed to
wading through reams of "show and tell" project status reports.

Additionally, and this is another key point, if an issue comes up in
the project schedules, (slippage, etc.)  a manager can formulate
another "context search" for an additional retrieval, that addresses
the specific issues in question from the project status reports. Note
that if the use of the system is enforced, then there is no excuse for
project "execution failures," too many people would have knowledge of
the "program exceptions," and too many people would be documented of
having the knowledge. (The project may fail for other reasons, but
execution is not one of them-unless the managers are sloppy, and not
"watching the store," in which case their managers can formulate
appropriate "context searches" to check up how well the project is
being managed, and so on up the corporate hierarchy.) The important,
key point, is that everyone in the project's chain of command is
subject to accountability and scrutiny of the decisions they make.

As a side bar, note that it is not the objective to scrutinize a
decision itself, but how the decision was arrived at (and, hopefully,
all of that information is documented in the archive.) Was a decision
made with integrity? What was the "quality" of the decision? Were all
pertinent issues and interests addressed prior to making the decision?
Note that an external, and presumably unbiased (ie., without parochial
interests,) source could retrieve this information from the archive
(or have it retrieved for them) and form an opinion on the
appropriateness of the decisions, and decision making process (with or
without the knowledge of the people involved in the project.) This is
the traditional realm of OD or TQM organizations (who, presumably,
would monitor such things, "real-time," and keep upper management
appraised of effectiveness of the project's management-these
organizations have no responsibility or authority in what was decided,
but only in the way that it was decided.)  Note that this,
potentially, presents a means of enforcing the use of the system-the
system would be used as a significant source of information-by,
perhaps, a disinterested party-in the determination of promotions,
bonuses, etc. and fits in nice with the current concepts of "quality
management."  It is an important, key point, that the system fits in
nicely with the more contemporary management schemas. As the decision
making process is pushed down into a modern, flat organizational
structure (ie., "empowerment" is a fashionable term and "down sized"
is the reality,) this type of system is probably the only way that
management can "stay in touch" with the decision making process.  It
is also probably the only way that management can exercise any sort of
policy influence over the way the organization makes its decisions
(which will be well below upper management, hopefully.) As a
conclusion to this side bar, observe who is the audience of the
author(s) of the "library" (think about it, it is the other team
members and program monitors) which could conceivably evolve into a,
largely, self directed management structure-ie., an organization that
does the most, with the least, the quickest. (The keyword here is

Probably the system's greatest benefit can be realized when the group
(or team) consists of cross-functional personnel. Here, as an example,
Marketing would be responsible for doing media searches for pertinent
data and opinions (and placing it in the project archive where it
would be available on demand to everyone with a vested interest in the
project.) Ditto for Sales, who would be responsible for making sure
that interests of the customer base was represented in the group's
decision making process.  And so on for the other functions
represented. Note that the document that defines the various
responsibilities of the functions should also be in the archive
(because someone may want to retrieve that piece of information,
someday.) The objective of the system is to integrate all of the
cross-functional issues in a concurrent fashion. There are no excuse
for engineering designing something that manufacturing can't make and
marketing can't market because sales can't sell it, because the
customer doesn't want it, or understand it.

Note that at this point, each of the cross-functional organizations
must go "on record" as committing to "this is what we want to do,"
(ie., an agenda has been determined.)  (This commitment is something
that upper level management will be monitoring the system for as a
necessary prerequisite for project sponsorship. They will probably
have to intervene, in the interest of expediency, to circumvent the
forestalling of the functional organization's parochial interests.) At
this point, we have an agenda, a buy-in from the functional
organizations, and a sponsor, and it is all documented and subject to
retrieval at a moments notice-which will be of use in the project's
execution phase when directions become de-focused and the functional
organizations renege on their commitments. (Like it or not, the
reality is that these two things happen all too frequently-I have
never been involved in a project where these two things did not
happen, to a more or lesser extent-sometimes with disastrous

I used the example above of schedule/milestone tracking, and how it
relates to the social infrastructure of the organization, and how it
can be monitored in an electronic "bureaucracy." By no means do I
imply that this is the only organizational process that needs to be
monitored in the archive. Another of the advantages of the proposed
system is to be able to relate organizational processes. For example,
resource "burn rate" should be monitored (time cards should be
electronic, also-which are an email into the archive containing the
number of hours spent, during the day, on a certain task.) Now the
"context frame" can be changed to include milestone progress, AND the
cost of development to obtain the milestone. And so on.


John Conover,,

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