Intel IT research white paper Information Overload: Inaccessible Data and a Knowledge Management Solution (bold is mine)
Problem: lack of project data accessibility
Date collection: semi-structured interviews (questionnaire is included) with users of project documents at different organisational levels and job functions
Inhibitors of finding documents
- Many document repositories exist. “Different groups used these repositories in different fashions and without a consistent process for depositing documents in any of the repositories”.
- Lack of communication about “where the documents were stored and what other document repositories exist”.
- Current location of a document is not known.
- “Information was not well archived with proper revision controls, resulting in the original version of the documents often being inaccessible and sometimes nonexistent”.
- Documents are mailed around and not posted to a common repository.
- Users rely on finding people involved in the project to find project information. These people could be busy or hard to find.
- Documents could be too long to be useful.
Impact
- Waste of paper, disk space and time
- Rework because of (1) changed, but not communicated requirements, or (2) inconsistent interpretation of requirements
- “In general people tended to share information only at its end state, when it was ready for consumption, and not during discovery” -> duplication of efforts
- Searching results in a significant loss of time
- “The difficulty in accessing the right information created a new behaviour trend for some users: They sought out information in meetings”
- “When documents were not easily accessible, users could get only a snapshot of the environment unless they knew whom to ask. To resolve this problem, specific groups or projects established unique processes to address this problem”.
Findings
- User segmentation is number one priority
- Different user needs regarding depth of the document (management summary vs. data about reasons for a specific decision made before). Two user segments were identified: “technical expertise” and “support and environment”.
- “Interviewees rarely had an inclusive picture of the different ways the project documents were used”
- Proposed user segmentation for further investigation: role or job function, prior experience, geographical location.
Recommendations
- Understanding users with the proposed segmentation
- Improving finding documents
- Single repository with revision control and posting process + discipline to follow it
- Adding metadata to documents
- Improving finding information in documents
- Executive summaries
- Using knowledge discovery in databases (=summary extraction)
- Adding unique metadata tag to a specific piece (e.g. project requirement), so it’s possible to follow it through different documents
Hmm… It’s good as an example, but I wouldn’t call it “KM solution” :)
What is more interesting is look how people adapt to the situation: start relying more on meetings or on personal contacts. I guess that document searching behaviour should be studied together with informal communication (see public vs. private discussions), so at the end one can arrive to the solution that combines strengths of both sides.
Archived version of this entry is available at http://blog.mathemagenic.com/2003/02/19.html#a467; comments are here.Tags: information overload, knowledge mapping
Related posts