From: [email protected]
Date: 2018-03-12
Subject: Reading John Conover

I found a very interesting article by John Conover about the ratio-
nale behind the development of rel, a "full  text  information  re-
trieval  system."  [1] What struck me was that he describes a solu-
tion to a number of problems that I encounter every day,  and  he's
writing  in  1993.   That was 25 years ago.  He describes a project
management solution for use within corporate environments, a system
which  will "contain a complete play by play chronology and history
of all decisions, and reasoning concerning the project."  [2]  More
abstractly, the system provides stakeholders with a "context frame-
work" that aids in the retrieval and  interpretation  of  otherwise
disparate pieces of information. [5]

The solution he describes is based on email, augmented with sophis-
ticated full-text search tools.  Using email  as  an  aid  in  task
tracking,  especially across groups, sounds like a nightmare.  How-
ever, Conover is talking about  a  central  email  repository.  [5]
Email,  in  this scenario, is a shared repository where all project
decisions and associated activity take place, and  from  which  all
reports are drawn. [2] It is the source of truth for project status
information.

For a little historical context, Altavista was launched at the  end
of 1995.  In 1993, email must have looked like the next frontier; a
robust platform upon which to build business applications.  I think
it's  likely  that  a lot of expectations that were placed on email
were later redirected to the web.  We tend to  think  of  email  as
distributed because that's how we interact with and manage it, even
though it is stored centrally.  We don't have access to  each  oth-
er's  email in the way that would be required for the described so-
lution to work.

After 25 years, have we really not solved these problems?  We have,
in  fact, solved many of them, just not using email.  After another
reading, I found that a lot of the tactics  Conover  describes  are
implemented  within  agile/Scrum-oriented  project management tools
such as JIRA, Pivotal Tracker, and Team Foundation  Server.   These
tools  provide  the  "context  framework"  within which various and
sundry pieces of project-related information  can  be  meaningfully
interpreted.  They provide schemas and metadata that enable queries
and structured reports.  With this in mind,  we  can  take  another
look at his key points.

Conover says,

    "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." [2]

Conover  also  describes  the  system as "a very fast, dynamic, MBO
[management by objectives] scheme" which sounds a lot  like  Agile.
[2]  Part of the reason that tools like JIRA, PT, and TFS have made
so much progress in realizing the solution that John  describes  is
that  they  are  process-aware.  They take Scrum as their model and
organize information in those terms.  They define how each piece of
information relates to the project by enforcing a predefined schema
(e.g. User Story, Task, Comment).  Even so, there is much to aspire
to in what Conover describes.

There  are  some really cool features of Conover's solution that we
still lack today, and that I, personally, would like to see  devel-
oped.  First, I would love to use mailing lists at work to separate
the "main stream" of communication from  side  conversations,  tan-
gents, and speculation. [3] I believe that project management tools
serve this purpose, but a mailing list would be more  effective  at
making  this  conversation visible and accessible.  I like the idea
that "a manager has the option  of  subscribing/un-subscribing"  to
information that is appropriate to them." [3] Also, archives.

Even  with  our modern tools, the automated nightly reports Conover
describes might only contain user story and task-level  status  in-
formation, and I'm not convinced that this would provide actionable
insights on its own. [3] Whether this system is based on  email,  a
web  application, or a spiral-bound notebook, its users are respon-
sible for putting relevant information into  the  system.   Another
requirement  is  the  exercise of incredible discipline by users of
the system.  Users must take care to enter  all  possibly  relevant
information into the system with an eye toward how that information
might be consumed.  Another challenge is in  filtering  the  signal
from  the  noise.   We rely on people to determine what is relevant
and enter it into the system in a meaningful way.

The development of best practices in this area is a worthwhile  en-
deavor,  and one that has much in common with the tradecraft of in-
telligence analysis.

References

[1]: http://www.johncon.com/john/correspondence/930812094217.1631.html
[2]: http://www.johncon.com/john/correspondence/930817080048.3609.html
[3]: http://www.johncon.com/john/correspondence/930824075159.5941.html
[4]: http://www.johncon.com/john/correspondence/930827081444.9503.html
[5]: http://www.johncon.com/john/correspondence/930914085306.2173.html
[6]: http://www.johncon.com/john/correspondence/930914104310.2391.html