Application 1 – Analysis and Synthesis of Prior Research
& Research Article
Knowledge Management of Interconnected Decisions with Application to Project Management
Reuven Karni 1 and Maya Kaner 2*
1Shenkar College of Engineering and Design, Ramat Gan, Israel 2Ort Braude College, Karmiel, Israel
In this paper we describe a methodology to support decisionmaking in a multiple decision environment using previous experience regarding decisions and their interrelationships. This methodology comprises: (a) new kinds of knowledge which help to better understand the interrelationships between decisions; (b) a human reasoning process incorporating the reuse of past experience in making interrelated decisions; (c) lessons that can be learned or formulated, on the basis of past experience, when current interconnected decisions are to be made. Case- based reasoning (CBR) is used to manage decision knowledge using cases — experience gained from previous decisions. This is complemented by dyad-based reasoning (DBR) to manage the interrelationships between decisions. A dyad is a pair of linked decisions reflecting past experience in making successive decisions. DBR provides a new type of knowledge: the nature and composition of an interconnected set of decisions involving several aspects of a decision- making situation. We demonstrate the application of the proposed methodology to a typical example of a multiple decision environment — project management. When a project manager has to make a number of interrelated decisions while carrying out several project management processes, a dyad knowledge base and DBR provide guidance as to the complementary considerations needed to make a multi-faceted set of decisions. Copyright # 2008 John Wiley & Sons, Ltd.
INTRODUCTION
The relationship between decisionmaking and knowledge management is succinctly stated by Holsapple and Winston (1996): ‘‘Making a decision means that we are making a new piece of knowl- edge that did not exist before.’’ Thus decisionmak- ing both uses and creates knowledge; and hence a fundamental goal of knowledge management is to support decisionmaking and also to benefit from decisions taken. Decision support systems usually
support individual decisions or defined groups of decisions (Shim et al., 2002). However, there exist multiple decision environments such as design (products, software, services), planning (strategies, policies, plans, processes, projects), and manage- ment (people, projects, quality) which involve not just a large number of variegated decisions but also their interrelationships that are often dynamic and undefined. Knowledge and management of these interconnections constitute a major challenge to knowledge-based decisionmaking. We define an interconnection between two decisions as a causal link such that one decision actuates another decision. For example, anticipating problems with
Knowledge and Process Management
Volume 15 Number 4 pp 211–223 (2008)
Published online in Wiley InterScience
(www.interscience.wiley.com) DOI: 10.1002/kpm.313
*Correspondence to: Maya Kaner, Ort Braude College, POB 78, Karmiel 21982, Israel. E-mail: kmaya@braude.ac.il
Copyright # 2008 John Wiley & Sons, Ltd.
a project leads to a decision to reinforce staffing; and this in turn leads to a decision to supplement the project team by recruiting a senior staff member. In our analysis, we are concerned with interconnections at two levels: generic — the types of decision, and specific — the content of the decisions.
A typical example of a multiple decision environ- ment is project management (PMI, 2004). Projects, as they usually impact the whole organization, must be carried out under tight schedules and budgets, require expensive and scarce resources, and need to reflect the continuous changes occurring in the business environment: product life cycles, techno- logical innovation, and fierce competition. During project planning and progress, project managers must make many decisions, such as what team members to choose, how to estimate project activity durations and costs, and what risks to anticipate. These decisions are actually interrelated because, for example, in the case of selecting a team member, the specific team member chosen influences both time and cost activity estimates; and the lack of experience of the team member potentially leads to certain risks being taken. Thus, project decisionmaking provides a real challenge for the project manager. On the one hand, project decisions are repetitive; hence knowl- edge and experience accumulated during past decisionmaking can support future decisions. On the other hand, they recur in different circumstances and may establish other interconnections in different projects or project phases. For example, selection of a project team may initially be dictated by cost considerations or quality factors. However, if the project is falling behind, team members who can help make up lost time will be chosen.
For managing decision knowledge, we adopt the case-based reasoning (CBR) approach (Lee and Kim, 2002). CBR is concerned with supporting new problem solving by using knowledge derived from solving previous problems. The general assumption of CBR is that a problem solution can be obtained from past solutions to similar problems (Kolodner, 1993; Riesbeck and Schank, 1989). In CBR knowledge is represented by cases describing past experiences and containing all relevant information connecting the problem situation (e.g., different circumstances in the same or different projects) and its solution (project manager’s decision in specific circumstances) (Aarts, 1998; Brandt and Nick, 2001; Friedrich et al., 2002). The relevance of CBR relates to the correspondence between past experience (Althoff et al., 2000; Kaner and Karni, 2003) and current decisionmaking.
Originally, CBR was developed to support computer assisted human case-based reasoning. The main activities carried out by a classical CBR
system are described by the R4 cycle presented originally by Aamodt and Plaza (1994). The general CBR process model consists of four phases:
� Retrieve: assess the most similar cases to a given problem. For example, retrieve the most similar cases describing a specific project risk and the corresponding corrective actions that were taken.
� Reuse: locate and assess the solution(s) of the retrieved case(s) to the current problem. For example, if according to past experience, resource allocation was a corresponding reaction to a project risk, in the current situation we may likewise decide to reallocate a resource.
� Revise: check the applicability of the solution to be reused and adopt or adapt it as required. For example, check if it is feasible to reallocate a resource.
� Retain: incorporate ‘‘the lessons learned’’ into the system by adding a new problem and its solution to the case base. For example, a new risk may be identified as a result of the resource allocation, such as a likely cost overrun.
Modern CBR focuses on computerized case-based reasoning using algorithms for case indexing, case retrieval, and case adaptation (Lee and Kim, 2002). In this article we emphasize human case-based reason- ing and do not provide details of automation.
For managing decision interconnections, we intro- duce what we refer to as dyad-based reasoning (DBR). We assume that decision interrelationships can be learned from similar past interconnections. We distinguish two levels of learning: generic and specific. For example, according to past experience, selection of a project team member may lead to a certain risk. The generic level of learning is expressed by the existence of causality between staff selection and risk anticipation decisions. The specific level of learning relates to the specific team member chosen, what actual risks were anticipated and why selection of this particular member triggered anticipation of these risks.
The aim of this paper is: (a) to demonstrate and analyze the complexity of interconnection manage- ment in a multiple decision environment; (b) to propose a human reasoning process incorporating the reuse of knowledge gained both from past decisions and from their interrelationships; and (c) to demonstrate the application of the methodology in a project management environment.
PROJECT MANAGEMENT PROCESSES AND DECISION INTERACTIONS
The Guide to the Project Management Body of Knowledge—PMBOK (PMI, 2004) is an authoritative
212 R. Karni and M. Kaner DOI: 10.1002/kpm
RESEARCH ARTICLE Knowledge and Process Management
sourcebook (American National Standard ANSI/ PMI 99-001-2004) on project management. It categorizes project management practices into nine knowledge areas: project integration management, project scope management, project time manage- ment, project cost management, project quality management, project human resource management, project communications management, project risk management, and project procurement manage- ment. These knowledge areas together comprise 44 project management processes (as opposed to technological product-oriented processes). For example, the project time management area consists of six processes: activity definition, activity sequen- cing, activity resource estimating, activity duration estimating, schedule development, and schedule
control. Each project management process in the PMBOK is described in terms of its inputs, tools and techniques, and outputs.
Project management processes are, alternatively, categorized into five activity groups: initiating, planning, executing, monitoring and controlling, and closing processes. In this article we focus on the planning process group, covering the planning of a project. Figure 1 (PMI, 2004) sets out the planning processes and illustrates examples of explicit inter- connections — such as that between cost estimating and activity duration estimating.
Table 1 lists the planning processes and details implicit interconnections when an output of one process becomes an input of another process. For example, the work breakdown structure (WBS) is an
Scope
Definition
Develop Project
Management
Plan
Risk
Management
Planning
Risk
Identification
Qualitative
Risk Analysis
Quantitative
Risk Analysis
Create
WBS
Plan
Purchases and
Acquisitions
Scope
Planning
Activity
resource
estimating
Cost
Estimating
Cost
Budgeting
Human
Resource
Planning
Activity
Definition
Activity
duration
estimating
Activity
Sequencing
Schedule
development
Quality
Planning
Communications
Planning
Plan
Contracting
Risk
Response
Planning
Initiating
Process Group
Executing
Process Group
Closing
Process Group
Monitoring
& Controlling
Process
Group
Figure 1 Planning process group — process interactions (PMI, 2004)
Knowledge Management, Interconnected Decisions, and Project Management 213 DOI: 10.1002/kpm
Knowledge and Process Management RESEARCH ARTICLE
Table 1 Project management planning processes — inputs and outputs (PMBOK, 2004)
Process Inputs Outputs
Develop project � Preliminary project scope statement � Project management plan management plan � Project management processes
� Enterprise environmental factors � Organizational process assets
Scope planning � Enterprise environmental factors � Project scope management � Organizational process assets � Project charter � Preliminary project scope statement � Project management plan
Scope definition � Organizational process assets � Project scope statement � Project charter � Requested changes � Preliminary project scope statement � Project scope management � Project scope management plan plan (updates) � Approved change requests
Create WBS � Organizational process assets � Project scope statement (updates) � Project scope statement � Work breakdown structure � Project scope management plan � WBS dictionary � Approved change requests � Scope baseline
� Project scope management plan (updates)
� Requested changes Activity definition � Enterprise environmental factors � Activity list
� Organizational process assets � Activity attributes � Project scope statement � Milestone list � Work breakdown structure � Requested changes � WBS dictionary � Project management plan
Activity sequencing � Project scope statement � Project schedule network diagrams
� Activity list � Activity list (updates) � Activity attributes � Activity attributes (updates) � Milestone list � Requested changes � Approved changes requests
Activity resource � Enterprise environmental factors � Activity resource requirements estimating � Organizational process assets � Activity attributes (updates)
� Activity list � Resource breakdown structure � Activity attributes � Resource calendar (updates) � Resource availability � Requested changes � Project management plan
Activity duration � Enterprise environmental factors � Activity duration estimates estimating � Organizational process assets � Activity attributes (updates)
� Project scope statement � Activity list � Activity attributes � Activity resource requirements � Resource calendar � Project management plan
� Risk register � Activity cost estimates
Schedule development � Organizational process assets � Project schedule � Project scope statement � Schedule model data � Activity list � Schedule baseline � Activity attributes � Resource requirements (updates) � Project schedule network diagrams � Activity attributes (updates) � Activity resource requirements � Project calendar (updates) � Resource calendar � Requested changes � Activity duration estimates � Project management
plan (updates) � Project management plan � Schedule management
� Risk register plan (updates)
(Continues)
214 R. Karni and M. Kaner DOI: 10.1002/kpm
RESEARCH ARTICLE Knowledge and Process Management
Table 1 (Continued)
Process Inputs Outputs
Cost estimating � Enterprise environmental factors � Activity cost estimates � Organizational process assets � Activity cost estimate
supporting detail � Project scope statement � Requested changes � Work breakdown structure � Cost management plan (updates) � WBS dictionary � Project management plan (activity list,
activity resource requirements) � Schedule management plan � Staffing management plan � Risk register
Cost budgeting � Project scope statement � Cost baseline � Work breakdown structure � Project finding requirements � WBS dictionary � Cost management plan (updates) � Activity cost estimates � Requested changes � Activity cost estimate
supporting detail � Project schedule � Resource calendars � Contract � Cost management plan
Quality planning � Enterprise environmental factors � Quality management plan � Organizational process assets � Quality metrics � Project scope statement � Quality checklists � Project management plan (cost � Process improvement plan
management plan) � Quality baseline � Project management
plan (updates) Human resource planning � Enterprise environmental factors � Roles and responsibilities Roles
and responsibilities � Organizational process assets � Project organization charts � Project management plan (time, cost
estimates) Project management plan (quality metrics, risks)
� Staffing management plan Staffing management plan
� Activity resource requirements Communications planning � Enterprise environmental factors � Communications management plan
� Organizational process assets � Project scope statement � Project management plan
� Constraints � Assumptions
Risk management planning � Enterprise environmental factors � Risk management plan � Organizational process assets � Project scope statement � Project management plan
Risk identification � Enterprise environmental factors � Risk register Risk register � Organizational process assets � Project scope statement � Risk management plan � Project management plan (activity list)
Project management plan (cost management plan)
Qualitative risk analysis � Organizational process assets � Risk register (updates) � Project scope statement � Risk management plan � Risk register
Quantitative risk analysis � Organizational process assets � Risk register (updates) � Project scope statement � Risk management plan � Risk register
(Continues)
Knowledge Management, Interconnected Decisions, and Project Management 215 DOI: 10.1002/kpm
Knowledge and Process Management RESEARCH ARTICLE
output of ‘‘Create WBS’’ and an input into ‘‘Activity definition.’’
Process interconnections are dynamic and com- plicated as, theoretically, each process can interact with many other processes. This is expressly recognized in the PMBOK (PMI, 2004): ‘‘. . . processes interact with each other in a complex way that cannot be completely explained in a document or with graphics.’’ Thus there is a real challenge to provide a tool to support the project manager when he/she is called upon to make interrelated decisions.
In a typical project environment many decisions regarding project scope, schedule, cost, and risks are taken when planning processes are enacted. Hence interdependence between project management processes establishes interconnectivity between corresponding decisions. In our research we refer to interconnections between project management processes from a decisionmaking perspective, when a decision within one process actuates a decision
within another process. In order to demonstrate the challenge of decision interconnections we illustrate two ways, out of many possibilities, for a team member to be selected for executing a specific activity.
In the first example the project manager puts together a project team based on cost and time; in the second example his considerations are based on quality. The corresponding decision interconnections, expressed by an output entity from an actuating process, and the same entity as an input to an actuated process, are emphasized in Table 1: represented in italics for the scenario in Figure 2 and illustrated through the use of underlining for the scenario in Figure 3.
The interpretation of Figure 2 is:
The project manager receives the project management plan and scope statement and creates a work break- down structure (WBS) (decision a: how to translate the project scope statement into a WBS; ‘‘create
Table 1 (Continued)
Process Inputs Outputs
� Project management plan � Project schedule management
plan � Project cost management plan
Risk response planning � Risk management plan � Risk register (updates) � Risk register � Project management plan
(updates) � Risk-related contractual
agreements Plan purchases and � Enterprise environmental factors � Procurement management plan acquisitions � Organizational process assets � Contract statement of work
� Project scope statement � Make-or-buy decisions � Work breakdown structure � Requested changes � WBS dictionary � Project management plan
� Risk register � Risk-related contractual
agreements � Resource requirements � Project schedule � Activity cost estimates � Cost baseline
Plan contracting � Procurement management plan � Procurement documents � Contract statement of work � Evaluation criteria � Make-or-buy decisions � Contract statement of work
(updates) � Project management plan
� Risk register � Risk-related contractual
agreements � Resource requirements � Project schedule � Activity cost estimate � Cost baseline
216 R. Karni and M. Kaner DOI: 10.1002/kpm
RESEARCH ARTICLE Knowledge and Process Management
WBS’’). For the deliverables within the WBS he/she tries to understand how similar items in the past were decomposed into activities (decision b: what activities to formulate; ‘‘activity decomposition’’). For these activities he/she determines: (a) what resources are required (decision c: what resources to choose, ‘‘activity resource estimating’’); and (b) in conjunc- tion with the project scope statement he/she identifies what risks could be triggered when developing deliverables (decision d: what risks to anticipate, ‘‘risk identification’’). For each activity, its resource type, and the expected risks, the manager estimates a duration (decision e: what time estimate to provide, ‘‘activity duration estimating’’) and a cost (decision f: what cost estimate to provide, ‘‘cost estimating’’). In accordance with the time and cost estimates associated with the resource requirement, he/she selects the best candidate for carrying out the activity (decision g: what candidate to choose, ‘‘human resource plan- ning’’).
The interpretation of Figure 3 is:
The project manager revises the cost management plan (decision 1: what budget estimate to provide, ‘‘cost budgeting’’). For items in the updated cost manage- ment plan he/she tries to understand (a) what risks could be expected (decision 2: what risks to manage, ‘‘risk identification’’); (b) what quality level should be provided (decision 3: what quality standards to define,
‘‘quality planning’’); and (c) what deliverables should be made or purchased (decision 4: what outsourcing resources to choose, ‘‘plan purchases and acqui- sitions’’). For each ‘‘make’’ activity, in the light of expected risks and planned quality metrics, he/she selects the best candidate to perform the activity (decision 5: what candidate to choose, ‘‘human resource planning’’).
These examples demonstrate the dynamics and diversity of decision interactions. We propose a framework to cope with this difficulty.
METHODOLOGY
Decisionmaking levels
We consider three levels of decisionmaking as follows:
� Case — a specific decision associated with a project management process and described by its domain problem (P) and solution (S) attributes and their instances. Cases comprise past experi- ences. Table 2 illustrates examples of cases, attributes, and their instances for three types of decisions: human resource planning, activity duration and cost estimating, and risk identifi- cation and response.
� Dyad — two successive linked actuating and actuated cases representing two decisions and the causal relationship between them. These causal relationships can be interpreted at two levels of granularity: (1) decision types and inter- type causal relationships (e.g., risk anticipation (R) affects the way in which a team member is selected (C)); and (2) decision content and inter- content causal relationships (e.g., foreseeing a problem of an employee leaving a software project (R1) resulted in resource allocation
Activity
decompositionCreate WBS
Activity
resource
estimating
Risk
identification
Cost
estimating
Activity
duration
estimating
Human
resource
planning
Project
management
plan
Project scope
statement
Figure 2 Interconnected decisions — first scenario
Cost budgeting
Plan purchases and acquisitions
Human resource planning
Cost management
plan
Risk identification
Quality planning
Figure 3 Interconnected decisions — second scenario
Knowledge Management, Interconnected Decisions, and Project Management 217 DOI: 10.1002/kpm
Knowledge and Process Management RESEARCH ARTICLE
through selection of a beginner as a programmer for the project (C1)).
� Dyad chain — these comprise experiences of several interconnected decisions. Figure 4 illus- trates the dyad chain: R1-C1, C1-E1, E1-R2, R2-E2, and E1-C2. At the type level the chain is interpreted as: risk anticipation led to candidate selection (R-C); candidate selection led to task duration and cost estimation (C-E); task duration and cost estimation led to risk anticipation)E-R); and task duration and cost estimation led to candidate selection (E-C). At the content level it is interpreted as follows: ‘‘Foreseeing a problem of an employee leaving the project resulted in
resource allocation (R1) leading to selection of a beginner for a software quality assurance of a human resource system (C1). The beginner candidate selection determined the planned task duration (1–1.5) and cost (40 000–50 000) esti- mates (E1). This in turn led to (a) determination of the candidate salary (C2) and (b) anticipation of a problem of cost overhead triggered by change in environment (e.g., budget cutting) (R2). Foresee- ing this problem led to a revision of task duration and cost (E2).’’
Kinds of knowledge
By comparing past and current decisions and their interconnections we distinguish seven kinds of knowledge, representing three aspects of learning. The first aspect relates to monadic and dyadic knowledge. Monadic knowledge involves learning from past individual decisions. Dyadic knowledge deals with learning from the interrelationships between past decisions. The second aspect
Table 2 Cases, attributes, and instances — examples
(a) Cases associated with ‘‘human resource planning’’
Case Problem Solution
Specialization System Experience Salary
C1 Quality assurance Human resources Beginner C2 Quality assurance Human resources Beginner 10 000–15 000
(b) Cases associated with ‘‘activity duration estimating’’/‘‘cost estimating’’
Case Problem Solution
Task description (specialization)
Task description (system)
Duration estimate
Duration cost
E1 Quality assurance Human resources 1–1.5 40 000–50 000 E2 Quality assurance Human resources 2–2.5 60 000–70 000
(c) Cases associated with ‘‘risk identification’’/‘‘risk response planning’’
Case Risk category
Risk Problem Solution
Reason/trigger category
Reason/trigger Corrective action category
Corrective action
R1 Staff Staff resigning Customer Change in requirements
Staff Staff allocation
R2 Cost Overhead Environment Change in conditions
Cost Release of budget reserve
R1 C1 E1
R2
C2
E2
Figure 4 Example of a dyad chain
218 R. Karni and M. Kaner DOI: 10.1002/kpm
RESEARCH ARTICLE Knowledge and Process Management
corresponds to dyad granularity. Type knowledge refers to the domains within which decisions are taken. Content knowledge refers to actual details of the two linked decisions and their interdependence. Finally the third aspect is concerned with the comparison of dyad structures between past and present decisionmaking. The seven kinds of knowl- edge are listed below.
(1) Monadic knowledge (analogous content): � We learn from a previous past solution. � We start from a new case and look for similar
cases according to the problem description. � We adopt the past knowledge and record a
new case with the previous solution.
(2) Monadic knowledge (additional content): � We learn from the absence of an acceptable
previous solution. � We start from a new case and look for similar
cases according to the problem description; either no similar problem is found or all solutions are rejected.
� We reject past knowledge and record a new case with a new solution; current experience has resulted in a new decision (new knowl- edge).
(3) Dyadic knowledge (analogous type): � We learn from the causal relationship bet-
ween actuating and actuated decision types. � We start from the actuating type of decision
and look for a linked actuated decision. � We adopt the type of the actuated decision
and the interconnection between actuating and actuated decision types. This enables us to select the type of the second decision to be made.
(4) Dyadic knowledge (analogous content): � We learn from the causal relationship
between two interrelated cases and the case contents.
� We start from an actuating case and look for an actuated case.
� We adopt the interconnection between the two cases and their contents and record a new dyad with the adopted actuated case.
(5) Dyadic knowledge (additional type): � We learn from the fact that we create a
decision type pair which has not been created in the past.
� We start from the actuating type of decision and look for an actuated type of decision.
� We reject the actuated types of decisions found and create a new interconnection with the actuated decision type.
(6) Dyadic knowledge (additional content): � We learn from the fact that we create a
decision pair which has not been created in the past.
� We start from the actuating case and look for an actuated case.
� We reject the actuated case and create a new interconnection and actuated case and record a new dyad with a new actuated case.
(7) Dyadic knowledge (absent type and content): � We learn from the fact that no dyad has been
created involving the actuating decision. � We start from the actuating case and look for
an actuated case. Such a case is not found. � We create a new interconnection and actuated
case and record a new dyad with a new actuated case.
Human enacted case-based and dyad-based reasoning
Figures 5 and 6 illustrate human enacted case-based and dyad-based reasoning. Using case-based reasoning, the decisionmaker defines his problem and searches for similar past cases. He/she adopts or rejects these cases by means of monadic knowl- edge. Using dyad-based reasoning he/she searches for similar dyads. He/she adopts or rejects past interconnections by means of dyadic knowledge. He/she passes between CBR and DBR until he/she feels that he/she has taken all necessary decisions. In order to automate these procedures definitions are required for monadic and dyadic similarity measures and threshold values; these are outside the scope of this article.
Regarding the process in Figure 6 we note that when a similar first case is found it could be the actuating or actuated decision. If it is an actuating decision, dyadic knowledge will be obtained regarding subsequent decisions. If it is an actuated decision, knowledge will be obtained regarding precedent decisions. The first instance will answer the question: ‘‘what decisions could be made after the current decision?’’ We wish to know if complementary decisions are required. The second instance will answer the question: ‘‘what decisions led to the current decision?’’ We wish to know what influences could have affected the current decision, which are not yet accounted for, and therefore may require revision of the current decision.
Blessing et al. (2001) describe a program to gain knowledge from (software) project experience and making it available to project teams. They define four ‘‘project experience processes’’: project knowledge creation; project knowledge preservation; project
Knowledge Management, Interconnected Decisions, and Project Management 219 DOI: 10.1002/kpm
Knowledge and Process Management RESEARCH ARTICLE
knowledge maintenance; and project knowledge usage. All these processes are included in our scheme: knowledge is created when a decision or decisions are made; knowledge is preserved in the case or dyad base; knowledge is maintained when outdated or inferior solutions are rejected; and knowledge is used whenever a case or dyad search is initiated.
Example
We can explain the reasoning procedures represented in Figures 5 and 6 as follows (see Tables 2 and 3):
� The project manager is required to select a candidate for a maintenance system software
Select (first) case
Search dyad base
Similar first
case found?
Add
decision?
Stop Define type
seY oN
No
Second case
type OK?
Adopt dyad
Store dyad
Yes
No
Second case
content OK?
Dyadic
absent
Dyadic
analogous
content
Dyadic
analogous
type
Yes
Establish
interaction
Perform
CBR Dyadic
additional
or absent
type
Perform
CBR
Store new
dyad
Dyadic
additional
content
No
Store new
dyad
Yes
Figure 6 Dyad based reasoning (DBR) — a human reasoning process flowchart
From DBR
Determine case
category
Determine case
problem (input)
Search relevant case
base
Similar case
found? Evaluate past solutionMake new solution
Store new case (P, S)
Past solution
OK?
Make new solution Adopt case
Store new case (S)
Yes No
Store updated case
To DBR
No Yes
Monadic
additional
content
Monadic
analogous
content
Figure 5 Case based reasoning (CBR) — a human reasoning process flowchart
220 R. Karni and M. Kaner DOI: 10.1002/kpm
RESEARCH ARTICLE Knowledge and Process Management
development. He/she looks for cases associated with ‘‘human resource planning.’’
� He finds no similar cases in the ‘‘human resource planning’’ case base (hence: new problem). He/ she therefore makes a new decision (new solution): selection of a beginner with a given salary (10 000–15 000) for maintenance system software development activity.
� A new case is stored (C3). � He wishes to know whether he/she should take a
further decision and therefore searches the dyad base with C3. He/she finds two similar cases: C1 and C2. These are included in three dyads: C1-E1, R1-C1, and E1-C2. He/she notices that a succes- sive decision has been made regarding activity duration and cost estimating (E1); a previous decision had been made regarding risk anticip- ation (R1); a previous decision had been made regarding activity duration and cost estimating (E1).
� He first examines the dyad C1-E1 and agrees that the activity duration and cost should be esti- mated. However, he/she rejects the content of E1 and performs CBR to find a better decision.
� He finds no similar cases in the ‘‘activity duration and cost estimating’’ case base (hence: new
problem). He/she therefore makes a new decision (new solution): task duration (1.5–2) and cost (30 000–40 000) estimates for mainten- ance system software development activity.
� A new case is stored (E3). A new dyad is stored (C3-E3).
� He chooses not to continue this line of action. � He next examines the dyads R1-C1, E1-C2 and
comes to the conclusion that R-C and E-C inter- actions are not relevant to him. Nevertheless, he/she wishes to check a risk anticipation (R) as a result of his previous decision (C1).
� He establishes a new interconnection between C (type) and an R (type): ‘‘Selection of a beginner leads to risk anticipation.’’
� He performs CBR to find similar cases. � No similar cases are found in the case base. He/
she makes a new decision. � A new case is stored (R3). � He decides to continue the line of action. He/she
searches the dyad base with R3. A similar dyad is found: R1-C1. The dyad type is not acceptable (see above). He/she establishes a new intercon- nection between R3 and an E type of decision: ‘‘Risk anticipation (project delay) leads to the necessity to revise cost and duration estimates.’’
Table 3 Cases added — example
(a) Cases associated with ‘‘human resource planning’’
Case Problem Solution
Specialization System Experience Salary
C3 Software development Maintenance Beginner 10–15 K
(b) Cases associated with ‘‘activity duration estimating’’/‘‘cost estimating’’
Case Problem Solution
Task description (specialization)
Task description (system)
Duration estimate Cost estimate
E3 Software development Maintenance 1.5–2 30 000–40 000 E4 Software development Maintenance 3–3.5 50 000–60 000
(c) Cases associated with ‘‘risk identification’’/‘‘risk response planning’’
Case Risk category Risk Problem Solution
Reason/trigger category
Reason/trigger Corrective action category
Corrective action
R3 Staff Experience Customer Change in requirements
Time Project delay
Knowledge Management, Interconnected Decisions, and Project Management 221 DOI: 10.1002/kpm
Knowledge and Process Management RESEARCH ARTICLE
� He performs CBR to find similar cases dealing with duration and cost estimates for software (problem) development of the maintenance system. He/she finds one similar case E3. However, he/she rejects the estimates given (solution) and creates new estimates (E4).
� A new case is stored (E4). A new dyad is stored (R3-E4): ‘‘Anticipation of a problem of lack of experience triggered by a possible change in requirements (R3) led to a revision of task duration and cost (E4).’’
� He chooses not to make any further decisions.
Figure 7 illustrates the current chain of decisions. Four cases (Table 3) and three dyads (C3-R3, C3-E3, R3-E4) have been added. Their interpretation is as follows:
‘‘Selection of a beginner with a given salary for maintenance system software development (C3) led to (a) recording of a case reflecting initial duration (1.5–2) and cost (30 000–40 000) estimates (E3); and (b) anticipation of a problem of lack of experience triggered by a possible change in requirements (R3). Foreseeing this problem led to a revision of task duration and cost (E4).’’
Table 4 provides a comparison between current (Figure 7) and past (Figure 4) interconnections in terms of the dyadic knowledge involved in the example.
CONCLUSIONS
Multiple decision environments involve not only a large number of decisions but also their inter- relationships that are usually dynamic and often undefined. We have illustrated this through project management. Janczak (2004) distinguishes three categories of managerial processes when under- taking projects: analytic, intuitive, and pragmatic. Analytic project managers (‘‘analysts’’) regard projects as problems to be solved. They focus on seeking solutions; and their search activities are therefore based on the need for generating efficient solutions. They collect and store explicit knowledge; and, ‘‘by solving problems, analysts [do] in fact develop their knowledge resources’’ (compare the opening sentence to this article) and integrate knowledge by standardizing solutions. Their modus operandi is thus to search for problems and deliver solutions. This analytic managerial style accords well with the problem-solution approach we have presented and the use of case and dyad bases as knowledge repositories.
In general, the concepts of case-based reasoning, and the proposed dyad-based reasoning, constitute an integrative tool for recording decisionmaking experiences, on the one hand, and for utilizing them on the other. They provide not only details of previous decisions and their interrelations, but also
C3
R3
E3
E4
Figure 7 Current dyad chain — example
Table 4 Current and past decisionmaking — comparison
Current dyad Past dyad Interpretation
Dyadic analogous type knowledge (C,E) (R,E) Candidate selection leads to duration and cost estimation
Risk anticipation leads to duration and cost estimation
Dyadic additional content knowledge (C3, E3) (C1, E1) According to past experience, the beginner candidate selection
for assurance of software quality determined the initial task duration (1–1.5) and cost (40 000–50 000) estimates. According to current experience candidate selection for software development determined the initial task duration (1.5–2) and cost (30 000–40 000) estimates.
(R3, E4) (R2, E2) According to past experience, anticipation of a problem of cost overhead led to a revision of task duration and cost. According to current experience, anticipation of a problem of lack of experience led to a revision of task duration and cost.
Dyadic absent knowledge (C, R) (C) According to past experience, no follow through occurred when a candidate
was selected. Currently, a risk was anticipated when a candidate was selected.
222 R. Karni and M. Kaner DOI: 10.1002/kpm
RESEARCH ARTICLE Knowledge and Process Management
enriched knowledge about how the current episode compares to previous episodes. We have termed this knowledge ‘‘dyadic knowledge.’’ It presents us with answers to questions as follows:
� Was any decision made after the type of decision I am making now?
� If so, what types of decisions were made after the decision I am making now? Should I take a similar type of decision?
� If so, what actual decisions were made after the decision I am making now? Should I take a similar decision?
� If not, should I nevertheless make a further decision? If so, what type of decision should I make?
The answers to these questions characterize the lessons that can be learned or formulated, on the basis of past experience, when current decisions are taken. These are:
� If I accept a type–type connection, I have learned what type of additional decision I should now make.
� If I reject all type–type connections, and never- theless make an additional decision, I have created a new type–type causality. I should explain this new causality, justifying the differ- ence between current and past experiences.
� If I accept a content–content connection (causality implied by the two decisions), I have learned something about nature of the decision I should now make.
� If I reject all content–content connections (caus- ality implied by the two decisions), and never- theless make an additional decision of a different nature, I have created a new decision. I should explain this, justifying the difference between current and past experiences.
� If I find no connections at all, and nevertheless make an additional decision, I have created a new type–type and content–content link. I should explain this new connection, justifying the difference between current and past experiences.
� Although I have no more decisions to make, it may happen that subsequent decisions have nevertheless been made in the past. This can
guide me when, at a later stage, I have to make further decisions.
REFERENCES
Aamodt A, Plaza E. 1994. Case-based reasoning: founda- tional issues, methodological variations, and system approaches. AI Communications 7(1): 39–59.
Aarts RJ. 1998. A CBR architecture for project knowledge management. In EWCBR-98, Lecture Notes in Artificial Intelligence 1488, Smyth B, Cunningham P (Eds). Springer Verlag: Berlin; 414–425.
Althoff KD, Bomarius F, Tautz C. 2000. Knowledge man- agement for building learning software organizations. Information Systems Frontiers 3(4): 349–367.
Blessing D, Goerk M, Bach V. 2001. Management of customer and project knowledge: solutions and experi- ence. Knowledge and Process Management 8(2): 75–90.
Brandt M, Nick M. 2001. Computer-supported reuse of project management experience with an experience base. In LSO, Lecture Notes in Computer Science 2176, Althoff K-D, Feldmann RL, Mueller W (Eds). Springer Verlag: Berlin; 178–189.
Friedrich R, Iglezakis I, Klein W, Pregizer S. 2002. Experi- ence-based decision support for project management with case-based reasoning. In Proceedings of the 1st German Workshop on Experience Management, Lecture Notes in Informatics, Minor M, Staab S (Eds). Springer Verlag: Berlin; 139–150.
Holsapple CW, Whinston A. 1996. Decision Support Sys- tems: A Knowledge-Based Approach. West Publishing: St. Paul, MN.
Janczak S. 2004. How middle managers integrate knowl- edge within projects. Knowledge and Process Management 11(2): 210–224.
Kaner M, Karni R. 2003. Experience management within project management processes. In Proceedings of the 2nd German Workshop on Experience Management, Luzern, Switzerland, 400–408.
Kolodner J. 1993. Case-Based Reasoning. Morgan Kauf- mann: San Mateo.
Lee JK, Kim JK. 2002. A case-based reasoning approach for building a decision model. Expert Systems 19(3): 123– 135.
PMI. 2004. A Guide to the Project Management Body of Knowledge (PMBOK). Project Management Institute Standards Committee.
Riesbeck CK, Schank R. 1989. Inside Case-Based Reasoning. Erlbaum Publishers: New Jersey.
Shim JP, Warkentin M, Courtney JF, Power DJ, Sharda R, Carlsson C. 2002. Past, present, and future of decision support technology. Decision Support Systems 33: 111– 126.
Knowledge Management, Interconnected Decisions, and Project Management 223 DOI: 10.1002/kpm
Knowledge and Process Management RESEARCH ARTICLE