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