Chapter VI

KMS Development
 Chapter objective
• Describe KMS development process
• Explain the difference between KMS and
system development
• Explain the necessary condition for successful
KMS development
• Know some specific KMS development tools
and procedures
 Knowledge Management System (KMS)
development Cycle
• It is a sequence of tasks to build a new
knowledge management system
• It creates standard development of KMS
• Also help to compare and evaluate different
KMSs
• Help to use time and resources efficiently by
avoiding trial error and reworking
Conventional System Life KM System Life
versus Cycle
Cycle

Evaluate Existing Infrastruct

Recognition of Need and ure
Feasibility Study

Functional Requirements Sp Form the KM Team

ecifications
Knowledge Capture
Iterative
Logical Design (master
design plan) Design KMS Blueprint

Physical Design (coding) Verify and validate the KM

System
Testing
Iterative
Implement the KM System
Implementation (file
conversion, user training) Manage Change and
Rewards Structure
Operations and Maintenance
Post-system evaluation
2-4
• Here, I make a comparison between the system life cycle that is often adopted
in conventional system development and the version of KMSLC that are
proposed by Awad and Ghaziri in their textbook.

• Let’s look at the stages that are involved in a typical conventional system life
cycle.

• In almost all conventional system development project, one will start out with
a “Recognition of Need and a Feasibility Study”. Sometimes, this stage is
simply abbreviated as Feasibility Study. In this stage, normally a system analyst
will have already identified an existing problem in an organization (may be in a
department) that can be solved by an application of Information technology.
Of course, recognizing the existence of a problem doesn’t necessarily say a
solution is possible, within the current resources constraint in the organization.
These constraints could be time, money, people, and expertise.
• Assuming that the answer is positive after the feasibility study, the next stage would be to come
up with software specifications for the system that is to be constructed. This is a sample of
elements that will be included in a software requirements specifications document.

• When the software requirements specifications have received an “ok” sign from users and from
management, the later stage will be straightforward. Logical design (or the master design plan)
of the system will commence, usually performed by a group including systems analyst and
programmers and users.

• Once the master design plan is ready, physical design (or coding) will follow. This is again
straightforward in an IT point of view.

• Once a version of the system is ready, then testing will begin, followed by implementation, and
finally when the system is ready, issues on operations and maintenance will be documented
and followed.
• The conventional system life cycle is largely sequential, that is one stage following on from
the previous one.
• However, at the point of testing, when the system to be implemented is found out to not
perform according to the initial software requirements specifications or contains logical
errors or programming errors, the development team will have to refer back to the logical
design to make necessary changes or amendments. However, the software requirements
specification remains unmodified.

• Compared to this, in the KM system life cycle,

• One will start with evaluating the existing infrastructure (knowledge assessment), including
both knowledge and system and people, that constitute the essential resources in the
company.
• If a KM initiative were decided, then the next step will be the formation of a KM team to
take on this KM project initiative.
• Normally, there will one knowledge developer in the KM team, who will be playing the important role of
identifying knowledge sources, capturing the necessary knowledge from experts, and then design the
blueprint for the KMS to be constructed. The first 3 stages pretty much resemble the first 2 stages in the
conventional system life cycle, while the “design the KM blueprint” corresponds to the logical design.

• However, instead of having a sequential stage of physical design, then followed by testing, in KMSLC, the
stage of verify and validate the KM system proceeds in an iterative manner, until a satisfactory prototype
of the KMS is arrived. By satisfactory, this will involve not just the users as in conventional system life
cycle, but the experts who are the sources of the knowledge embedded in the KMS.

• Implementation will be the next step, followed by the important yet less noticeable step of manage
change and rewards structure. This is a delicate stage as very often users, experts could become anti-
support to the KMS and implementation if they feel that their importance is being undermined, or that
the existence of the KMS jeopardize their necessity in the company.

• Post-system evaluation is to consider all the benefits of the KMS as weighted against its foresee benefits
at the time of conception.
 Key Differences
• Systems analysts deal with information from the user;
knowledge developers deal with knowledge from
domain experts
• Users know the problem but not the solution; domain
experts know both the problem and the solution
• Conventional SLC is primarily sequential; KM SLC is
incremental and interactive.
• System testing normally at end of conventional system
life cycle; KM system testing evolves from beginning
of the cycle
• Here, we list several key differences between the
conventional and the KMS life cycle. 2-9
 Key Differences (cont’d)

• Conventional system life

cycle is process-driven or
“specify then build”

• KM system life cycle is

result-oriented or “start
slow and grow”

2-10
 Key Similarities
• Both begin with a problem and
end with a solution
• Both begin with information
gathering or knowledge capture
• Testing is essentially the same to
make sure “the system is right”
and “it is the right system”
• Both developers must choose the
appropriate tool(s) for designing
their respective systems

2-11
 Stages of KMSLC
Evaluate Existing
Infrastructure

Form the KM Team

Knowledge Capture

Iterative Rapid Design KM Blueprint

Prototyping
Verify and validate the KM
System

Implement the KM System

Manage Change and

Rewards Structure

Post-system evaluation
2-12
• KM system development life cycle is largely
composed of 8 stages, which we will briefly
discuss in the remaining slides. You should
obtain description of their details in both the
lecture notes and the prescribed text.
• The first stage is to evaluate existing
infrastructure.
• There are several important questions that you
need to ask when making the evaluation.
 (1) Evaluate Existing Infrastructure
System justifications:
• What knowledge will be lost
through retirement, transfer, or
departure to other firms?
• Is the proposed KM system
needed in several locations?
• Are experts available and willing
to help in building a KM system?
• Does the problem in question
require years of experience and
tacit reasoning to solve?
2-14
 The Scope Factor
• Consider breadth and depth
of the project within financial,
human resource, and
operational constraints
• Project must be completed
quickly enough for users to
foresee its benefits
• Check to see how current
technology will match
technical requirements of the
proposed KM system

2-15
• As part of evaluating the infrastructure, you should also consider
the scope factor. Very often, the scope is being inappropriately set,
either too ambitious or too little to make the KMS impact known.

• One should be realistic when considering the scope of the system.

A larger goal can almost always be sub-divided into smaller ones.
Being able to achieve success in the smaller goals not only can
boost confidence in achieving the larger goal, but will also gain
recognition and continual support from management. At the end, a
KMS will not be successful without gaining the rapport from the top
management.
 Role of Strategic Planning
• Risky to plunge into a KMS without strategy

Knowledge developer should

consider:
Vision

Resources

Culture
2-17
• The role of strategic planning cannot be
undermined. A knowledge developer should
be able to foresee what the business is trying
to achieve, how it will be done, and how the
new system will achieve goals. He or she
should study the company’s resources and
culture in a manner that can align the KMS to
effectively use these resources to achieve its
benefits.
 (2) Form the KM Team
• Identify the key stakeholders of
the prospective KM system.
• Team success depends on:
– Ability of team members
– Team size
– Complexity of the project
– Leadership and team
motivation
– Not promising more than can
be realistically delivered

2-19
• After carefully evaluating the infrastructure,
the next stage will be to form the KM team
that will work together to develop KMS from
the blueprint to implementation.

• The team success will depend on a number of

factors, including those shown here.
 (3) Knowledge Capture
• Explicit knowledge captured in
repositories from various media
• Tacit knowledge captured from
company experts using various
tools and methodologies
• Knowledge developers capture
knowledge from experts in
order to build the knowledge
base such as Expert Interview
• The next stage after forming
the KM team will be knowledge
capture.
2-21
 Selecting an Expert
– How does one know the expert is in fac
t an expert?
– How would one know that the expert
will stay with the project?
– What backup should be available in
case the project loses the expert?
– How could we know what is and what is
not within the expert’s area of
expertise
– How to select an expert for the purpose
of knowledge capture is also an
important challenge for the knowledge
developer. Some of the questions that
should be asked are listed here.?

2-22
(4) Design the KM Blueprint
The KM blueprint addresses several
issues:
• Finalize scope of proposed KM
system with realized net benefits
• Decide on required system
components
• Develop the
key layers of the KM software arch
itecture
to meet company requirements
• System interoperability and
scalability with existing company
IT infrastructure
2-23
• Next, the KM team will need to develop
the KM blueprint based on the knowledge
captured. This will be very similar to the
logical design stage in conventional system
development life cycle.

• The blueprint should address several

issues, including those listed here.
 (5)Testing the KM System
• Verification procedure:
ensures that the system
has the right functions
• Validation procedure:
ensures that the system
has the right output
• Validation of KM
systems is not
foolproof
2-25
• As the KM system is under development, it goes
through a repetitive iteration of verification and
validation as the rapid prototyping process comes
out with intermediate version of the test system.
This is one of the major difference between the
conventional and the KMSLC, as one is process
driven while the other is result driven.

• Verification (functionality) vs. Validation (integrity)

 (6) Implement the KM System
• Converting a new KM system into actual operation
• includes conversion of data or files
• also includes user training
• Quality assurance is important, which includes checking
for:
– Reasoning errors
– Ambiguity
– Incompleteness
– False representation (false positive and false negative)

2-27
• Finally, as in conventional system life cycle, there will be the time
when the KMS will be rolled out for users to use.

• The elements that are involved in implementing a KM System are

given here. The quality assurance part is particularly important
for KMSLC. Whereas in conventional system life cycle, the logical
design based on the software requirements specification will
ensure the quality of the system performing as expected. In
KMSLC, due to its iterative nature of verifying and validating, the
final state of the KMS will not be foreseen from the very
beginning. Detailed checking with the cooperation of the experts
to ensure the system is working as expected is inevitable.
(7) Manage Change and Rewards Structure

• Goal is to minimize
resistance to change
– Experts
– Regular employees
(users)
– Troublemakers
• Resistances via
projection, avoidance, or
aggression
2-29
• Finally, during implementation, we will
surely encounter resistance from people in
the organization that will oppose the
system because of fear of losing control. A
few of these resistors of change are listed
here.
 (8) Post-system Evaluation
• Assess system impact in terms of effects on:
– People
– Procedures
– Performance of the business
• Areas of concern:
– Quality of decision making
– Attitude of end users
– Costs of Knowledge processing and update

2-31
 Key Questions
• Has accuracy and timeliness of decision making
improved?
• Has KMS caused organizational changes?
• What are users’ reactions towards KMS?
• Has KMS changed the cost of operating the
business?
• Have relationships among users affected?
• Does KMS justify the cost of investment?

2-32
 Basic Knowledge-Related Definitions
Common Inborn ability to sense, judge, or perceive
Sense situations; grows stronger over time
Fact A statement that relates a certain element
of truth about a subject matter or a domain
Heuristic A rule of thumb based on years of
experience
Knowledge Understanding gained through experience;
familiarity with the way to perform a task;
an accumulation of facts, procedural rules,
or heuristics
Intelligence The capacity to acquire and apply
knowledge
2-33
 Types (Categorization) of Knowledge
• Shallow (readily recalled) and deep (acquired through
years of experience)

• Explicit (already codified) and tacit (embedded in the

mind)

• Procedural (repetitive, stepwise) versus Episodical

(grouped by episodes)

• Knowledge exist in chunks

• Shallow vs. deep (necessary to make
decision/solve problem in complex situations)
2-34
 What makes someone an
expert?
• An expert in a specialized area masters
the requisite knowledge
• The unique performance of a
knowledgeable expert is clearly
noticeable in decision-making quality
• Knowledgeable experts are more
selective in the information they acquire
• Experts are beneficiaries of the
knowledge that comes from experience

2-35
1. Purpose
2. Statement of Scope & Objectives
2.1 System functions
2.2 Users and characteristics
2.3 Operating environment
2.4 User environment
2.5 Design/implementation constraints
2.6 Assumptions and dependencies
3. Functional Requirements
3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces
4. Nonfunctional Requirements
4.1 Performance requirements
4.2 Safety requirements
4.3 Security requirements
4.4 Software quality attributes
4.5 Project documentation
4.6 User documentation
2-36
 Users Versus Experts
Attribute User Expert
Dependence on system High Low to nil
Cooperation Usually cooperative Cooperation not
required
Tolerance for ambiguity Low High
Knowledge of problem High Average/low
Contribution to system Information Knowledge/expertise
System user Yes No
Availability for system
• builder Readily available Not readily available

• In earlier slides, we talked about the differences between conventional

system life cycle and KMSLC.
• We emphasized the importance of the role of users in conventional life cycle
as compared to that of experts in KMSLC. Here, we compare them based on
their major attributes. 2-37
 Rapid Prototyping Process?

Structure
the Problem
Repeated
Reformulate Cycle(s)
the Problem
Structure
a Task
Make
Modifications
Build
a Task

2-38
 .....

Layers of KM Architecture
1 User Interface
(Web browser software installed on each user’s PC)
2 Authorized access control
(e.g., security, passwords, firewalls, authentication)

3 Collaborative intelligence and filtering

(intelligent agents, network mining, customization, personalization)
Knowledge-enabling applications
4 (customized applications, skills directories, videoconferencing,
decision support systems, etc
5 Transport
(e-mail, Internet/Web site, TCP/IP protocol to manage traffic flow)
6 Middleware
(specialized software for network management, security, etc.)
The Physical Layer
7
(repositories, cables)

Groupware Data warehousing

Databases Legacy applications (document exchange, (data cleansing,
(e.g., payroll) collaboration) data mining)
2-39
• Then, the blueprint should consider how the
functions of the KMS can be placed into a KM
architecture, consisting of 7 important layers
as shown here.

• Details of these layers in the KM architecture

will be explained in the next lecture.
Knowledge Capture and Transfer Through
Teams

Team performs Evaluate relationship

Outcome
a specialized task between action and
Achieved
outcome

Knowledge
Feedback Developer
Knowledge
transfer
Knowledge method
stored in a selected
form usable by
others in the
organization

2-41
 CHALLENGES IN BUILDING KM SYSTEMS
• Culture
— getting people to share knowledge
• Knowledge evaluation
— assessing the worth of knowledge across
the organization
• Knowledge processing
— documenting how decisions are reached
• Knowledge implementation
— organizing knowledge and integrating it
with the processing strategy for final
deployment

2-42
• Needless to say, there are numerous challenges that one will
expect to face when building KM systems.

• Here, I have listed four which are considered as universal.

• The first challenge is culture. Here, we are not simply referring to

culture as in your place of birth, your nationality, etc.
• The challenge is more than that. It involves the challenge of
getting people to share knowledge, getting people to the point of
willing to share what they know. This challenge is more of an art
of doing it, rather than technical. For a knowledge developer,
one of the primary skills or qualifications is the ability to get the
experts share the tacit knowledge related to the domain of the
KMS that is to build.

• If you are in the position of a manager, what are the ways that
you can think of to encourage your subordinates to share what
they know with one another??
• The next challenge is knowledge evaluation. This involves the assessment
of the worth of knowledge (people, files, documents, databases, etc) that
exist across the entire organization, in order to determine both domain and
scope of KM projects that should be initiated. This will imply a project in
itself, the more substantial the larger an organization. This will imply that
one has to selective in determining what are relevant knowledge, where
they reside, and what benefits they will derive if they are captured and put
in a form that can be shared and used.

• The third challenge is knowledge processing. By knowledge processing, it is

the task of finding out how experts make decision on their tasks based on
the knowledge they possess. This is an important challenge that will
eventually influence the quality of the KM system that is to build.

• Finally, there is the challenge of knowledge implementation. This is most

technical among the four challenges, and are related to the activity of
organizing knowledge that has been identified and integrating it to the
processing strategy being adopted by the organization. Being able to
successfully overcome this challenge is like overcoming the last hurdle
before final deployment of the KM system.
 Vision
• Foresee what the business is trying to
achieve, how it will be done, and how
the new system will achieve goals

2-45
 Resources
• Check on the affordability of the
business to invest in a new KM system

2-46
 Culture
• Is the company’s
political and social
environment open and
responsive to adopting a
new KM system?

2-47
End of Chapter !