Narayanan V.K., Armstrong D.J. - Causal Mapping for Research in Information Technology (2005)(en)
.pdf
320 Iandoli and Zollo
Following this background one expects that sense-making is deeper and more intense in knowledge-intensive organizations (e.g., software companies) working in an unstable environment, facing new and unexpected situations, and performing non-routine tasks. Consequently, explanations provided by software developers regarding the problem of choosing the best life cycle model in the early stages of a new software product development given information about situational constraints should provide considerable and deep knowledge about how people perceive and frame problems, select and attribute meanings and relevance to critical variables, and eventually make their decisions regarding the development process.
In the following section we propose a methodology based on causal mapping to elicit and represent cognitive constructs that software developers activate when requested to choose a life cycle model given some ambiguous and incoherent information about a product’s requirements, customer’s need, and constraints about available resources, costs and development time. Following the above assumptions, causal maps represent a suitable methodological approach because:
a)they allow researchers to obtain a formal representation of cognitive constructs activated by developers as a set of causal relationships; this representation is a practical way to elicit and capture, at least partially and in simplified form, the mental schemata and shared beliefs driving individual actions and choice models;
b)explanatory discourse can be easily translated into causal maps; explanations are very often attempts to provide a picture of cause/effect relationships among facts occurring in the real world;
c)causal maps can be constructed from the analysis of natural language information contained in explanatory discourses.
The Methodology: Eliciting and
Mapping Developers’ Knowlege in the
Life Cycle Selection
The idea proposed in this chapter is that causal mapping can be employed to map individual knowledge contained in explanations provided by software developers in the early stages of a new project when a life cycle model has to be selected. Causal maps can be used to model concepts and the relationships between the concepts contained in explanatory discourses. The proposed methodology is articulated according to the following steps:
a)Sample Selection: one or more development teams made up of experienced practitioners in software development are selected according to certain criteria: i) level of expertise, as recognized by other experts or estimated from their position; ii) variety, in terms of roles, organizational positions, background (Calori, 2000).
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
Knowledge at Work in Software Devlopment 321
b)Problem framing: a set of general framing questions concerning the main decision variables involved in the problem of choosing the “right” life cycle model is designed on the basis of the literature analysis and through a first involvement of the developers;
c)Elicitation: framing questions are employed to collect explanatory discourses through interviews;
d)Coding: explanatory discourses are analyzed to elicit concepts and relationships among them (Fletcher & Huff, 1990); relevant concepts are described in detail and reported in an interview dictionary;
e)Mapping: individual causal maps are used to represent concepts and relationships between concepts and analyzed to identify input and output variables, and influential and relevant concepts;
f)Comparison: individual maps are compared to identify similarities and differences in the framing of the life cycle selection problem across different individuals;
g)Data validation is performed through inter-coder reliability and feedback from interviewees;
h)Implication for decision support: once validated, the results emerging from the causal map analysis can be used to improve the design of Decision Support Systems (DSS) for the selection of the “best” life cycle model.
The choice of interviewing people instead of documentation analysis can be justified given the characteristics of the context. First, documentation containing developers’ opinions and perceptions about how they frame the problem and make their choices during the development process does not exist.
Second, managing a software development project requires coping with ambiguous requirements, facing unexpected situations and making continuous adjustments to the customer’s needs. Developers try to exploit existing knowledge and experience to cope with such novelty. Interviews and explanations try to “force” developers to make sense of an ever changing and unstable environment and to actively reconstruct (ex post) the rationale behind their past behaviors and decisions. Linguistic explanation may play a fundamental role in this reconstructing action because the tacit knowledge of informal organization is very often not known and opaque to its same constructors (Schanck, 1986; Weick, 1976). The taken-for-granted world is the world of the “obvious” and its opacity lies in the uncritical and automatic ways which it is enacted and recalled to memory. For these reasons, interviews, which permit direct involvement and interaction, favor the capture of tacit knowledge more than explicit sources such as written speech and documentation.
The proposed methodology was tested through a case study in an Italian software company producing software for accounting, management, office automation, and telecommunication systems. Other activities of the company concern outsourcing management of data elaboration centers. The company belongs to an important group with more than 1,000 employees, half of which are software developers, and a turnover of 80 million euros in 2002.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
322 Iandoli and Zollo
The activities of a software development team belonging to a specific organizational subunit and involved in the realization of a new product were investigated in depth through the proposed methodology. In the following, a step-by step application of the methodology is presented to provide the reader with practical examples and an overview of the critical issues and results that emerged during and after the field analysis.
Sample Selection
The sample was selected according to the above-mentioned criteria of level of expertise and variety. More specifically, level of expertise was estimated through years of experience in software development, involvement in the development of large projects, and peer and management indication. Through such criteria, it was not difficult to identify an “experienced team.” A satisfying degree of variety was ensured by the way the company selects development teams. The team is usually made up of several developers with different roles (system analyst, programmers, network experts, etc.) and by one or more project managers. Of course team composition and duration depend on the characteristics of the project and may change over time. It is worthwhile to note that the number of people involved in the field research may vary as well depending on the research purpose. For example, if one wants to build a very comprehensive collective knowledge base (Calori, 2000), it is necessary to interview a large number of experts to integrate as many different points of view as possible into representative and reliable descriptions. On the other hand, if the research purpose is to investigate in-depth a given organizational aspect through an action research approach (Argyris & Schon, 1978), the number of people involved may be lower than in the previous case. As far as this chapter is concerned, our aim was to use the field analysis primarily to test the proposed methodology and to provide the reader with as many details as possible. Consequently, the presented results are mainly descriptive. However, in the last two sections of this chapter, we outline how the same methodology can be used to develop prescriptive or supportive tools for software project management.
Problem-Framing
The aim of this step was to identify a set of general framing questions needed to structure the interviews performed in the next step. These questions concerned the main decision variables involved in choosing the “right” life cycle model. The framing questions have been designed starting from the literature analysis. On this basis a framework describing variables considered relevant to the final choice of the life-cycle has been constructed. This framework was then presented to some of the company’s project managers and developers to be validated and integrated before being employed in the interview phase. Project managers’ and developers’ suggestions were collected and used to refine the framework, whose final version is depicted in Figure 2. Given the way it has been constructed, one can look at this framework as a sort of collective representation of the problem of choosing the right life-cycle model, though very general, unspecific and approximate.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
Knowledge at Work in Software Devlopment 323
Framework variables have been grouped into three main clusters:
a)Organizational variables concerning resource availability for the project, investments, manager and team commitment, leadership of the project managers, and organizational culture;
b)Customer-related variables such as requirements, concerns for costs, quality, time, and visibility of changes, i.e., customer perception that his/her requests have been recognized and satisfied through actual changes in the product;
c)Process variables related to production such as team competencies, maintenance, relationships with the customer, and the possibility of further development.
Clusters have been obtained through two steps. In the first step an initial classification was proposed by the authors on the basis of meanings that the considered variables usually assume in the literature. The proposed classification was then refined through developers’ observations and suggestions. Moreover, it emerged that each cluster represented a dominant point of view shaping the way each interviewee perceives and looks at the problem. In other words, among the interviewees, some developers empha-
Figure 2. Variables influencing the choice of life cycle model according to team perception
CUSTOMER
Costs |
Times |
Quality |
Visibility of |
|
|
changes |
|
Requirements |
|
|
O |
Resouces availability |
|
|
|
|
|
|
|
|
R |
Investments |
|
|
|
G |
|
|
|
|
A |
|
|
|
|
N |
|
|
|
Life-cycle |
I |
Committment |
|
|
|
Z |
|
|
|
choice |
A |
|
|
|
|
T |
|
|
|
|
I |
Leadership |
|
|
|
o |
|
|
|
|
O |
|
|
|
|
N |
|
|
|
|
|
Organizational |
|
|
|
|
culture |
|
|
|
|
Competencies |
Relationship with |
Maintenance |
Possibility of |
|
|
further developments |
||
|
of the team |
Customers |
|
|
PROCESS
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
324 Iandoli and Zollo
sized more the customer-related cluster, others seemed more concerned about process, while a third group paid more attention to organizational constraints.
Elicitation
The project manager and four team members were separately interviewed in on-site meetings over two months. Framing questions were used to structure the interview. The framework in Figure 2 was presented at the beginning of the interview as a means of stimulating and triggering the discussion. Each interview, whose duration was on average about two hours, was taped and transcribed.
Interviews were aimed at eliciting explanatory relations among concepts provided by software developers such as concepts’ explication (e.g., “What does quality mean to you?”), causal relationship: (e.g., “How do individual and team competencies influence project development?”), actions and/or decisions justification (e.g., “How do you cope with high risk when choosing priorities?”), and values and personal beliefs driving actions and choice (“How important is it for you to ‘have the control?’”). Interviews developed dynamically through interaction. The interviewer asked participants to explain opinions and beliefs, and to develop arguments until a satisfying level of detail was achieved.
Coding
Interview coding was completed in two steps according to the documentary coding method (Wrightson, 1976), using a concepts dictionary to assemble and identify explanatory relationships between concepts. This method was slightly modified and generalized to code explanatory relationships, which do not express solely causal influence but also justification and concept clarification.
In the first step, relevant concepts were identified and listed; a detailed description of their meaning as emerging from the interview was provided for each concept. Examples of concept descriptions appearing in the dictionary are reported in Table 1.
In the second step the interview text was carefully analyzed to identify and list explanatory relationships linking two or more concepts. For example, in one case, the interviewee underlined the importance of requirements understanding and specifications as follows:
“Requirements are a fundamental variable: they represent 'what you need to do.'
[…]If requirements are ambiguous, as often it is the case, you need to create an effective channel to communicate and interact with the client. This usually means spending money and time. A possible outcome of a successful interaction is the reduction of a requirement, that is a reformulation of the customer request that is both able to satisfy his/her needs and is technically clear and feasible.
[…]A requirement reduction may imply success for a project. Summing up, understanding a customer’s needs has a definite contribution on the quality perception of the customer.”
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
Knowledge at Work in Software Devlopment 325
Table 1. Part of a Concept Dictionary Drawn From One of the Interviews
Control: set of activities needed to manage project’s development.
Dimension: can be assessed in terms of project’s estimated duration in days/months/years.
Flexibility: capability to develop product that are easy to modify and adapt to customer’s requests that may arise during project development.
Quality: perceived performance, usefulness, measure of “what must be done.”
Relationship with customers: needed to make ambiguous requirements expressed by customers. as clear as possible. Customers can be more or less easy to manage … in any case it is necessary to establish a communication channel. Requirements: represent “what you need to do,” what the company must deliver to the customer, and this may or not be always made explicit by the customer itself.
Requirements reduction: is the possibility to reformulate customer’s requests that is both able to satisfy his/her needs and technically clear and feasible. Sometimes reduction means requirements simplification, in other cases it may imply requirements dropping.
Risk: risk may arise from an under-qualified team with little or no experience or from huge dimension of a project or from scare familiarity with new technologies.
Team: work group and its competencies. Technology: tools for development.
Time: it can be a requirement for the customer or time to market.
Visibility of change: represents the possibility to customize the product on the basis of customer’s request.
It is easy to recognize in this quotation the definition of some concepts such as “requirements,” “requirement reduction,” as well as several explanatory relationships that were coded in the following format A -> ex -> B, where ex stands for “explain” and can be read as A explains B, B because A, A is a reason for B to occur, A is (a better) way to say B, A (may) influence B, A (may) cause B. Examples contained in the quotation above are as follows:
Ambiguous requirements –ex–> Create a channel with the client
Create a channel with the client –ex-> Spending time and money
Successful interaction –ex-> requirement reduction
A list of explanatory relationships can be reported on the coding sheet where additional information can be added concerning the location in the text, additional notes aimed at further describing the relationships or reporting emphasis added by the interviewee, and links to other items in the list, as shown in Table 2.
Results
The mapping step may be carried out in a direct way from the results of the coding step whenever text analysis and synthesis have been extensively and carefully performed. Given the coding results, mapping means essentially to assemble the several explanatory relationships that emerged from the coding through the well-known graphical representation of causal maps. It is important to remark that mapping concerns relationships such as A causes B, A influences, B, A has an impact on B, and so on. Explanatory relationships state influence between two concepts.
In Figure 3 an example of a causal map elicited from the interviews is presented. The minus sign on the arches between two concepts represents negative influence.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
