[1087] in magellan
Knowledge Base Discovery Project Report -- Aug/Sep 2003
daemon@ATHENA.MIT.EDU (smyser)
Fri Oct 3 15:26:48 2003
Reply-To: <smyser@MIT.EDU>
From: "smyser" <smyser@MIT.EDU>
To: <magellan@mit.edu>
Date: Fri, 3 Oct 2003 15:26:44 -0400
Message-ID: <001401c389e4$47b92290$20029812@soprclar>
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 8bit
August/September 2003 Status Report
Project name: Knowledge Base Discovery Project
Project leader: Rob Smyser
Web URL: http://web.mit.edu/is/discovery/kb/
Accomplishments past period:
1. detailed demonstration by Oliver Thomas of RT and RTFM. Some key
findings from the meeting minutes include:
- The ability to convert a help desk ticket to a FAQ is a real strength.
- The search function isn't that strong.
- Work flow is probably more of a process issue than a technology issue.
- We should consider taking advantage of this product's best features, and
dump the output into another content management system.
- What more does this product offer than Kevin's system?
= more scaleable
= more stable
= Web front end
- Content isn't reusable.
- Lack of cross-referencing is a problem.
- If Support adopts RT, some development work will be involved; maybe our
desired features could be included in that work.
2. detailed preliminary exposition of the team's findings -
A homework exercise prompting people to write an essay in response to the
following question:
Given everything we've seen and learned about over the last months,
what should IS do about the knowledge base situation? Why?
If there is more than one acceptable alternative, what is the
order of preference, and why.
The responses were emailed to the team; everyone remarked on how cogent and
heartfelt were the responses. Rob merged the emails around emergent themes
and redistributed that summary. The team was struck by the fact that they
had basically reached a conclusion and all that was left was to write it up.
The essential conclusion is to build on RTFM to turn it into RTKB.
3. Interview with Ken Dietel of Duke about DUNK.
Learned that they opted for Serviceware years ago, both for its connection
to Remedy and its packages of pre-prepared content about standard products.
In use, the most-browsed content was that which they wrote themselves about
issues unique to Duke; the prepackaged content is hardly browsed at all. In
retrospect they should not have licensed it; the license terms prevent their
KB from being reached from off-campus IP addresses, which has not been a
good thing.
4. Discussion of the strategic path to take with preliminary results, with
Sponsor and Casetracker MiniDiscovery team leader
Concluded that a nice synergy was possible if the Casetracker group ended up
choosing to go with RT and we could recommend building on RTFM. The
essential conclusion here was that we could have a win-win if the RT and
RTKB development projects could be merged into one project with a shared
goal of getting it done in January 2004.
5. Received detailed proposal from NetSol, whose product is Altvia KBMS.
They'd like to build us a system for $37500 delivered onto our own hardware.
This represents a substantial discount from their already low,low pricing in
return for being part of a Technology Council that would constitute a
"partnership" in furthering the development of their KB tool. Very
attractive offer, nice product.
Goals for the coming period:
- Finish the report. Circulate, bless.
Next community milestone:
None planned
Issues:
Efforts are moving forward in the tools space within Support, even though
the report and thus the project is not really finished.
Key learnings:
The report has the opportunity to explain the required people-structure and
perhaps propose a content-structure needed in a successful muli-departmental
KB system.
Team dynamics:
Additional comments:
