A Reflective Practitioner’s Confessional Account
Of Developing A Knowledge
Inventory: A Grounded Methodology
Paul Jackson, Edith Cowan University
ABSTRACT:
Knowledge mapping is a fundamental step in any knowledge management
initiative and seeks to identify ‘what an organization knows’ in
order to leverage it to greater advantage. This article explores a single
knowledge mapping project conducted by the author for a local government
authority from the perspective of a reflective practitioner. Using the tools of
hermeneutic inquiry, it initiates and performs the project with as few
preconceptions as possible, in order to identify a minimum set of actions and useful
heuristics for the conduct of a knowledge mapping project. These are presented
as a mini-methodology accompanied by insights, which may be of particular use
to small or medium sized organisations.
INTRODUCTION
This research addresses the discipline of knowledge mapping, which is a task performed within the general rubric of knowledge management. The trigger for this research was the opportunity to perform a knowledge mapping consulting project as part of the execution of a knowledge management strategy. The subject is a medium sized council shire. The council has implemented a suite of business improvement practices and a component of this improvement revolves around making more effective use of information and knowledge. One of the early steps in this process is to discover and list ‘what the organization knows’. I, the researcher (a new university teacher and industry consultant with twenty years of IS experience) was engaged to conduct the work.
THEORETICAL OVERVIEW
The general requirement confronting knowledge management is to identify, catalogue and then provide access to organisational knowledge such that it can be easily stored, found, used and enhanced (von Krogh and Roos, 1996;Leonard-Barton, 1995; Davenport and Prusak, 1998; Boisot, 1998; Bukowitz & Williams, 1999). Central to knowledge management is the notion of taking inventory of stores of organizational memory and mapping these in some diagrammatic or sortable list form to provide clarity and gain intellectual mastery over knowledge stocks and how they are related to each other (Vail, 1999; Nissen et al, 2000; Hansen et al, 1999; Kim et al , 2003 ). Knowledge maps can be used to match a business need to an identified knowledge repository via a knowledge management system. Knowledge management solutions include such technology as forums, databases, organisational ‘yellow pages’ and knowledge bases (Alavi & Tiwana, 2002). These solutions can be grouped and made available to match the work patterns of knowledge workers in what the Gartner Group calls ‘Smart Enterprise Suites” (Gartner Report AV-17-7196, 12 November 2002). Non-technical management initiatives can also be implemented based upon a knowledge map by identifying areas of special expertise and leveraging these more effectively.
Gathering and categorizing of knowledge can be performed in a number of ways, with a methodological lineage that can be traced to classic business analysis and data modelling. There are several approaches to knowledge mapping, which generally build upon the systems analytical approach to sense-making. Knowledge management approaches recommend the use of knowledge mapping to establish an inventory of knowledge assets, how they cluster together, and the characteristics of those assets. Knowledge maps ascertain and clarify the domain of interest in which the elements are relevant. In information systems development, entity-relationship diagrams are the basis of relational database design and software objects development. In an environment of relatively unstructured, non-routine knowledge work, where one is attempting to provide a suitable workplace of well-configured knowledge management systems (for example within an Intranet) a well-constructed knowledge inventory could offer several advantages: it could be a simple index to be used to find a person or piece of information or provide a taxonomy of information at the user interface (Mack et al, 2001). Once knowledge items have been identified, a representational form is required to make that inventory accessible for use. The mode of access can be a report or a simple database with search and list capabilities (Davenport and Prusak, 1998). It can also take more sophisticated visual and navigational forms, such as topic maps (Le Grand & Soto, 2003) concept maps (Huff & Jenkins, 2002), semantic networks (Geroimenko, 2003) and Petri-nets (Rudas & Horvath, 1997). Process models which link to knowledge resources can be developed and published to Intranets using software tools such as ARIS (Scheer, 1999).
This research examines the phenomenology of knowledge elicitation and the development of an inventory. Whilst there has been much work done investigating representational forms for knowledge maps, and some in the area of methodology (e.g., Kim et al, 2003), there seems to be a paucity of description at the human interface of gathering and categorizing knowledge items for embedding in a technology solution. The first requirement in any mapping exercise is to make sense of the business and derive salient items of knowledge. There are substantial situational and psycho-social components which influence how any particular individual performs this task – irrespective of the level of detail of a methodology. The formal tools of sense making are those of business analysis and process mapping, which identify work activities and sequences, the stocks and flows of information required in the execution of those processes, the application of expertise and the concomitant roles and responsibilities. The Soft Systems Methodology using rich pictures, root definitions and CATWOE’s (Checkland & Scholes, 1990) is an example of an interpretivist method which is geared towards sense-making, whereas data flow diagrams, entity-relationship models, ontologies, cognitive maps and taxonomies, although within this general conceptual space, have an objectivist orientation. The context of eliciting information from business staff is usually through examining documentation, conducting workshops, interviews and observation of work practices (Grey, 1999; Kim et al, 2003). .
METHODOLOGY
The aim of this research is to uncover, step-by-step, what tools and materials are needed to achieve adequate knowledge maps. The readiness at hand of analytical tools is established by their use in the process of achieving an end. Action and existence are generally unreflective and unproblematic: we simply do things and use tools to achieve certain ends; we are not ghosts in the machine, observing putative internal representations (Ryle, 1949) or manipulating symbols of the real world (Heidegger, 2001). It is when a work process breaks down in some way because the tools do not suit what we are trying to achieve, that we become aware of what the tool is meant to achieve, or indeed what sort of tool is needed. To put it in rather more Heideggerian terms, it is when a ‘breakdown’ occurs and we are confronted with a situation of ‘non-obviousness’, in particular when tools are not ‘ready at hand’, that we are ‘thrown’ and become aware of the tool we use and its shortcomings. Indeed, formal and linguistic representations of actions qua methodologies are restrictive and their use will introduce a ‘blindness’ into perception of the process. This is valid for physical and intellectual tools (Polanyi, 1973).
The intellectual and sense-imposing structure and tools of methodologies can be assessed by their readiness at hand in achieving a desired end, the knowledge inventory. We will not realise breakdowns until we actually perform the designated action: therefore we need to ‘do’ things or model them in some way (Ehn, 1988; Winograd and Flores, 1986). Secondly, knowledge of what we do and experience is not necessarily propositional: it can be, and is, physical and tacit. Existence is about doing as much as thinking about the world. We need to drag non-obvious practical knowledge into the open by active user participation, by living the task, through participation or observation. Therefore, this research has adopted the methodology of reflective phenomenology through action research to illuminate what has hitherto been a largely technical and formalistic exercise. In particular, it is at the situated interface between formalism and phenomena that the readiness of hand of a method is ascertained. Observation and reflection-in-action give insight into what is really happening when you involve people in knowledge elicitation interviews and workshops.
Within the particular real-life case, what methodology is appropriate for sourcing my data? How will I be able to make trusted, justified assertions about knowledge-mapping from my own experience within this project?
¨ Clearly there is action research involved (Baskerville, 2001; Robinson, 1993; Schon 1983). I have a plan, a method and will react and re-orient based upon feedback and interpretation. I must use the tools of reflective phenomenology and heuristic inquiry to monitor and record these changes
¨ Clearly there is participant observation: but I must declare my bias and be as unencumbered as possible both in the doing and in the observing and reporting of the application of practical reason. Therefore I will use minimum preordained knowledge mapping methodology and identify only mines on the straightest possible path. I will also employ the first person to continually emphasise the subjective source of data.
Throughout the project, I kept a diary of observations made during encounters with the client and whilst I was developing the knowledge inventory and the database. I reflected regularly upon the implications of those notes and observations. The data is qualitative and textual, so the tools of interpretivist analysis and hermeneutics are required and I use the 6 stage hermeneutic cycle of Klein and Myers (1999). Apart from this “dialogue with the self”, this report has been reviewed by the client project manager as a fair and accurate record.
THE CASE STUDY
Background to the Story
The organisation in which this project took place
is a shire council located within a large capital city in
¨ Corporate Services – which provides administrative functions such as finance and human resource management, as well as functions pertaining to parking, noise and dog management.
¨ Community Services- which provides services to section of the residential population, such as the aged, the disabled, youth groups, sporting clubs and special-interest cultural groups.
¨ Engineering Services – This oversees the development and management of infrastructure, such as roads and parks.
¨ Built Environment Services – which manages the development of land and buildings by ratepayers, residents, the shire itself, and commercial interests, as well as the provision of health monitoring, inspection and waste collection.
The shire places substantial emphasis upon quality management systems. It is a participant in the Australian Business Excellence Framework (a kind of Australian Malcolm Baldridge award). Processes and procedures are comprehensively documented and there are continuous improvement groups who discuss and distribute enhancements to work processes and lessons learned. There are clear metrics for departmental performance, with achievements being reported in metrics and qualitative terms on a monthly basis and in the annual report.
The CEO of the organisation is the main driver of business process improvement and initiated a project to introduce knowledge management into the shire. This project had four stages:
1. A data and information collection strategy, in which the organisation discovers ‘what it knows’ and what it needs to know
2. A data and information interpretation task, which develops strategies on utilising and interpreting the data
3. A strategy to bring the data and task together to facilitate more effective decision making
4. A strategy to sustain innovation and improvement through continuing to optimise the environment for knowledge work.
The Beginning
This case study covers the step within the first stage of this project, which was the physical identification and recording of knowledge assets. This task was assigned as a paid consultancy to me, a university researcher, via the University. Defining a scope of work took three meetings with the client. I constructed a proposal which had the following objectives:
The objective
of this audit is to provide an inventory of the existing stocks of information
(which exist for example in information systems, procedures, reports,
people’s heads) and any issues with the provision of that information to
staff and stakeholders in the performance of their tasks. The audit should
result in an inventory (or map) of information which might be used for a number
of purposes, for example as a basis for designing a systems architecture for
I was well-versed in knowledge management and I had also previously developed data models and data dictionaries as a business analyst. I found some useful web sites which gave insight into the approach from a KM perspective. However, I was determined not to enter the project with a detailed methodology in hand and took my guidance from the meanings and intentions of the client project manager. The idea of ‘inventory’ implies an electronic database. The economic and technical parameters of the organisation pre-determined that an MS-ACCESS database would be required, as neither the infrastructure nor any perceived ROI could justify a sophisticated graphic application. I reflected upon what entities would be required or be of potential use in such a database, according to the project objectives. I arrived at the following:
¨ Items of knowledge – because we are collecting information about a piece of knowledge which we must be able to name in some way.
¨ Data on what is done to or with the knowledge – because we need to know in what context knowledge is needed or created, in order to anticipate how it will be needed and accessed in the future.
¨ Data on who does something to or with the knowledge – because we need to know who has the knowledge and can make it available to others.
I refined each of these entities to arrive at the following attributes which I thought would be useful for reports or functions:
A. Knowledge item:
¨ Name – a unique identifier for the knowledge
¨ Description – a textual explanation of the knowledge item
¨ Type - an indication of the type of knowledge, for example was it personal knowledge, a document, a group skill, an IT system or a book-journal. This seemed a useful categorisation, although I am prejudiced through articles on organisational memory such as Walsh and Ungson (1991) etc.
¨ Domain – an indication of the business area in which the knowledge was used (accounts, human resource and so on)
¨ Location – the physical location where the knowledge was stored
¨ Concept – a main concept for the knowledge item
¨ Related concept – concepts related to the knowledge item (this was included to open the way for possible graphics in the future)
¨ Importance – the priority of the knowledge to the business
As the project evolved, the last four items deteriorated in perceived value (although in another, larger organisation I would retain them). There was only one business location, the importance of knowledge was overwhelmingly ‘very high’ or ‘high’, and the “concept – related concept” attributes could not be consistently implemented without an existing taxonomy.
B. Knowledge method is what is done to the knowledge ‘object’:
¨ Method – is a term borrowed from object orientation; I initially defined creator, owner, users and changer as possible values here, as these generally represent what is done to knowledge (Huber, 1991; Bukowitz & Williams, 1999).
¨ Activity level – how often the method is performed (often, regular, seldom).
¨ Stakeholder – which organisational group actually performed the ‘method’.
¨ Process – what business process was performed as the method was being executed.
C. Stakeholder a simply a list of values containing the organisational units
This is a very simple structure and although some basic errors
were made, for example an incorrect relationship to methods was made, whereby
multiple methods were not possible, and the key to the items table was the name
(where it should have been an autokey). Once the
tables were defined, the data entry proceeded very quickly using the MS-ACCESS
datasheet view. Figure 1 shows the basic layout of the database.
Figure
1: Knowledge Items Database Layout
The Middle
I began the inventory identification by examining in detail major business documents such as the annual report, business strategies and reports. The Internet and the Intranet website were also early sources. My previous experience with Objected Oriented Analysis (Booch, 1994) influenced me to seek nouns and substantives referring to documents, procedures, IT systems and reports. These substantives were the first candidates for ‘items of knowledge’. From descriptions of activities, I was able to deduce ‘group skills: for example, one division ran a child care centre, which became defined as group expertise in caring for children. The latest IT strategy revealed the computer applications.
As a former strategic consultant I had the urge to link knowledge items to the relevant business process in a diagrammatic form (see also Scheer, 1999 and Collins, 2003). This has the advantage of clearly showing which particular items of information are required by any business task. Process modelling was not within the scope of the project. However, the nature of the organisation was such that far from running as an integrated value chain, the shire performed many discrete functions (defined as functional units) which stood proxy for processes (for example, Community Services would be ‘Serve the Community’ and Engineering Services ‘Provide Construction and Maintenance Services’).
As I proceeded I found external stakeholders were the possessors of certain types of knowledge. ‘External / Internal’ became an attribute of stakeholders. However, as I progressed, I found myself not entering external stakeholders. My rationale was that the first port of call when knowledge was being sought would be the appropriate contact person within the home organisation. I therefore linked external knowledge to an internal stakeholder as a substitute for the external stakeholder (for example to avoid the reproach “Good grief, you’re the fifth person from there to call us this week – don’t you ever talk to each other?!).
I started by entering the data in MS-ACCESS ‘spreadsheet mode’. This interface is raw and basic and lured me to enter the data in a truncated and inarticulate form, which I subsequently spent some time correcting. In retrospect I should have developed the database forms early on, in order to apply early quality control.
After extracting as much as I could from documentation, I moved to interviews with staff. The first tranche of interviews was with divisional management, who were to provide an overview of their divisions and direction in collecting and assessing knowledge items. I then moved to operational staff. The interviews were successful and I gained substantial insight into organisational work. There were nonetheless two major difficulties. Firstly, it was clear that people were often not able to identify and articulate what knowledge they used to accomplish their everyday (and therefore largely habituated) tasks. This is a standard problem in knowledge elicitation. Secondly, I gained the impression that interviewees were sometimes making decisions about what they told me: either they considered I did not need to know something, or they did not want to give something important or personal away. In retrospect, I consider that workshops would be effective in reducing this exposure.
Prior to the interviews, I created a question sheet (see Appendix 1) which divided the interview into two parts. Part one consisted of asking the participant which activities they engaged. This took 10 – 15 minutes. Then I worked through this list of activities by asking the participant what knowledge, information or data they needed to accomplish the task. This established a trigger and a context for eliciting knowledge items. After about 4 interviews I developed forms for the capture of data. This facilitated subsequent entry into the database, through ensuring completeness and structure, but I often used 20 such forms in a sitting. I entered all this data from notes and forms into the database, although in about 10% of cases I found it was not expressed clearly to me what the knowledge was actually used for.
I noticed fairly early that differentiating creator and owner of knowledge was pointless, and that in most cases, they were the same thing. I attempted to enter users of data, but this seldom came out of the interview notes, and I had to make assumptions and guesses about ‘who else might use this’. For example, the Community Services people might need to know about building quality standards for recreation halls. My initial assumption in including ‘user’ in the methods section was that by identifying multiple users, I could deduce knowledge which should be made generally available (for example on the Intranet or Internet). However, this has several implications. It requires detailed analysis and became too ambitious for this project. It goes beyond the inventory to a kind of implicit process mapping. Finally, one cannot foresee who potential users of information are anyway. If this list was to become generally accessible, it would be easy to trace and monitor which pieces of knowledge were generally required. By the second half of the project, I documented only the owner of a piece of information.
A recurring conundrum was how to deal with a piece of information which has its origins in a computer information system. The user of the information might need only a name and address list from a report, which is a small subset of what is actually in the IT system (which is itself captured in the inventory). I resolved this by itemising the information in the database, but entering in the description that its origins were in a certain information system. This would help someone who has a query such as ‘how do I find the names of those needing special transport to events?” by indicating they should access Information System ABC.
About one third into the project I discovered standard taxonomies in the area of local government which were designed to provide a superset of all records management and informational categories any council might wish for. This was interesting, but was not pursued, as I was told the organisational forms and statutory obligations in councils vary widely.
As I continued, I found the absence of an overall process model a hindrance. In my work as an Information Planning consultant, the first step I have always taken in analysing a business is the development of a process model which represents the tasks and activities of an organisation, down to 2 – 3 levels of detail. Tasks which are then distributed across organisations can then be integrated and optimised and solved using the same application or technology, instead of each organisational unit acquiring their own ‘island’ solution and thereby developing information ‘silos’. Whilst there are ‘process models’ in place at this organisation, these are developed and owned by organisational units and are isolated from each other. I developed a process model which breaks down departmental boundaries and used some of these categories within the knowledge inventory database (for example ‘risk management’ and ‘quality management’ were not part of any particular organisational unit).
Reflecting at one stage, I had classified 390 discrete pieces of knowledge and information. The problem of granularity raises its head: what actually is the criterion for deciding whether an item is worth capturing in the database? Should one list every item of knowledge (or suspected knowledge)? What is obvious, what is trivial? I decided to leave it to reviewers to decide – indeed, reviewers of the database deleted some 30 items as extraneous). I sense there are the following criteria:
¨ Could someone else in the organisation want to find this to use for a different task, such that they need ‘anonymous’ access and may not have the knowledge of where to find what they need?
¨ Could someone else want to share that knowledge or information across boundaries of space and jurisdiction? It would be easier if it can be placed at a central site but not restricted (e.g. at the moment, each Division of the City has its own directory on the server, which is not accessible to other divisions).
¨ Is it critical to the organisational activity, such that if the information were corrupted or lost, it would affect the ability to complete that task?
The size of the organisation is important in deciding these things. This shire employs only 160 people: everyone knows how to ask for information and the ‘degree of separation between a seeker and provider of knowledge is very low. I reflect that the actual use of a knowledge inventory to find knowledge will be very interesting, if the current method of finding knowledge is to ‘stick your head above the partition walls and yell’.
One particular class of interview was most interesting, namely those (usually administrative assistants) who sit in positions of “gatekeeper”. They are not only enormously well informed, but are very able to describe the piece of knowledge in accurate terms. I assume it is because they facilitate the movement of knowledge, rather than using it. This means that the knowledge remains explicit and part of discursive consciousness (Giddens, 1984) and does not become sedimented into tacit form.
About half way through the data collection I examined the organisational procedures, which proved to be a fantastic source of knowledge items. These brought 260 new items in one day alone, compared to 400 from about 10 interviews and the other documents. The reason is clearly that procedures are written in a style which defines inputs and outputs: these are very often (in fact usually) informational. There is a strong ‘feel right’ factor to these knowledge items.
At this stage I also realised the necessity of integrating the organisational stakeholder information with the methods information in the database. I reworked all items in the database to link to a stakeholder role. This needed to be done to the level of a staff member, as one of the emerging objectives of the knowledge inventory was to help locate someone who could help (for example, the switchboard operator who gets a call with a question on deaf language or treatment of lawn beetles). In this process of upgrading the entries, I notice duplicate elements: a good data entry tool would warn me if there already similar entries in the database.
The End
After all data collection had been performed, there remained the quality assurance and delivery of the final product. I prepared a workshop, in which the database will be inspected. I generated a report for each domain, and allocated this to the functional group which “owned” that domain. Each group was to inspect the report line-by-line and annotate it with corrections and deletions. This clarified and tightened up the database considerably.
The first participants had some trouble understanding the purpose of the review. I may have explained badly, as I didn’t go through the printout itself. Interestingly although hundreds of corrections were made only about ten new pieces of knowledge were recorded,. There was confusion regarding the word “owner” of a piece of knowledge: was it the person who collects the data, or who is responsible for keeping it up to date, or administering the repository (i.e. the IT department)? The work was generally pretty tedious. In retrospect I surmise that perhaps workshops at the beginning would have been useful, to engender additional ownership of the inventory list. At the start of the review sessions I again presented the rules of thumb to workshop participants:
¨ Who else needs to know this?
¨ Does the job role require this, to the point that if the incumbent became unavailable, someone else would need to acquire this knowledge in order to do the job?
A final intuition which the organisation’s project manager and I agreed upon, was that this database would never be finished; it is an ongoing work-in-progress. If it is to be successful in operational use, it must be continually added to and one must be able to measure and improve its effectiveness.
A neat maintenance and enquiry system evolved out of the
project, although this had not been specified at the commencement of the
project. It could be easily fitted into the Intranet to support anyone, in
particular front-office staff, locate the right person to assist with a query
(instead of forwarding, yet again, to an already overloaded senior manger) or a
piece of information. An enhancement was a programmed trace which created an
audit trail of queries, thereby allowing analysis of what it was that people
most sought for. Improvements which were desired but not possible at the time
were to hyperlink the listed items either to the electronic source, or to bring
up an e-mail which was automatically addressed to the “owner” of the knowledge.
Figure 2: Menu and Knowledge Item Search
Figure
3: Knowledge Item Maintenance Form
DISCUSSION AND ANALYSIS
The source of data has been observational and reflective, one of discovery and self-discovery. Much of this data cannot be triangulated, as the observations, extensions of and corrections to methodology come from within me. The only triangulation has been to submit this paper to the commissioner of this work, whose feedback has been positive and supportive, which confirms that the steps listed here have led to a usable and useful outcome.
The first of the hermeneutic principles has been observed in the setting of the business context, the commission of the work and the description of myself and my biases. The following description constitutes the analysis of the data in terms of the hermeneutic circle.
Relationship with the participants
I was an external consultant, not known to any of the participants. It was not my intention to observe them or their behaviour and the atmosphere was always friendly and helpful. As the representative of the project manager who had initiated the project, there may have been some doubt about my motives for wanting to know what they know: knowledge is, after all, power. However, this was not provable and I took all interactions with participants at face value.
Generalisation and Abstraction
This stage of the hermeneutic circle can arrive at general concepts and rich insights. The following methodology constitutes the general concepts, the steps to take and the tasks to be performed. The next section, heuristics, comprises the richer insights of the exercise.
Methodology
The method led to the following general observations about knowledge mapping in this context, which may form the basis of heuristics. My experiences as a project manager and consultant force me to articulate a phase model, within which framework I can stipulate activities. Firstly, in retrospect, there were four types of work which can be established as the more-or-less sequential phases of work:
1. Preparation and Planning:
a. Establish the scope of work and available resources: this will be mostly a function of the funding available and will determine the richness and detail of the knowledge inventory.
b. Establish the objectives and potential uses of the knowledge inventory, the final format required and the level of detail is expected to be.
i. The format will normally be a database of some kind, but may be graphical. It may also depend upon requirements to link to other technologies you have, such as Human Resource databases, records management and Intranets.
ii. The rules of thumb for the level of detail might be:
§ Could someone else in the organisation want to find this knowledge in order to apply it to a different task?
§ Is it important to organisational activity, such that if the information were corrupted or lost, it would affect the ability to complete a task?
c. Identify the main sources of information, such as documents, management and staff, who should give good coverage of knowledge items
d. Estimate the duration of the project and plan the phases and the tasks for each phase
e. Get to know the organisation through some interviews with senior staff, reading financial reports and annual reports
2. Database and Category Design
a. Decide which entities and attributes you require, but ensure you are collecting data which will be of use.
b. Create a database in a technology appropriate to your organisation.
c. Within the collection database, establish the following categories to be instantiated as pull-down lists or combo boxes for data entry:
i. Knowledge types you are interested in (documents, expertise, information systems etc)
ii. Knowledge methods you are interested in (owner, user, updater)
iii. Knowledge domains of interest. These will either be organisational areas of expertise or business processes. If there is time, use business process modelling to identify the business processes. Otherwise, identify the areas of expertise (which will tend to be congruent with organisational structure)
iv. Stakeholder groups (usually organisational units, but consider if you wish to identify communities of practice)
v. Stakeholder role (the particular staff position)
vi. Staff names (should you be wishing to integrate these into the database)
d. Once the categories are in the database, ensure that data entry is supported through functional forms (add, update, delete, get next, get previous etc) and through list boxes.
e. Create data entry forms on paper and interview checklists (if you have a PDA and a human assistant, data entry might be immediate.
3. Data Collection
a. Begin by examining important documentation such as annual reports, strategic reports, information systems plans, process and procedural documentation, meetings minutes and so on.
b. Prepare forms and questions for the interviews.
c. Conduct workshops using mind-mapping techniques to brainstorm as many items as possible and gain group acceptance for the knowledge mapping project.
d. Conduct interviews with senior management to help identify further subjects who are more at the coal face. Also identify ‘gatekeepers’.
e. Enter the data into the database
4. Data Cleansing
a. Step through all items, ensuring spelling, descriptions are ok.
b. Check for duplicates and meaningless items
c. Conduct group reviews and inspection workshops to identify missing items and anomalies
Derived Heuristics and Insights
¨ If the aim and use of the knowledge inventory is clear, there is greater acceptance and enthusiasm for the result. Just to know what we know is not terribly useful. Use this to create a plastic explanation for interviewees. Is it going to be a piece of software, input to something else or something for the quality auditors only?
¨ The more anonymous, larger and distributed the organisation, and the more it uses a value chain to produce outputs, the more useful will be the knowledge inventory and the more worthwhile it is to capture knowledge in detail which his associated with business process.
¨ Determine the level of detail. The rule of thumb I used was: is there anyone else in the organisation who may be interested in this, or if the person in that role leaves, what will their successor need to know?
¨ Have the database and the forms ready from the beginning. When entering data, aim for quality (clarity, spelling, format, accuracy, completeness) of data at the first entry of the data. For example, enter the method and the knowledge item at the same time.
¨ Perform a process analysis and develop clear, approved process categories for the knowledge inventory. Get familiar with the activities within a category, as this will serve well when entering the data and subsequently assigning it to a knowledge domain. It is also important for phrasing questions to staff as the task definition brackets the experiential flow: “what knowledge do you use or apply in order to achieve this task?” Even then, not all staff will be able to give a complete answer.
¨ First gather and analyse all major items of documentation, such as annual reports, departmental reports and reviews and strategic plans. In particular look closely at procedural documentation.
¨ Identify managers and gatekeepers and interview them using a checklist of questions as in Appendix 1, or even use a form (as in Appendix 2). Even better would be a junior assistant to write notes and fill in the forms during the interview. Use tasks and business processes as a trigger to uncover knowledge items.
¨ There will be changes to categories. By necessity, as data about knowledge grows, so outlines of previously unrecognised knowledge domains will appear. When this happens, review existing items to check whether they should be in the new category
¨ Run reports across the database to see if any categories are empty. If so, delete them.
¨ In future, I would use cognitive mapping in workshops not just for eliciting information, but for increasing the participation and ‘ownership’ of staff for the final knowledge directory.
¨ Remember that although the output of a knowledge mapping project is formal and structured, the input is messy and ill defined. To ask skilled, routinised people what they know requires skill, patience and careful phrasing of questions.
¨ Involve and motivate people by using workshops and brainstorming – and asking them, to what use could this knowledge inventory be put. This project, for example, resulted in an inventory, a tool to find knowledge, a list of items which can be reviewed to isolate and secure strategically important knowledge, categories for the ordering and sorting of knowledge and a potential instrument for supporting knowledge worker induction.
Alternative Explanations and
Suspicion
I have arrived at a rationalised methodology: the steps to take and the order to take them in (Jayaratna, 1994), along with some ‘tools and techniques’ (Project Management Institute, 2000). I believe that there is external validity and reliability in these generalisations: another researcher could arrive at the same database of knowledge using the steps I have taken. But the systematic application of Cartesian doubt is required:
¨ What use is the database really? My business analyst voice tells me that the database and inventory will be functionally useful, that people will use it for a variety of purposes, some unforseen. My sceptic’s voice tells me that it is quicker for staff to ask someone ‘who knows what’: that they managed well before and will continue to do so. Perhaps there is a formula for calculating the need for knowledge inventory involving the number of staff, their distance from each other, the degree of separation and an ‘anonymity index’. A search counter has been built into the database, which should deliver answers for the next instalment.
¨ What level of detail was really required? Or, asked another way, how many items should I have in the database? Perhaps such that each item was accessed at least once and that few items were sought unsuccessfully. Counters for both can, and should be, built into the database and the database should evolve toward this balance.
¨ Rework will be necessary, as new stakeholders (perhaps non-formalised communities of practice) or processes emerge. New categories evolve from a deepening understanding of what the organisation was about.
¨ Why didn’t I use soft systems methods, cognitive mapping, discovery workshops? An introspective voice tells me that workshops would deliver less detail, but this may have been wrong. A less self-critical voice reminds of an article (Robertson, 2003) which said the best way to get the richest information on knowledge items is through interviews. In retrospect, my project and change manager voice tells me to involve people in groups and win their hearts for the cause.
¨ Why was it hard for some people to identify or reveal their own knowledge? I don’t believe there was a lot of deliberate hiding of knowledge. The answer lies mostly in the very nature of social enquiry, which is clearly what knowledge mapping is. So much knowledge is habituated, ‘practical consciousness’ (Giddens, 1984) that identifying the ‘reasons for’ doing things requires skills in social investigation. Knowledge of this ‘double hermeneutic’ is not widespread.
Conclusions
The approach to knowledge inventory in this project was developed reflexively and developed (almost) from the ground up: it achieved a “result” and a way of achieving a result which seems to be repeatable and valid for future projects. The outcome was acceptable to the client and its instantiation as an Intranet search tool was not quite foreseen at the inception of the project. An immediately useful application was developed, which was low-tech, cheap, widely accessible and simple to implement.
The transcription of the reflected approach and the application of reflection in action (Schon, 1983) have resulted in a methodology and some techniques which used together may help practitioners in future, and be richly reviewed from a theoretical perspective for the discipline of knowledge management. Some important questions for future research are thrown up for knowledge mapping and I would highlight the following:
¨ What factors determine the correct level of detail for a knowledge inventory? I have identified a rule of thumb, but further research is required to identify principles.
¨ How would a business manager calculate the investment one should put into developing a knowledge inventory, such that there is an acceptable return on that investment?
¨ What is the best way to identify and circumscribe knowledge items within the complex, phenomenological world of work process?
Above all, the client project manager and I agreed that the work of knowledge inventory remained a work in progress. Only through identifying missing items on the one hand, and items never accessed on the other, could one oscillate towards the ideal level of content and detail over time. This is a future line of inquiry to be pursued. The client, whilst maintaining the database structure, has since initiated a project to enhance usability of the system (which is now fully implemented). One enhancement was to allow users themselves to enter items they consider important for others to know. This item must only be ‘approved’ by the administrator and it is available to others to find.
References
Alavi, M. & Tiwana, A. (2002), Knowledge Integration in Virtual Teams: The Potential Role of KMS, Journal of the American Society for Information Science and Technology, vol. 53, no. 12, pp. 1029-1037.
Baskerville, R. (2001), Conducting Action Research: High Risk and High
Reward in Theory and Practice, in E. M. Trauth, (ed.)
Qualitative Research in IS; Issues and Trends, Idea Group Publishing,
Boisot, M. H. (1998), Knowledge Assets -
Securing Competitive Advantage in the Information Economy,
Booch, G. (1994), Object Oriented Analysis and Design with Applications, Benjamin/Cummings,
Bukowitz, W. R. & Williams, R. (1999), The Knowledge Management Fieldbook,
Pearson Education Limited,
Checkland, P. & Scholes,
J. (1990), Soft Systems Methodology in Action, John Wiley and Sons Ltd,
Collins, H. (2003),
Ehn, P. (1988), Work-Oriented Design of
Computer Artifacts, Arbetslivscentrum,
Gartner-Group (2002), Strategic Analysis Report R-18-1032.
Geroimenko, V. (2003), The
XML Revolution and the Semantic Web, in V. Geroimenko
& C. Chen, (eds.), Visualizing the Semantic Web. XML-based
Internet and Information Visualization,
Springer-Verlag,
Giddens, A. (1984), The constitution of society: outline of the theory of structuration,
Grey, D. (1999), Knowledge Mapping: A Practical Overview, Available: [http://smithweaversmith.com/knowled2.htm] (April).
Hansen, M. T., Nohria, N. & Tierney, T. (1999), Whats your strategy for managing knowledge? Harvard Business Review, vol. 77, no. 2 (March-April 1999), pp. 106-116.
Heidegger, M. (2001), The Being of Entities Encountered in the Environment,
in R. C. Solomon, (ed.) Phenomonology and
Existentialism, Rowman & Littlefield
Publishers Inc.,
Huber, G. (1991), Organizational Learning: The Contributing Processes and the Literatures, Organization Science, vol. 2, no. 1, pp. 88-115.
Huff, A. S. & Jenkins, M. (eds.) (2002), Mapping Strategic Knowledge,
Sage Publications,
Jayaratna, N. (1994), Understanding and Evaluating Methodologies: NIMSAD - a Systemic Framework, McGraw-Hill, Maidenhead.
Kim, S., Suh, E. & Hwang, H. (2003), Building the knowledge map: an industrial case study, Journal of knowledge management, vol. 7, no. 2, pp. 34-55.
Klein, H. K. & Myers, M. D. (1999), A Set of Principles for Conducting and Evaluating Interpretive Field Studies in Information Systems, MIS Quarterly, vol. 23, no. 1, pp. 67-94.
Le Grand, B. & Soto, M. (2003), Topic Maps Visualization, in V. Geroimenko & C. Chen, (eds.), Visualizing the
Semantic Web. XML-based Internet and Information
Visualization, Springer-Verlag,
Leonard-Barton, D. (1995), Wellsprings of Knowledge: Building and
Maintaining the Sources of Innovation,
Mack, R., Ravin, Y. & Byrd, R. J. (2001), Knowledge portals and the emerging digital knowledge workplace, IBM Systems Journal, vol. 40, no. 4, pp. 925-955.
Nissen, M., Kamel, M. & Sengupta, K. (2000), Integrated Analysis and Design of Knowledge Systems and Processes, Information Resources Management Journal, vol. 13, no. 1, pp. 24-43.
Polanyi,
M. (1973), Personal knowledge -Towards a
Post-Critical Philosophy, Routledge & Kegan Paul,
Project Management Institute (2000), A Guide to the Project Management
Body of Knowledge (PMBOK Guide) - 2000 ed, Project
Management Institute Inc.,
Robertson, J. (2003), Stakeholder interviews as simple knowledge mapping, Available: [http://www.steptwo.com.au/papers/cmb_interviews/] (December).
Robinson, V. M. J. (1993), Current Controversies in Action Research, Public Administration, vol. Fall, pp. 263-290.
Rudas, I. J. & Horvath, l. (1997), Modeling of manufacturing processes using a Petri net representation, Engineering Applications of Artificial Intelligence, vol. 10, no. 3, pp. 243-55.
Ryle, G. (1949), The
Concept of Mind, Penguin,
Scheer,
A.-W. (1999)., ARIS--business process
modeling., 2nd., completely rev. and enl. ed. edn,
Springer,,
Schon, D. A. (1983), The Reflective Practitioner, Basic Books.
Vail, E. F. (1999), Knowledge Mapping: Getting Started with Knowledge Management. Information Systems Management, vol. 16, no. 4, pp. 16-23.
von Krogh, G. & Roos, J. (1996), Managing Knowledge: Perspectives on
Co-operation and Competition, SAGE,
Walsh, J. P. & Ungson, G. R. (1991), Organizational Memory, Academy of Management Review, vol. 16, no. 1, pp. 57-91.
Winograd, T. & Flores, F. (1986), Understanding Computers and Cognition : a new foundation for design, Ablex Publishing,
APPENDIX 1
Interview Questions
1. What are the main tasks / business processes in your Department?
2. What are the core competencies in your Department / Organisation?
3. Who are the main people to go to when advice is required? (Ie who are the most knowledgeable)
4. What are the main locations for storage of core information?
¨ IT Systems
¨ Files
¨ Groups of people
¨ Individuals
¨ Cupboards
5. What external sources of knowledge and information do you use?
6. Do you have any documents such as strategic plans or consultant reports?
7. What are the key pieces of information that tell you your Department / Organisation is running well?
Knowledge Worker Questions
1. What are your main tasks and responsibilities?
2. What type of knowledge and information do you need to fulfill these duties?
3. What are the main locations for storage of core information?
¨ IT Systems
¨ Files
¨ Groups of people
¨ Individuals
¨ cupboards
1. Do you use, create or change knowledge in the above processes?
2. With whom do you work most often to solve problems? Do you typically work together like this?
3. What skills do you use in other people?
4. What issues do you have in obtaining the knowledge or information you require?
5. What external sources of knowledge and information do you use?
About the Author:
Dr Paul Jackson is a lecturer in the