MSc. Thesis on Software Development, Organizational Knowledge, and Outsourcing – By T. Silva

1. Introduction

 

It is almost trite to state that software development is a knowledge intensive activity (Robillard 1999; Desouza 2003). After all, the construction of all but the smallest of software systems relies on the integration of a large body of knowledge held by different individuals. Many such requisite areas of knowledge have been identified in previous research studies, including knowledge of development processes, of technologies, the application domain, software engineering and design techniques, local organizational policies and practices, and even the locations of local experts. (Waterson, Clegg et al. 1997; Faraj and Sproull 2000; Iivari, Hirschheim et al. 2001; Rus, Lindwall et al. 2002)

 

Despite the identification of such a diversified body knowledge, much of the focus on knowledge issues within software engineering has been on the effective reuse and transmission of knowledge and experiences with tools, languages and development activities (Dingsoeyr and Conradi 2002). Requirements, and domain knowledge, have long been recognised as the most important prerequisite for the development of software (Bell and Thayer 1976), but these have not been addressed using concepts from theories drawn from the literature on organizational and individual knowledge.

 

(Ciborra 2000) points out the difference that exists between the high grounds of IS methodology and the daily “swamp” of real world projects. Much of the existing literature that addresses requirements can be said to exist on level of the former – following a prescriptive approach in specifying methods of acquiring and notation of such knowledge . Few exceptions to this exist, in the work of authors such as (Curtis, Krasner et al. 1988; Walz, Elam et al. 1993; Kraut and Streeter 1995) whose accounts of the software development process paint a messier, and more realistic, picture of the work practices and the environment surrounding software requirements.

 

This work follows in this vein, by delving into the swamp, in order to explore how professionals working in an offshore software development firm build up an understanding of software requirements and the application domain necessary for the construction of a software system. It addresses the lack of research given to the knowledge aspect of this by using a perspective informed by the literature on organizational knowledge. Following (Schultze and Leidner 2002)’s categorization of knowledge research within the information systems field (Appendix X), the perspective used here falls within the category of interpretive discourse – focusing on knowledge as an integral part of situated work and organizational practices, shaped by the social context. Overall, this research can be seen as a combination of three areas of research from which the field of information systems draws upon – the software development process, organizational knowledge, and co-operative workplace studies.

 

This remainder of this dissertation is structured as follows: The next chapter reviews the literature relevant to this topic, namely that relating to knowledge as well as software requirements. This is followed by an introduction to the epistemology underlying this research, as well as an overview of the methodology followed. The FOURTH chapter provides the general context of the offshore software development firm selected as the research site. The FIFTH chapter outlines and discusses some of the research findings relevant to the themes found in the literature. The final conclusions of this research are drawn in the SIXTH chapter, followed by a discussion of the limitations and suggestions for further research.

2. Literature Survey

 

In order to frame the theoretical perspective and methodology used in this research, the available academic literature pertaining to both organizational knowledge and software requirements were examined. The main findings derived from this study are presented below.

 

2.1 Knowledge

 

The concept of knowledge has been subjected to various interpretations and categorizations as an object of interest for academic research and of real-world practice. One of the most influential works on knowledge has been that of (Nonaka 1994), who proposed that it was created through the conversion between tacit and explicit knowledge, or through interactions between similar types of knowledge, such as tacit/tacit and explicit/explicit. While the emphasis of his work was on the importance of sharing and social experience in the creation of knowledge, the actual genesis and retention of this was seen as occurring on the level of the individual.

 

The dimensions of tacit and explicit knowledge were also recognized by (Spender 1996), who made the additional distinction between the collective and individual forms of knowledge in his framework. He argued that knowledge and behaviour within organizations or groups could not be simply treated as a “sum” of individual components. Activity in collectives is socially embedded, and the knowledge that arises through this has an existence beyond that of the individuals. (Choo 2000) also includes the social form of knowledge within his framework, where it is termed “cultural knowledge”, and exists independently of the tacit and explicit categories.

 

What frameworks such as these, as well as a number of other papers in the knowledge management field have in common (such as (Johannessen, Olaisen et al. 2001) and (Hedlund 1994)), is the consideration of the tacit and explicit dimension as a dualism, whereby knowledge is seen to belong to one category or the other in an ‘either/or’ fashion (Hislop 2002). Within this stream of thought it is not uncommon for practitioners and real world organizations to focus on what (Hansen, Nohria et al. 1999) have termed the “codification” strategy – the conversion of tacit knowledge into explicit – as seen in accounts by (Huang 1997; Dingsoeyr and Conradi 2002; Romaldi 2002). This approach follows the ideal of objective science in trying to abstract a disembodied body of knowledge beyond the context in which it currently resides, whereupon it can be much more easily transferred to new situations. The techniques adopted by practitioners following this approach are generally based around the design and operation of repositories of knowledge shared among a large group of people within the organization.

 

In contrast to this, some researchers make the claim that tacit knowledge is inarticulable, This leads to the promotion of “personalization” strategies that seek to put knowledgeable people in contact with each other (Desouza 2003).  The most common manifestation of this viewpoint in practice is in the form of organizational “yellow pages” (Alavi and Leidner 2001).

 

A similarity can be seen between this latter viewpoint and work by authors such as (Brown and Duguid 1991; Brown and Duguid 1998) (McDermott 1999; Swan, Newell et al. 1999; Wegner and Snyder 2000) within the “communities of practice” stream of research. This, posits a view akin to Spender’s notion of collective knowledge, arguing that a significant part of the tacit “know how” in organizations is shared among employees within socially cohesive work groups. Knowledge is transferred through personal relationships, aided by shared meanings for “established” members and through legitimate peripheral participation for new initiates.

 

With regard to dichotomous treatments of the tacit and explicit concepts of knowledge, such as those mentioned in the previous sections, (Tsoukas 2002) states that the work of Michael Polanyi is “frequently referred to, but little understood”. In Polanyi’s original argument, tacit and explicit knowledge are mutually constitutive of each other, the former providing the backdrop against which all action is understood. Thus the assumption that tacit and explicit knowledge form discrete, stable, and separate, categories is not workable in the real world (Tsoukas 1996). (Cook and Brown 1999) argue for a similar re-interpretation of Polanyi. They also draw upon the work of the Pragmatist philosopher John Dewey in emphasizing that, what people and groups know is by itself of little importance without reference to “knowing” – the epistemic work done as part of action, and advocate the consideration of what they term an epistemology of practice.

 

Not only is tacit and explicit knowledge tied up with each other, they are also inextricably linked to the context of action. This conflicts with the treatment of the knowledge development as a purely intellectual process, a heritage of the Cartesian dichotomy between the body and the mind (Hislop 2002). Support for this viewpoint exists in empirical accounts by (Schon 1983), of how professionals engage in what he terms “reflection-in-action“ – a spontaneous and simultaneous combination of thinking and doing – and also by (Orlikowski 2002) who described how workers in a large software development firm enacted knowledgeable work practices shaped by their everyday work as well as their organizational context. A related point of note is that knowledge is not simply something that is simply transferred from one person to another, but arises in new contexts through the purposeful adoption of useful practices by people. This process of “mutates” the knowledgeable practices as the receiver makes sense of the usefulness and application of it for his own activities (Venters, Cushman et al. 2003).

 

Some attempts have been made to catalogue the diverse approaches to knowledge in the literature. All of them recognize the prevalence of the “knowledge as an asset” approach, generally linking it to the functionalist paradigm or the Cartesian school of thought. Some of these provide the “social”  or “community” view as the alternative (Swan, Newell et al. 1999; Empson 2001). (Sorensen and Kakihara 2002) provide three alternatives to the traditional “image” of knowledge as an asset, emphasizing the subjective, processual, and relational aspects of it.  As useful as these concepts are, it must be kept in mind that real world studies are rarely situated completely within a single category. For example the community of practice studies address knowledge simultaneously as something subjective and relational. This can be seen as directly related to (Spender 1998)s claim that no single reference system can describe knowledge in the real world, upon which he builds up the argument for the usage of a pluralist and situated epistemology of knowledge.

 

Given the multifaceted and complex nature of knowledge, and the various approaches and views prevalent in the literature, how do we understand what knowledge in an organization really is? (Davenport and Prusak 1997) provide a useful definition that captures the processual and contextual nature of knowledge.

 

“Knowledge is a fluid mix of framed experience, values, contextual information, and expert insight that provides a framework for evaluating and incorporating new experiences and information. It originates and is applied in the minds of knowers. In organizations, it often becomes embedded not only in documents or repositories but also in organizational routines, processes, practices, and norms.”

 

However, in using this as a working definition, it must be kept in mind that knowledge is of consequence only when it emerges, manifests, and also transforms itself through action. Therefore, the focus should equally be on knowledgeable practice, as much as it is on knowledge itself.

 

2.2 Software Requirements

 

There is an increasing awareness of the contextual and social nature of the process of requirements analysis in contemporary software engineering and information systems literature (see for example, (Goguen 1994; Checkland and Scholes 1999; Nuseibeh and Easterbrook 2000). Some of these studies also address the incomplete and evolving nature of this throughout the development process, and recognize that a significant portion of requirements and domain knowledge would remain unarticulated by the stakeholders of the system due to its tacit nature (Sawyer and Kotonya 1999). However, consideration of the social dimension underlying the requirements stops at the point where they are obtained from the stakeholders. The rest of the process, relating to the understanding evolved by the development team constructing the software, is considered unproblematic in these studies.

 

A different viewpoint on this is presented in (Walz, Elam et al. 1993). In their study, they found that development teams kept communication channels open with the stakeholders of the system, in order to obtain some of the initially unarticulated information. However when they did get new domain knowledge they also found it difficult to integrate into their current understanding of how a system would work, often losing information that did not match their existing working models of the task. These problems in understanding requirements are exacerbated by the tendency for users and developers to have different ways of talking about and representing requirements (Al-Rawas and Easterbrook 1996). Such issues are claimed to have been addressed in newer software development methodologies based on agile development, where close communication and collaboration between customers and developers is seen as facilitating the sharing of tacit knowledge (Chau, Maurer et al. 2003).

 

Not only do requirements have to be obtained from customers, they have to be shared and communicated between members of development teams. A thin spread of domain knowledge within such teams was identified as a problem in large software projects by (Curtis, Krasner et al. 1988), who described how this was often concentrated within key individuals. This contrasts with the findings by (Crowston and Kammerer 1998) that large software projects depended on the integration of domain knowledge from a variety of people, and that successful projects utilized the requirements gathering process as a means of developing shared understandings and carrying out collective sense making. This depended strongly on processes of socialization and conversation between the various actors involved in the project. The use of informal mechanisms such as interpersonal networks and peer discussions were also described by (Kraut and Streeter 1995), however the due to the excessive transaction costs of such personal contact, these had to be paralleled by formal mechanisms in order for projects to be run smoothly.

 

Offshore development brings about additional challenges to this. According to (Aman and Nicholson 2004), barriers such as culture differences, distance, and language inhibited knowledge transfer in offshore development projects, and were addressed by a variety of mechanisms such as phone calls, virtual meeting boards, “straddler” roles such as that of the onsite project manager, continuous mentoring of developers by managers, and using standardized information and documentation. The issue of the cultural gap between developers and stakeholders in cross-cultural software production environments was also highlighted by (Walsham 2002). Social networks between globally distributed groups tended to be weaker, thereby undermining collective identity formation and communication (Herbsleb, Mockus et al. 2000; Olson and Olson 2000). According to (Zowghi 2002), all these difficulties magnify existing problems in requirements elicitation, which are caused by a lack of customer-developer interaction and insufficient consideration of tacit knowledge.

 

3. Research Methodology

 

All professionals are knowledgeable in their work practices (Orlikowski 2002). Software developers are no exception to this, and the methods of working they follow would have arisen through a process of sensemaking within their context of work. Research aimed at understanding the practices of software professionals would also have to explore the subjective understandings and rationalizations they have within their workaday world. Therefore the epistemology underlying this research is strongly interpretive.

 

The data for this research was primarily gathered through unstructured interviews with staff members of the selected software development company. The first set of respondents was identified through a list provided by an initial contact at the senior management level within the company. Most people interviewed were helpful in nominating respondents, for the most part current or former team members. This made it possible to “dig” further down into certain projects and to corroborate facts between team members working on them. A total of 15 employees were interviewed. These respondents were engaged in project roles ranging from those of software and quality assurance engineers, to onsite business analysis (refer diagram X). The interviews were spread out over a period of almost four weeks commencing from mid-July as the intensive nature of work at the Company and the made it difficult to schedule them close together.  Several of these respondents were contacted for short follow up questions either in person or through the telephone, primarily for the purpose of expanding upon certain points they had made previously.

 

Interviews were not recorded, as it was felt that the presence of a recorder would induce reluctance on the part of respondents to provide details in their answers. This was due to two reasons. Firstly, the Company was very protective about details of the actual clients they worked for, as well as about their proprietary software process and practices. Secondly, the respondents themselves were often required to provide answers regarding their attitudes as well as their informal practices within projects, and having a recorder may have caused them to be less candid in their answers.  Written notes were taken during the process of the interviews, which were expanded into more detailed descriptions immediately after the interview. An attempt was made to ensure that statements made by the respondents that were interesting, in terms of the theories or concepts underlying this research, were noted down in verbatim.  However, in some cases a degree of paraphrasing may be present, and these will be distinguished by the conventions proposed by Silverman (1993, cited in (Schultze 2000)) – through the use of double quotes for verbatim speech and single quotes for paraphrased speech.

 

In addition to the interviews, documents used for requirements specification and clarification purposes were also examined in order to get an understanding of the content and form of the information conveyed through these means. A domain knowledge repository system used in one of the projects was also observed during this study.

4. The Context of the Study

 

The Company[1] is a software development firm based in the United States with multiple development centres located in India and Sri Lanka. The work undertaken by the Company is based on the development of customized software for independent clients. These clients come from a variety of industries and sectors including manufacturing, telecommunications, logistics, data analysis, printing, and retail sales. A number of these clients are themselves independent software vendors (ISV’s), who usually operate in a specific domain (such as mobile services or document management). Projects also exhibit a high diversity in terms of length (ranging from a few months, to ongoing production support and maintenance projects that have been running for over three years), and in size (from projects utilizing four or five people, to those requiring over a hundred).

 

Due to the wide variety of projects and clients, practices followed by development teams within Company tended to differ from project to project. However several recurrent patterns of work could be discerned through the answers obtained from the respondents who participated in the study.

 

The standard practice for offshore projects is to send a few team members in business analysis and high level technical roles onsite, where they engage in the initial requirements gathering. In situations where the client company is an ISV, or possess a degree of technical expertise, the initial requirements may be expressed by the client in the form of a structured requirements specification document using forms of description such as textual use cases, or even outlines of the user interfaces. When the customer is not as technical, the requirement may initially be expressed in a much simpler form – which may even be a single line (eg: “to re-engineer the existing system”). In situations such as these, the analysts would spend time onsite in discussions and brainstorming sessions with the client in order to derive use case and flow diagrams outlining the business processes behind the system as well as the required functionality, which were documented within the structured requirements specification.

 

This documentation was often the first formal introduction that development teams would receive about the requirements. Some clients also provided documents pertaining to their business, for example one client sent books and electronic content providing information about processes such as colour separation methods used within the printing industry in which they operated. In most cases telephone or video conferencing was used to hold meetings between the offshore teams, and onsite teams or clients. At this stage, the team consisted mainly of the more senior developers and project managers. The usual practice at these meetings was for the team to carry out presentations explaining their understanding of the system and its requirements to the client, from which a discussion ensued.

 

The work carried involved in the construction of a system by development teams actually consisted of two main streams, software engineering and quality assurance (QA)[2]. There was a strict separation between the responsibilities of staff members assigned for each role – the former carried out the design and programming tasks and the latter carried out high level testing and validation against the use cases. Representatives from the QA staff generally joined projects at a slightly earlier stage than engineers, and throughout the project there was little communication between both groups till actual testing had to be carried out. At this latter stage, both groups communicated primarily through formal mechanisms such as bug tracking software or through defect reports in a tabular format. These groups were also generally sited in physically distinct locations during the course of a project.

 

Many engineers joined projects some time after inception, after the initial requirements gathering and transmission activities had already been completed. For them, the initial workshops and presentations were held with project managers or senior technical team members, rather than with the client or the onsite team. Following this, questions that arose, which could not be handled by the immediate team, were escalated to onsite team members or to the customer through Question and Answer sheets (described later), email, and on a few occasions, through telephone calls to designated point people defined by the client. In projects where these point people were technically proficient (as in the case of ISV’s, or with IT staff working for the client company), the engineers themselves were more likely to engage in direct contact with them regarding requirements.

 

In projects there were usually a number of developers assigned at late implementation stages due to previous members leaving, or when it was felt that the existing team was not big enough. For most of these late joiners no workshops or meetings were carried out. They had to rely on questioning existing members, and studying the partially constructed system, after reading the existing documents and Q&A sheets.

 

A proprietary software development methodology was used within the Company. While this drew upon concepts from newer methodologies, a large proportion of the projects done within the Company were carried out with a waterfall model style emphasis on obtaining requirements at the start, and creating a reasonably complete high level design before commencing implementation. Once a specification had been drawn up to sufficient detail, time and cost estimation was carried out, and the project moved into the construction phase following customer approval of the estimates.

 

Getting the requirements correct was usually considered the customers responsibility. They were considered “fixed” after the customer approved the documentation at the inception of the project, and any major changes were treated as formal change requests and evaluated in terms of impact. Changes that had a low impact on existing functionality were generally accommodated, however if these had a significant impact on functionality, this would lead to another round of estimation which could result in changed deadlines and charges, or even a new development contract centred around the modified functionality.

 

5. Discussion of Findings

 

Based on the empirical data gathered at the company, several themes can be identified relevant to the knowledge based perspective adopted for this research. These are described within this chapter, with the pertinent theoretical discussions at the end of each section.

 

5.1 Knowledge Transfer – a Two Way Street

 

Most clients inherently “know” what they want in terms of the functionality and behaviour of a system. The majority of ISV clients of the Company also have long term experience operating within limited domains, in which they are knowledgeable about the needs of their own clients.  The main issue, especially with offshore development, is for development teams to acquire this same understanding.

 

The way in which the respondents within the Company described the process of clarifying information from the clients suggests that this occurs as a reciprocal exchange, rather than being a one-way process. When describing requirements during initial brainstorming sessions or through requirements documents, customers often focused on what analysts termed “the happy scenario”, the main flow of activities that defined a certain function or a business process. Once such requirements were documented (usually in the form of use cases, or flow diagrams) and sent to development teams, questions invariably arose with regard to “missing” bits of information that had to be handled through alternative methods.

 

One method that was cited frequently was the use of the Question and Answer (Q&A) document. This usually took the form of a table with each question on a new row, created using spreadsheet software. Members of the development team would enter questions regarding areas that they required further clarification on, and submit this document through email, or through a shared server, to the client who would usually provide answers and return it by the next day. Q&A’s were in use throughout the course of a project, as sometimes what had previously appeared to be straightforward requirements, were questioned when developers concentrated upon it in the process of coding, or in developing test cases. Sometimes questions which were “closed” (specified as satisfactorily answered by the team) could be reopened in the light of new problems that occurred at this later stage. For this reason old questions were always retained within Q&A sheet for future reference purposes. Q&A’s were resorted to quite often during the construction of the system, and hence these documents could grow quite large – in one project such a document referencing a single use case contained over 170 questions. While most respondents found Q&A documents very useful, there were some occasions on which they could not relate the answers given by the client to what they needed to know. One developer outlined a tactic he used for this purpose

 

“When you get into situations where a Q&A is not clear you go into a search in Google and find something that looks like it. Then you make a suggestion – ‘this solution is good for you, please advice’. If we jump in and ask (this question) they may say ‘no no, it’s like this’. You must ask them ‘is this the system you want’”

 

A similar method was used by the analysts during the earlier stages of the project. Following the description of business flows by customers, the analysts created HTML mock-ups of screens based on these and sent them back to the customer for verification. They often found that clients were much better at clarifying or changing the requirements when faced with the screens, as opposed to verifying it through the requirements specification itself.

 

A similar process of re-clarification also occurred between members of a project team, primarily at the interface between analysts and developers, as well as between old team members and new ones. Several respondents gave examples where newer team members brought up questions which forced existing team members to revisit existing documented requirements and to get back to the onsite team, or client, in order to clarify something the team had up till that point considered unproblematic. In larger projects it was not unusual for a question to cascade through several layers – from the developer to a module leader, to an onsite analyst, to the client himself – with the understanding each person had of the requirements being re-evaluated at each level. This often occurred in relation to exceptional cases, where the client’s expectation of what the system should do when an error occurred, or an illegal operation was executed, was either not adequately understood, or unconscious assumptions had been made by existing team members.

 

There were also two occasions cited by respondents, on developers helped suggest changes to the system that improved the system specified by the client. Both of these occurred with ISV clients, where the requirements were expressed at a more technical level.

 

What is apparent here is that clients don’t simply “tell” the developers and analysts what they need.  When initially writing a functional specification, or working with an analyst to derive a process based representation of their business activities, clients would be reflecting on the domain outside of its context. This can be best expressed in the words of Polanyi

 

“Analysis may bring subsidiary knowledge into focus and formulate it as a maxim or as a feature in a physiognomy, but such specification is in general not exhaustive.” (Polanyi, 1962 cited in (Tsoukas 2002))

 

In this manner, behind a clients expression of requirements, there would exist a body of taken for granted assumptions and expectations that would often be left out. The issue with ‘exceptional’ cases uncovered by new members indicates the fact that these are the easiest subsidiary particulars to be missed. This can be explained as a result of the clients focusing on the process or functional aspects of a system – which are based on the things happening in the “right” way – drawing attention away from the exception situations. The developers themselves realized that such information was missing when they themselves focused attention on the specific function or module in the context of development, and found that the subsidiary knowledge they had was inadequate for the task.

 

Offshore development does not afford an opportunity for direct contact, and developers do not get the chance to engage in any peripheral participation or observation in order to absorb this unarticulated knowledge. This lack of context contributes to issues of misinterpretation and ambiguity. In response, a plethora of organizational and individual tools are used during the course of a project to help draw the attention of the client towards the ancillary details left out of the initial description of the system requirements and domain. Q&A sheets, HTML screenshots, presentations by the development team, and “suggested” system proposed by the engineer are part of the vocabulary of a “conversation” that continues between clients and project team members, well into the construction phase of the actual system.

 

This conversation can also generate new insight, provided that developers can place the requirements expressed by clients into a context of personal experiences and skills. This is the case with the ISV clients, where the specification by the client is on a more technical level, closer to the world of practice of the engineers. Epistemic work here was achieved within the realm of practice, through the means of the continuous dialogue between developer and client.

5.2 Knowledge – Differences in Perspective and Mutation

 

All respondents agreed that domain knowledge was an essential aspect for their work. However, the extent to which they believed this was important varied. Respondents in analyst roles were quite strong in their belief that development teams had to understand the “big picture” behind the requirements. The viewpoint of the head of delivery was representative of this

 

“We have to ensure that the high level goal is understood before we move to the lower level. The more perspective we give the guys below the better. We lose out because we don’t describe the environment and developers can’t visualize it”

 

Analysts and senior management both attributed a large proportion of problems that occurred within projects to misunderstanding of the requirements. The Company, in fact, had previously carried out a research study which had concluded that the bulk of medium severity errors that were detected after the construction of software were due to this reason.

 

While this attitude was also shared among quality assurance staff as well as the more senior engineers, who themselves were often involved during the inception of the project in tasks related to requirements gathering and clarification, a fair number of less experienced engineers downplayed the importance of understanding the entire business domain. One engineer stated that business knowledge was not needed at his level of work. Another stated that having a single person with comprehensive domain knowledge within the team was enough, as it was important for getting requirements and clarifying things from the specification, but not required when you actually start developing the module.

 

On entering a project an engineer would make a personal assessment of how much of the domain he would “need to know” in order to complete his relevant modules. A couple of engineers described this process as follows:

 

‘When you jump in you look at technology, platforms, standards etc. first before anything else. And then look at how much domain knowledge you need to understand’.

 

‘To get into a system you look at the problem first, before looking into the background. You look at how other people working on it go about it, and decide from that how much you need to know’.

 

At the start of a project, engineers would read the portion of use cases that were relevant to the modules which they were assigned. During implementation it was also quite common for them to communicate with each other regarding their “part” of the system; however this was mainly with regard to determining the proper software interface between modules, rather than the business logic or processes behind them. One engineer stated that spending extra time reflecting on requirements outside of his immediate module was worth the effort, as it allowed him to better understand the implications that changes he made would have on the modules being developed by other people.

 

In addition to the degree of importance attributed to it, a semantic difference in the interpretation of the term “domain knowledge” was apparent between people in analyst and the engineering roles. The former tended to describe domain knowledge in terms of the business reasoning behind the system, as the knowledge required in order to understand the perspective of the client, mainly why he would want a given functionality or a feature. Most engineers on the other hand tended to describe domain knowledge in terms of a tool to make sense of a functional specification or a design document. As stated by one engineer

 

‘In (project name deleted) you had to know the domain, knowing the programming wasn’t enough. For example, words used in printing were also used in method names. The printing process is in steps. The program code has the same steps. I had to know printing logic to handle coding too.’

 

Engineers also stated that they preferred having a clear specification that minimized the amount of communication that had to be carried out with the customer. They perceived this as a delaying factor for the projects they were working in. Clients who were themselves not ISV’s, or from a technical background, were cited as creating more ambiguity with requirements, and hence more delays in the development process due to the need to contact them for purposes of clarification.

 

To understand this perspective adopted by the engineers, it is important to have an appreciation of the expectations placed on the developers by the implicit rules by which their teams worked. Since module ownership was individual, the onus was on the developer to ensure that he completed his module “correctly” and on time. The measure of correctness available for the engineer at the time of construction was through the architectural design and requirements specification documents provided.  However, the final test by which a module “passed” was through the tests carried out by QA staff, who were therefore expected to understand a system in its entirety. In smaller projects, and in some projects with where the client was an ISV, QA staff actually took over responsibility for business analysis activities. Further evidence of this difference between the outlooks of these two groups can be seen in the comments made by QA staff to the effect that software engineers often adopted a perspective based on a “system viewpoint”, as opposed to their own “business viewpoint” are indicative of this.

 

According to one analyst, there was also a complementary tendency on the part of project managers to avoid overloading developers with domain knowledge for fear of stressing them. However there were exceptions to this – developers who were interested in learning something “extra”, and willing to be proactive in finding out that information, were encouraged to do so by senior members of the team.

 

The knowledge of the requirements and the domain on the part of the engineers took a form that was different from that held by the analysts, QA staff, or the clients. This was not just a matter of the amount of knowledge – while it would be accurate to say that the engineers knew less of the domain as it was understood by the other groups, whatever knowledge they had was more oriented towards the task of developing their specific modules. For example a developer constructing a module for a mobile payment gateway would “need” to know how SMS differed among regions and countries, but not the business model by which such a payment facility operated in general. Knowing the domain is therefore something that is not independent of the activity carried out by the engineer.

 

Neither could it be separated from the social context in which they operated in. In effect, there was a division of labour between the two groups of engineering and QA staff, as well as in the breakdown of modules within the engineering teams which meant that, from the perspective of engineers, the knowledge of the general domain, or of system-wide requirements, was largely irrelevant for their tasks.

 

From these accounts we can see that the knowledge held by the engineers is intertwined with both the social context in which they operated, as well as with the object of their individual tasks. The documentation, informal descriptions, and answers provided by clients and the analysts, as well as the knowledge other developers had about the requirements of their own modules, were resources upon which they drew upon in a selective and situated manner, in order to achieve their work.  Knowledge here was enacted as knowledgeable and context-dependent practice, and not simply transferred. As stated by (Hislop 2002) “the sharing of knowledge involves two people actively inferring and constructing meaning from two different experiences”. However, there is an individual element also involved here, seen in the evidence of some developers willing to learn more than others.

 

From an organizational point of view there was a problem in this – as shown by the degree of errors attributed to inadequate understanding of the specification. The fact that engineers with more experience, which was usually combined with increased participation during the early requirement setting stages of projects, had a perspective closer to that of the analysts could be attributed to their tasks being at a higher, system-wide and architectural level, and hence requiring a broader and deeper appreciation of requirements and the domain. The object of their activity, and the rules by which they carried it out, were thus different, entailing a difference in their understanding as well.

 

5.3 The Importance of Tacit Understanding

 

The view expressed by most of the respondents pertaining to domain knowledge and software requirements corresponded to an objectivist view of knowledge. Several respondents provided the view that without codified knowledge such documentation, software development would simply not be possible, as the process of explaining things to developers would simply be chaotic. The prevailing view was “if you find out something, document it”. This was in part due to the importance that the Company gave to traceability of requirements – which was itself a consequence of the up-front contractual arrangements with clients. One developer put forward the case for recording conference calls and meetings held with the customer and onsite team, and using software tools in order to search and retrieve from this collection in order to prevent information obtained from such interaction from being missed out on.

 

A repository system specifically used for domain knowledge was used in one project in the Company, the one pertaining to the printing domain. The developers working on this project had established an archival website, on which the documents pertaining to the printing industry and processes, links to outside resources, as well as the technical specification documents were placed. This repository was used by developers as a reference whenever they had to look up any information on the printing process, and also as the introduction point for new developers joining the project at later stages. There was a unanimous view among the respondents who had been involved in the project, that this system was a major contributing factor to its success.

 

However, at the same time developers were aware of the extent that individual familiarity with the domain facilitated the communication of requirements. However sending an entire team onsite for the purpose of carrying out the face-to-face interaction best suited for this was infeasible. Instead, one technique adopted in some projects was to expose team members to similar businesses located with Sri Lanka. Team members on one project, which was about developing a loan originating system for a US bank, were sent on visits to local banks in order to learn the workings of a typical loan process. On another occasion, a representative for a client for whom the Company was developing a printing management system accompanied members of the development team on visits to local printing firms.

 

Another tactic used was to meet with other teams, within the Company, who were working on systems that addressed similar domains. One team working on a document management system held several meetings with another team who had been working on a similar system for a long-term client, during which they discussed the process of managing documents in general as well as the technical requirements for such a system. Two members of the team working on the printing management system visited a team based in India, who had worked on a project for the same client previously, and therefore had some familiarity with the domain.

 

Developers also reported that they spent time searching on the internet for information related to the industry they were working on, especially during the early phases of a project. This was generally done in their free time. One developer, who had been assigned to two projects simultaneously, stated that as a consequence he had not been able to “Google” on information about one of the projects, which made it much harder for him to read the specification.

 

Similarly, when working with domains with which individual familiarity could not be obtained, difficulties were often faced by teams trying to understand requirements. For example, one supermarket client required a system that tracked deals made with suppliers based on the placement of products within their stores. However, as no such practice existed within local supermarkets, there was some difficulty in explaining the requirements for this system to the offshore team. Developers also stated that projects which operated in areas typically unfamiliar to people with technical backgrounds, such as manufacturing and logistics, made it much more difficult to “grab the domain”.

 

The term “80/20” came up in several answers in relation to the amount of knowledge that teams felt they could obtain before moving into implementation of the system. As one respondent put it

“There are two types of knowledge, transferable, like how the business works, and the other types like what a customer expects the system should behave, and the look and feel of it. Usually you start with the first one of this, the 80%. The remaining 20% comes along the way”.

 

With the assistance of partial releases and prototypes released to the client, developers obtained feedback which helped them build up an understanding of what was expected in terms of the non-functional requirements. Such information was rarely documented, partly because of the difficulty of expressing it formally through written language, and partly because it was highly changeable. New team members, assigned to a project at a later stage, had to rely on existing team members to tell them “this is what the customer likes” when it came to tasks – for example when defining the appearance of a user interface element.

 

These accounts illustrate the recognition that developers had of the importance of developing a tacit understanding of the domain with which they had to work. “Knowledge runs on rails laid by practice” (Brown and Duguid 2001), but in the absence of this the developers had to follow alternative methods such as visiting local organizations, talking to other experienced  teams, and searching on the internet. These allow developers to engage with the object of the activity in an indirect, albeit less effectively than bodily interaction within the context of the client would have been.

 

Moreover, there was also recognition that there were also certain understandings could not be obtained outside of the actual activities surrounding the construction of the system. These could never be fully specified at the start of a project, and therefore this understanding had to be built up through a process of working with the client over a period of time. Interacting with the client, through the process of getting feedback for visible, partially complete systems, can be considered epistemic work, the activity of which affords knowing on the part of the developer. These cannot be acquired through documentation and the initial descriptions by the client, divorced from the realm of practice. Developers themselves, despite a strong stated belief in codifiable knowledge, also were keenly aware of the role that inarticulable knowledge played in their work.

6. Conclusion: Towards a knowledge based view of requirements within the offshore software development teams

 

The nature of requirements within the process of offshore software development, as discussed in the preceding section, differs from the treatment found in most of the rational and prescriptive literature on software methodologies and practice. The salient points from the study are summarized below:

 

1. Conveying knowledge on the domain and on requirements is a two-way process between the client and the development teams. The focus on functional and process related aspects at the start of a project may result in attention being lost on subsidiary details. A variety of tools are used on the part of developers in order to refocus the attention of the client on these, ranging from the more formal Q&A documents and screen mock-ups, to informal “suggestions” by the engineers. In addition to this, revision of understandings held by developers also happens through dialectical processes; conflicts arise in the knowledge held by existing team members through their engagement with the object of the activity – the system under construction – and also through exchanges with new members

 

2. Knowledge does not simply get “transferred” to the members of the development teams constructing the system from the clients or from the analysts. Software engineers are active agents, deciding what they need to know, based on their situated understanding of the task at hand, as well as the implicit rules of the context they work in. In this particular study, the division of labour between QA and engineering staff may have lead to a reduced emphasis on understanding the domain in “business” terms. Using (Venters, Cushman et al. 2003)s concept of “motile” knowledge we can characterize this as a mutation, rather than simply a case of partial transfer of the knowledge.

 

3. Developers also draw upon resources other than the client in developing an understanding about the domain. While previous personal familiarity has a role to play, developers also actively engage with the domain through less direct means. In the study some methods used were visits to local companies, meetings with other teams, and “Googling”. There are also some aspects of knowing what the client wants, which cannot be divorced from the practices of interacting and obtaining feedback from the client in relation to visible artefacts of the development process. Developers also believed in, and found useful, the concept and practices based on codified knowledge, but were pluralistic in their appreciation of the processes by which tacit understanding was established.

 

Under the knowledge based view, there is no simple “flow” of requirements to the developer. The requirements and domain knowledge they have is something that is continuously enacted, refined, and interpreted in the light of their practice and social context. The viewpoint they hold is similarly complex and multifaceted – there is no simple privileging of tacit or codified knowledge in their practice.

7. Limitations and Reflections

 

Two limitations of this study are due to the fact that it depends on the narratives of a limited group of practitioners in order to reconstruct the practices followed on projects within the Company. First of all, these accounts may reflect circumstances that are specific to the projects they have worked on, rather than being indicative of how work was carried out in general. Secondly, despite the assurances provided about anonymity, certain practices or details could still have been withheld by the respondents.

 

Keeping the discussion focused on the issues that were of interest to me – mainly on the actual practice the respondents – was often challenging in the context of an unstructured interview. Several participants took the opportunity to describe their opinion on the limitations in the methodology followed by projects in the company. In hindsight I felt that this was partly due to the way I expressed my research topic at the start of the interview, which may have implied I was interested in how effectively requirements were addressed in the software development process, and partly because the respondents enjoyed the opportunity to provide a strongly felt opinion to an informed, and interested, audience.

 

During the course of this literature survey, the author came across the theoretical approach of Activity Theory, which “offers particular promise” to unify the concepts of “knowing” and “doing” in relation to knowledge work (Blackler 1995). Activity theory draws attention not just to the activity of the subject itself, but also to the praxis within which its members make sense of their actions. A further strength of this theory in relation to the study of knowledge work is due to the psychological theory of Vygotsky that underlies it. According to this consciousness and knowledge flows from the level of the social to that of the individual, shaping him through the process of internalization (Spender 1996) . This provides a means of linking the social and individual forms of knowledge in a non dualistic fashion.

 

Despite its potential as a useful theoretical framework for use within this research, it was later decided not to utilize a complete Activity Theory framework for this. Most Activity Theoretical research accounts are “thick” and based on observation of the daily practice of individuals in addition to extensive interviewing. This also requires the researcher to address the historical development of work activities, as such practices are themselves transformed as a result of ongoing individual action (Bannon 1997). Given the limited time available for this research, and the difficulty in using ethnographic methods in the study context, it was felt that it would be hard to do justice to this perspective within this dissertation.

 

However, despite not using this as a theoretical framework, this study draws upon certain central concepts of activity theory during the analysis of the findings. In particular, emphasis was given to aspects such as the mediating role of tools (physical as well as symbolic – for example language and culture) between the individual and the object of the activity (Kaptelinin and Nardi 1997), as well as the role of social rules and expectations in shaping this interaction.

 

An interesting ancillary finding of this research was that the problems that emerged from different cultural expectations with regard to teamwork and power relations, highlighted in the literature of global software development (Walsham 2002; Aman and Nicholson 2004) appears to have little manifestation here. When questioned on the impact culture differences had in terms of understanding the problem domain and requirements, the main issue cited by most respondents was that of language and terminology used by the clients. This may be due to the fact that most developers rarely worked with clients closely enough for cultural expectations to be an issue. For the most part, contact was through email, as well as through documents such as the Q&A sheet and use cases. The use of richer modes of communication, such as videoconferencing, was limited due to the time difference between Sri Lanka and the United States. One analyst even cited the separation inherent in offshore development as an advantage, as it allowed development teams to be isolated from political issues such as competition with other projects, which often happened with in-house development within client sites.

 

A final reflection that. The findings of this research strongly support the validity of a practice-based, situated perspective of knowledge relating to the software development process. However, towards the latter stages of creating this report, I found myself questioning how much of this was due to my use of a practice-based, situated epistemology of knowledge!  Having settled on this at an early stage of my research, it would have had an influence on how I interpreted and obtained the interview and observational data from the site! (Latour 2004)s statement that “there is no in-formation, only trans-formation” in relation to research texts is an apt reminder that the subjective orientation of the researcher always colours the description and explanation he gives.

 

8. Further Research

 

A potential direction in which to take this research is deeper down, through the use of ethnographic methods to observe the practices of developers and analysts carrying out their everyday work. The time-frame of the study could also be increased, for example following selected projects from inception through to the actual implementation. The framework of activity theory, discussed earlier, would be much more applicable to such a research, potentially providing a much deeper insight into how knowledge of requirements is recreated throughout the software development process at the research site.

 

The company used for the case study in this research operated on the basis of client projects. However offshore development comes in many other forms, for example some companies are based around the development and release of commercial software products; others work with clients within a restricted domain, and others may function as dedicated, and more or less permanent, development divisions of foreign businesses. It may be interesting to replicate this research in offshore companies that works according to a different business model, thereby having a different relationship with the client and the problem domain which it addresses.

 

A different interpretation of knowledge could also be used for this study. For example, instead of being biased towards a relatively harmonious view of practice, the study could have addressed issues of power related to the contested nature of knowledge (Blackler 1995). Potential conflicts exist in the definition of system requirements, not just between clients and development teams, but also between the different groupings – analysts, quality assurance engineers, and software engineers – that exist within the teams themselves.

 

 

 

 

Alavi, M. and D. E. Leidner (2001). “REVIEW: KNOWLEDGE MANAGEMENT AND KNOWLEDGE MANAGEMENT SYSTEMS: CONCEPTUAL FOUNDATIONS AND RESEARCH ISSUES.” MIS Quarterly 25(1): p107, 26p.

Al-Rawas, A. and S. Easterbrook (1996). Communications Problems in Requirements Engineering. First Westminster Conference on Professional Awareness in Software Engineering, London.

Aman, A. and B. Nicholson (2004). Managing Knowledge Transfer Process in Offshore Software Development: Overcoming the Complexity of Tacit Knowledge. WORKSHOP INFORMATION, KNOWLEDGE AND MANAGEMENT, Bologna.

Bannon, L. (1997). Activity Theory. http://www-sv.cict.fr/cotcos/pjs/TheoreticalApproaches/Actvity/ActivitypaperBannon.htm. 23rd August 2005.

Bell, T. E. and T. A. Thayer (1976). Software requirements: Are they really a problem? 2nd international conference on Software engineering, San Francisco, California, United States.

Blackler, F. (1995). “Knowledge, Knowledge Work and Organizations: An Overview and Interpretation.” Organization Studies 16(6): 1020-1047.

Brown, J. S. and P. Duguid (1991). “Organizational Learning and Communities of Practice : Toward a unified view of working, learning and innovation.” Organization Science 2: 40-57.

Brown, J. S. and P. Duguid (1998). “Organizing Knowledge.” California Management Review 40(3): 90-111.

Brown, J. S. and P. Duguid (2001). “Knowledge and Organization: A Social-Practice Perspective.” Organization Science 12(2): 198-213.

Chau, T., F. Maurer, et al. (2003). Knowledge sharing: agile methods vs. Tayloristic methods. Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises.

Checkland, P. and J. Scholes (1999). Soft Systems Methodology in Action. Chichester, John Wiley & Sons.

Choo, C. W. (2000). “Working With Knowledge: How Information Professionals Help Organizations Manage What They Know.” Library Management 21(8).

Ciborra, C. (2000). Drifting: from control to drift. Planet Internet. C. S. B. D. K. Braa: 185-195.

Cook, S. D. N. and J. S. Brown (1999). “Bridging Epistemologies: The Generative Dance Between Organizational Knowledge and Organizational Knowing.” Organization Science 10(4): 381-400.

Crowston, K. and E. E. Kammerer (1998). “Coordination and collective mind in software requirements development.” IBM Systems Journal 37(2).

Curtis, B., H. Krasner, et al. (1988). “A Field Study of the Software Design Process for Large Systems.” Commun. ACM 31(11): 1268-1287.

Davenport, T. H. and L. Prusak (1997). Working Knowledge: How Organizations Manage What They Know. Boston, MA, Harvard Business School Press.

Desouza, K. (2003). “Barriers to Effective Use of Knowledge Management Systems in Software Engineering.” Communications of the ACM 46(1): 99-101.

Dingsoeyr, T. and R. Conradi (2002). “A Survey of Case Studies of the Use of Knowledge Management in Software Engineering.” International Journal of Software Engineering and Knowledge Engineering 12(4): 391-414.

Empson, L. (2001). “Introduction: Knowledge Management in Professional Service Firms.” Human Relations 54(7): 811-817.

Faraj, S. and L. Sproull (2000). “Coordinating Expertise in Software Development Teams.” Management Science 46(12): 1554-1568.

Goguen, J. A. (1994). Requirements engineering as the reconciliation of social and technical issues. Requirements engineering: social and technical issues. San Diego, CA, USA, Academic Press Professional, Inc: 165-199.

Hansen, M. T., N. Nohria, et al. (1999). “What’s Your Strategy for Managing Knowledge.” Harvard Business Review 77(2).

Hedlund, G. (1994). “A Model of Knowledge Management and the N-form Corporation.” Strategic Management Journal 15(Summer Special Issue): 73-90.

Herbsleb, J., A. Mockus, et al. (2000). An Empirical Study of Global Software Development : Distance and Speed. International Conference on Software Engineering, Toronto, Canada.

Hislop, D. (2002). “Mission impossible? Communicating and sharing knowledge via information technology.” Journal of Information Technology 17(3): 165-177.

Huang, K. T. (1997). “Capitalizing Collective Knowledge for Winning, Execution and Teamwork.” Journal of Knowledge Management 1(2): 149-156.

Iivari, J., R. Hirschheim, et al. (2001). Towards More Professional Information Systems Development: ISD as Knowledge Work. Global Co-Operation in the New Millennium, The 9th European Conference on Information Systems, Bled, Slovenia.

Johannessen, J.-A., J. Olaisen, et al. (2001). “Mismanagement of tacit knowledge: the importance of tacit knowledge, the danger of information technology, and what to do about it.” International Journal of Information Management 21(1): 3-20.

Kaptelinin, V. and B. A. Nardi (1997). Activity Theory: Basic Concepts and Applications. http://www.acm.org/sigchi/chi97/proceedings/tutorial/bn.htm. 23rd August 2005.

Kraut, R. E. and L. A. Streeter (1995). “Coordination in Software Development.” Commun. ACM 38(3): 69-81.

Latour, M. (2004). A Dialog on Actor Network Theory. The Social Study of Information and Communication Technology. C. Avgerou, C. Ciborra and F. Land, Oxford University Press: 62-76.

McDermott, R. (1999). “How Information Technology Inspired, But Cannot Deliver Knowledge Management.” California Management Review 41(4).

Nonaka, I. (1994). “A Dynamic Theory of Organizational Knowledge Creation.” Organization Science 5(1): p14, 24p.

Nuseibeh, B. and S. Easterbrook (2000). Requirements Engineering: A Roadmap. The Future of Software Engineering. A. Finkelstein, ACM Press.

Olson, G. M. and J. S. Olson (2000). “Distance Matters.” Human Computer Interaction 15: 139-178.

Orlikowski, W. J. (2002). “Knowing in Practice: Enacting a Collective Capability in Distributed Organizing.” Organization Science 13(3): 249-273.

Robillard, P. N. (1999). “The Role of Knowledge in Software Development.” Commun. ACM 42(1): 87-92.

Romaldi, V. (2002). Collaborative Technologies for Knowledge Management: Making the Tacit Explicit? Joint Proceedings Informing Science & IT Education and InSITE—Where Parallels Intersect, Computer Science Department, University College, Cork, Ireland.

Rus, I., M. Lindwall, et al. (2002). “Knowledge Management in Software Engineering.” IEEE Software 19(3).

Sawyer, P. and G. Kotonya (1999). SWEBOOK : Software Requirements Knowledge Area Description, Informe Tecnico Version 0.5, SWEBOOK Project.

Schon, D. A. (1983). The Reflective Practitioner : How Professionals Think in Action. New York, Basic Books.

Schultze, U. (2000). “A Confessional Account of an Ethnography About Knowledge Work.” MIS Quarterly 24(1): 3-41.

Schultze, U. and D. E. Leidner (2002). “Studying Knowledge Management in Information Systems Research : Discourses and Theoretical Assumptions.” MIS Quarterly 26(3): 213-242.

Sorensen, C. and M. Kakihara (2002). Knowledge Discourses and Interaction Technology. Thirty-Fifth Hawaii

International Conference on System Sciences (HICSS-35), Big Island Hawaii.

Spender, J. C. (1996). “Organizational knowledge, learning and memory: three concepts in search of a theory.” Journal of Organizational Change Management 7(5): 63-78.

Spender, J. C. (1998). “Pluralist Epistemology and the Knowledge-Based Theory of the Firm.” Organization 5(2): 233-256.

Swan, J., S. Newell, et al. (1999). “Knowledge management and innovation: networks and networking.” Journal of Knowledge Management 3(4).

Tsoukas, H. (1996). “The Firm as a Distributed Knowledge System: A Constructionist Approach.” Strategic Management Journal 17(Special Issue : Knowledge and the Firm): 11-25.

Tsoukas, H. (2002). Do We Really Understand Tacit Knowledge. Knowledge Economy and Society Seminar, LSE Department of Information Systems.

Venters, W., M. Cushman, et al. (2003). Motility of Practiced Knowledge: An exploration within the UK Construction Industry. The Fourth European Conference on Organizational Knowledge, Learning and Capabilities,, Barcelona.

Walsham, G. (2002). “Cross-Cultural Software Production and Use: A Structurational Analysis.” MIS Quarterly 26(4): p359, 22p.

Walz, D. B., J. J. Elam, et al. (1993). “Inside a Software Design Team : Knowledge Aquisition, Sharing, and Integration.” Commun. ACM 36(10): 63-77.

Waterson, P. E., C. W. Clegg, et al. (1997). ” The dynamics of work organization, knowledge and technology during software development.” International Journal of Human-Computer Studies 46(1): 79-101.

Wegner, E. and W. Snyder (2000). “Communities of Practice: The Organizational Frontier.” Harvard Business Review 78(1): 139-145.

Zowghi, D. (2002). Does Global Software Development Need a Different Requirements Engineering Process? Proceedings of International Workshop on Global Software Development – ICSE 2002, Orlando, Florida, USA.

 

 

Diagram X

 

Interview Respondents

 

Role	Number of Respondents
Software development, technical design	8
Testing and quality assurance	2
Analysis of customer requirements, liaison between customer and offshore teams	4
Supervision of overall customer development projects for Sri Lanka	1

 

 

Appendix X

 

 

Deetz’s four discourses of Organizational Inquiry – Adopted from (Schultze and Leidner 2002)

CAN ENTIRE COMMUNITIES BE BLINKERED ?

[1] Names of clients, employees, and details relating to proprietary methodologies and practices have been omitted from this dissertation in order to respect the privacy concerns of the Company and the interview respondents.

[2] Throughout this report, the terms “developer” and “development team” will be used to refer to both QA and software engineering staff. When the distinction has to be drawn between them, they will be referred to as “QA staff” or “engineers” respectively