From: dbucklin@sdf.org
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