Knowledge Acquisition in Information System Development: a case study of system developers in an international bank.

Lecturer in


Introduction
Information systems continue to be a source of competitive advantage (Chaffey and White, 2010;Chen and Tsou, 2007;Zhang and Lado, 2001) yet their development has long been known to be problematic. Information system development (ISD) is often a highly complex and time-consuming task and the literature portrays a rather uncertain picture of its management, and whether Information System Development Methodologies (ISDMs) do in fact contribute to project success (Grant and Ngwenyama, 2003). Initially plagued by the lack of formalised methods (Avison and Fitzgerald, 2003), the profusion of highly structured approaches has still not prevented development projects from ending in failure (Standish Group, 2010;Siau and Tan, 2005;Yeo, 2002;Winklhofer, 2002).
In addition to this, the lack of flexibility afforded by some approaches as well as combinations of budget and schedule overruns, failure to meet user requirements and the influence of other organisational changes can all have deleterious effect upon the planned development (Siau and Tan, 2005;Yeo, 2002;Winklhofer, 2002). The social and human aspects of ISD have seen a growth in interest, including the information behaviour of system users (Fidel and Pejtersen, 2004), ISD leadership (Faraj and Sambamurthy, 2006), the effect of reward systems on project success (Mahaney and Lederer, 2006;Walsh and Schneider, 2002) and the conceptualisation of participant engagement (Mattia and Weistroffer, 2008). However, even the recent development of 'agile' methodologies has failed to reconcile the paradoxical requirements of flexibility and standardisation (Galal-Edeen, Riad and Seyam, 2007;Ferneley and Bell, 2005) and ISD research continues to focus upon methodological analysis, selection and development (Liviu, 2014).

Projects and Knowledge Management
Mainstream project management has long recognised the importance of, and techniques for, managing budgets, project timing, project planning and change management and possesses an extensive and growing body of knowledge: for example, project manager's culture and style of conflict management (Mohammed, White and Prabhakar, 2008), female project manager's leadership and managerial behaviour (Neuhauser, 1997), leadership style and innovation in construction projects (Bossink, 2004), project management style and new product development success (Thieme, Song and Shin, 2003) and the skills of effective project managers (El-Sabaa, 2001). The importance of managing knowledge within the project management environment has also been widely recognised (Akhavan and Zahedi, 2014;Gasik, 2011). Lundmark and Klofsten (2014) for instance, examine the ways in which project managers attempt to acquire knowledge and the resultant benefits upon project creativity, while Todorovic et al (2014) conclude that performance metrics may be used to effectively drive knowledge acquisition and Whyte and Minnaar (2014) investigate the knowledge requirements of new project members, recognising that those knowledge requirements change over time.
The significance of effective knowledge management has also been acknowledged within the specialised context of ISD projects. Pee, Kankanhalli and Kim (2010) along with Karlsen, Hagman and Pedersen (2011) emphasise the critical importance of knowledge sharing within and between IS projects. Reich (2007) identifies the aspects of information technology projects that are dependent upon developer knowledge while Siva (2012) acknowledges the barriers to successful knowledge management in distributed system development projects. System developers themselves are seen as key to effective project management since their individual knowledge is an antecedent of team performance (Lee, Park and Lee, 2014;Tesch, Sobol, Klein and Jiang, 2009;Patnayakuni, Rai and Tiwana, 2007;Tiwana and Mclean, 2005). System users have also been identified as important contributors of valuable knowledge during system development initiatives (Hsu, Lin, Zheng and Hung, 2012). Despite this realisation, Rosenkranz, Vranesic and Holten (2014) note that the process of knowledge production in ISD needs greater understanding.
What has received minimal attention to date is the development of the developer, specifically, how their knowledge of the process of systems development influences, and is influenced by, the act of developing information systems. While the importance of developer knowledge is recognised, and approaches to improving knowledge transfer and acquisition have been proffered, the rapidity with which developer's knowledge matures is not known. This is a significant question to pose since the results may have implications for knowledge management and ISD strategies within organisations. For instance, if developer knowledge is only acquired over relatively long periods of time then initiatives to foster and utilise new knowledge among developers must acknowledge that results are unlikely to be realised in the short-term.
This study has introduced the importance of innovative ISD, its origins and evolution, and the significance of system developers in the process. The next section explores the literature that highlights the importance of the developer in the process of system development and how their knowledge determines the selection and use of structured approaches. Recognising the difficulties in defining the term knowledge, the study arrives at a concept of knowledge that avoids epistemological paradox and allows its acquisition to be empirically evidenced.
An exploration is made of the acquisition of knowledge of a group of system developers engaged in two consecutive phases of ISD project in an international bank in France. Evidence is gathered through observational research, instantaneously sampled field notes, content analysis of electronically stored project documentation and semi-structured interviews, over a period of one year.
The data analysis and discussion sections are structured according to the research purpose, discussing, in turn, how the developers' knowledge shapes the choice of structured approach, how the choice of structured approach shapes the developers' practice and finally, how the developers' experience shape their adaptation of the structured approach. Fitzgerald (1996) describes the inadequate recognition of the personal preferences, experiences and characteristics of developers in systems development. Structured approaches do not cater for human factors such as learning and creative thinking that can be instrumental in delivering successful projects. Brooks (1987) states that systems development is a creative process, that schemes should be put into place to nourish creative people and that it is important not to lose sight of the fact that it is people and not the chosen approach that actually develop systems. Davis and Olsen (1985) concur that developers gain knowledge with experience and that this is a vital factor in successful systems development. Vitalari and Dickson (1983) also emphasise the importance of learning over time, concluding that developers acquire a range of strategies to apply in different systems development projects.

Structured Approaches & Developer Knowledge
Developer experience can be seen to be an issue that significantly affects the adoption and use of structured approaches. Lee and Kim (1992) and Kozar (1989) suggest that inexperienced developers are more likely to follow a structured approach rigorously whereas Leonard-Barton (1987) noted that experienced developers are more likely to use them. Fitzgerald's (1997) study explores the relationship between developer experience and adoption of a structured approach (Figure 1).
[Insert Figure 1 Here] Fitzgerald (1997) finds that training and education determines system developers' likelihood to utilise a structured approach. Developers with little or no prior experience may find the formal structure attractive. As they gain experience of using a particular approach then they are likely to gain knowledge of its limitations and drawbacks whereupon they abandon its rigid prescription. Later, as knowledge and skills are further enhanced, they are able to adopt and adapt a given approach to suit their particular personal and situational requirements.
Exploring the knowledge dimension of information system development A universal definition of knowledge is probably elusive (Fernie, Green, Weller and Newcombe, 2003), therefore, in order to conceptualise developer knowledge it is necessary to understand the various forms that knowledge may take. The terms tacit and explicit knowledge depict a fundamental characteristic of knowledge that has found almost universal acceptance in modern study. Knowledge is broadly distinguished as that which is explicit, or easily transferred or observed in the form of speech, text, graphs and signals, or that which is tacit, or often difficult to articulate or disseminate, resides within the individual and is highly personal, created and reaffirmed by our unique values, beliefs and experiences (Cook and Brown, 1999). Clark and Geppert (2002) classify these conflicting streams of knowledge management research that from one perspective consider knowledge to be a commodifiable and transferable resource, but alternatively recognise the complexity of knowledge transfer and its social and situational dependence. These polarized notions of knowledge have lead to much debate, and even to challenges to the term, and practice of, 'knowledge management' (Bouthillier and Shearer, 2002;Hildreth and Kimble, 2002;Wilson, 2002). Cook and Brown (1999) explore the multi-faceted nature of knowledge, noting the many different perspectives and definitions that can be further divided along the dimensions of subjectivity-objectivity and individual-group. In attempting to move away from further classifications of knowledge that contrive to expand the divides along those dimensions, much of the literature unites them through understanding that work that is performed by individuals involves both knowledge and action (Karlsson and Wistrand, 2006;Osterlund and Carlile, 2005;Bedny, Karwowski and Bedny, 2001;Bedny, Seglin and Meister, 2000;Alavi and Leidner, 1999;Miller and Morris, 1999;Leonard and Sensiper, 1998;Mukherjee, Lapre and van Wassenhove, 1998;Nonaka, 1994;Lave and Wenger, 1991). Such 'knowing as action' is said to "bridge the epistemologies" (Cook and Brown, 1999, p383) of the polarized dimensions.
It has been postulated that disparity in structured approaches to systems development has made the acquisition of actionable knowledge problematic (Loucopoulos and Layzell, 1989). Although the type of activity or method has been found to be less important than the working environment in determining the extent of knowledge generation and learning (Choo, Linderman and Schroeder, 2007) the choice of structured approach is likely to have a profound effect on the knowledge that project participants gain, both of the approach itself and of the organisation and its information system. Furthermore, the literature suggests that this knowledge will be developed experientially as well as experimentally and refined over time (Sennet, 2008;Alonderiene, Pundziene and Krisciunas, 2006;Cavaleri, Seivert and Lee, 2005;Oyeleran-Oyeyinka, 2004;Miller and Morris, 1999;Pfeffer and Sutton, 1999;Leonard and Sensiper, 1998). Interestingly however, there is no suggestion how long such developments may take other than inferences to knowledge acquisition taking place over 'extended periods of time' (Engestrom, 2000;Blackler, 1995). Selection of an appropriate approach is therefore not only a question of technical suitability from the perspective of system design, but also one of complementarities with an organisation's knowledge strategy.
Through conceptualising develop knowledge as that which is actionable, or which can be observed in the form of work, the problem of attempting to access or assess the knowledge of individuals is overcome. ISDs work may be either their contribution to designing and coding information systems, or their efforts to adopt and adapt their approach toward system development itself. Using Fitzgerald's (1997) study ( Figure   1), a trendline can therefore be applied to represent the acquisition of knowledge by developers that is used to modify the approach that they take toward system development ( Figure 2).

Research Purpose
This study is made upon the activities that system developers undertake. These activities form the locus for the acquisition of knowledge, and are observed in the form of modifications that they make to their approach to system development. By studying developers' knowledge acquisition, this study furthers the understanding of ISD that has hitherto largely focussed upon the study of the structure, benefits and difficulties of approaches to system development. Based upon a case study of a department of an international banking organisation in France it explores, 1.
The rapidity with which developers acquire knowledge in order to modify their approach toward system development.

2.
How developer knowledge shapes the choice of structured approach (Adoption)

3.
How the structured approach shapes developers' practice (Abandonment)

4.
How the developers' experience shapes the structured approach (Adaptation)

Methodology
The work is exploratory in nature and so a case study approach is adopted for its usefulness in uncovering 'why?' and 'how?' phenomena occur (Yin, 2003). Case study is defined by Yin (1994, p. 13) as "an empirical enquiry that investigates a contemporary phenomenon within its real-life context, especially when the boundaries between phenomenon and context are not clearly evident and relies on multiple sources of evidence". It is especially suitable for studying phenomena in highly complicated contexts (Stuart, McCutcheon, Handfield, McLachlin and Samson, 2002). Case selection often plays an influential role since the selected case(s) will have to provide valid information to support the theory building and explanation.
Some academics declare the use of multiple cases is likely to create more robust and testable theory than single case research since multiple cases improve reliability and validity (Yin, 1994;Eisenhardt, and Graebner, 2007;Barratt, Choi and Li, 2011). Voss, Tsikriktsis and Frohlich (2002) however maintain that fewer numbers of cases affords the opportunity to engage in deeper investigation. Dyer and Wilkins (1991) suggested that single case studies enable the researchers to understand the phenomena under investigation in much greater detail.

The Project
The development project consisted of three separate phases and employed a team of three system developers. Phase 1 involved the development of the organisation's internal information systems, those that were used solely by the employees and supported the day-to-day functioning of the business. Phase 2 involved the development of those external information systems that interfaced with customers and other corporate stakeholders. A future system development initiative, Phase 3, is mentioned during the investigation but did not form part of this study. The examination of Phases 1 and 2 took place over a period of one year.

Data Collection Methods
Three different approaches were used to capture the detail of the case consisting of participative observation, content analysis of project documentation and semistructured interviews. Through using this methodological triangulation (Jick, 1979) the study can claim a degree of validity and recoverability (Checkland and Holwell, 1998).
Action research was carried out whereby the researcher acted as a participative observer (Gans, 1999;Vinten, 1994;Bositis, 1988;Pohland, 1972). The principal researcher undertook 40 hours of first hand observation during Phases 1 and 2 of the project. Records were made of instances where the system developers discussed or took action about the development methodology that was employed. Any other actions or issues arising over the course of the project were instantaneously sampled and recorded in field notes (Paolisso and Hames, 2010).
Continuous observation of the system developers was not practicable therefore observational analysis was substantiated with content analysis of the project documentation. All project documentation was held electronically on the organisation's intranet permitting rapid retrieval and reducing the risk of omitting documents from the investigation. This information was compiled and contributed to the field notes.
Observational analysis and content analysis adopted the group of system developers as the unit of analysis. In order to gain deeper understanding of individual developer's approach toward the system development methodology being employed, semistructured interviews were conducted with each developer. The interviews were based upon a questionnaire that was developed from the themes identified within the literature. These explored the individual's perception of the type of system development methodology employed, the effectiveness of the approach along with the need and efforts to modify the approach. This approach allowed the interviewer to modify questions and to follow emergent themes or issues raised by the interviewee (Bryman, 2008). The interview questions were developed cyclically to improve the validity and reliability of the participant observation method (Becker, 1958;Halcomb and Davidson, 2006;Miles, 1979). Following preliminary analysis of preceding interview data, subsequent interview questions were refined and introduced to gain deeper understanding of salient issues and to following interesting and emerging themes. Each interview lasted approximately two hours, they were recorded using a Dictaphone and transcribed by the interviewer in order to reduce the risk of incorrectly interpreting responses (Opdenakker, 2006).

Data Analysis Methods
The primary investigator thematically coded the interview transcripts according to the themes identified in the literature review (Boyatzis, 1998

Choice of Structured Approach
A document was retrieved from the company's intranet that details the methodologies to be used for IT development projects: It is Group policy that all IT projects of any magnitude (greater than 10 man/months effort) must use an approved project development methodology to provide an orderly framework within which project progress can be monitored and project risks controlled. The Group has approved two industry-standard project development methodologies for use under different circumstances as may be appropriate. These

are: The Rational Unified Process (RUPs) -5% of projects; The [Traditional] System Development Life Cycle (TSDLC) -95% of projects.
Despite corporate policy stipulating the structured approach to be employed, according to the interviews carried out with project participants, no methodology was used to facilitate the development of Phase 1. However, the documentary evidence for the system migration initially contradicted these findings. The documentation found on the company intranet indicates that the TSDLC methodology was followed.
Firstly, the Terms Of Reference (TOR) for the project was retrieved which outlined aspects such as the project objectives, goals and benefits, and even stated "...This project will follow a standard waterfall model...". The dates that the project documents were produced were checked and were found to have been written at the prescribed points in the TSDLC. Despite the correct timing of the production of documentation a minimum of output was actually generated: only the TOR and a small number of technical documents were found. This, coupled with the statements from interviewees, suggested that the TSDLC methodology was not adopted in such a way that it provided structure or guidance to the work being undertaken. In fact, the minimal documentation that was generated appeared to have been produced simply to indicate that the project was conforming with Group IT policy.
From the researcher's observations and analysis of the project documentation no projects were being undertaken or were planned using the RUP methodology. Prior to beginning work on Phases 1 and 2 none of the project participants had experience of the The documentation relating to Phase 2 confirmed that the TSDLC approach was being followed. The TOR and a significant number of technical documents relating to project content, problem solving and progression were in place on the company's intranet. One respondent commented on the way that development methodologies were used for smaller projects: "...We don't worry too much on smaller projects, we just do whatever is needed to make the changes..." The response shows that for smaller projects the methodology was not strictly adhered to. This is important since the Group's IT Policy specifically allows methodologies to be modified to suit projects of different scope and scale. Observation also showed that the methodology was not followed as rigorously in the smaller projects. The reasons for not following the methodology in these cases appeared to be at least partly due to the reduced number and complexity of user requirements. This gave the opportunity to move through each stage more quickly providing some of the requirements of the methodology were abandoned. Interviews also indicated that project participants were not as worried about following the methodology as rigorously on smaller projects. What is not clear is whether this was due to the lower impact and therefore lower risk involved with smaller projects, or was due to the project participants' continued lack of understanding of the importance of adopting and adapting a structured approach. Even though the need for a structured approach was identified after their experiences during Phase 1, and the benefits of using the TSDLC were clear through observation of progress with Phase 2, the interviewees experienced some problems with adhering to the process, "...There is a lot of paper work involved in the methodology though, and this is very painful for a small team..."

Developer experience
"...They take a lot of time to put together because of the amount of detail that is required. We have to be sure that we have been clear in the documents of what it is we require so that problems do not occur..." The quantity of information and level of detail that was required to complete the project documentation was thought highly demanding. This was evident in the proportion of documents that were left incomplete. It was thought that the documentation may have been compiled retrospectively, after project completion, and therefore much of the required information was no longer available. However, our previous analysis of the dates at which documents were compiled showed that documents were in fact initiated, though not completed, at the expected times in the development process. It later became apparent that by the time the relevant information had been captured in order for the documentation to be completed, the task had already been finished.
When asked about the importance of tailoring methodologies to suit circumstances after gaining experience of the TSDLC during Phase 2, the interviewees each identified several common improvements they would like to make,  Standardised documentation: At present each project manager develops their own.
 Fixed response deadlines: Response to technical queries often takes several weeks.
 Effect of changes: It is difficult to ascertain whether proposed changes will affect only local systems or will impact on the global business systems.

Discussion
The corporate policy document that specified which structured approaches to use, also outlined the purpose and phases of the TSDLC, and details the paperwork records that must be generated. It even suggests that the methodology can be adapted to suit projects of different magnitude. Recognising that structured approaches often need to be modified to suit circumstances is an encouraging sign. However, the TSDLC is known to be a particularly difficult development approach to adapt (Plyler and Young-Gul, 1993).
Stipulating the approach that must be adopted when developing information systems would potentially prevent the organisation from benefiting from the knowledge of its developers. By constraining their choice of approach they would be unable to draw upon their skills and experience to shape an approach that would perhaps be more appropriate, effective or practicable in a given situation (Lee, Park and Lee, 2014;Karlsen, Hagman and Pedersen, 2011;Pee, Kankanhalli and Kim, 2010;Tesch, Sobol, Klein and Jiang, 2009;Patnayakuni, Rai and Tiwana, 2007;Tiwana and Mclean, 2005). Undoubtedly, dictating the approach to be used has some advantages, such as ensuring commonality of approach, and standardising documentation, which could both be useful for ensuring conformance with audited quality standards such as ISO9000.
The observation that none of the developers had experience of TSDLC prior to this project is somewhat surprising given that it is arguably one of the most well known structured approaches (Thite and Sandhu, 2014). A lack of training and awareness of the importance of structure and accurate documentation etc, contributed to the project participants' viewpoint that much of the paperwork was an unnecessary activity.
This may go some way to explaining their reluctance to adopt the stipulated approach in the first place, which is in contrast with Fitzgerald's (1997) observations, and the resultant difficulties that they experienced. For example, lack of understanding of the terminology used in the documentation dissuaded them from attempting to complete some sections. This may well have coloured their perception of the effectiveness of TSDLC and of structured approaches in general, although they later recognised the benefits of adopting structured approaches and utilised them in later phases of the project.
As a consequence of their lack of familiarity with the TSDLC and the benefits that a structured approach may afford, the project participants were focused upon completing the work at hand rather than the approach to system development. In fact their approach was largely unstructured and documents were completed to satisfy the requirements of the organisation rather than to aid the process of system development.
After completing Phase 1 of the project they unanimously recognised the benefits that a structured approach affords. However, there did not appear to be a verbatim adoption of the prescribed development methodology, rather they immediately entered a phase of 'adaptation' (Figure 3).
[Insert Figure 3 Here] What was particularly interesting was the rapidity with which the developers moved between positions of adoption and adaptation. Fitzgerald (1997) does not indicate the pace at which developers alter their perceptions and practice of using structured approaches. In contrast, the knowledge management literature largely recognises that knowledge acquisition takes place over extended periods of time (Sennet, 2008;Alonderience, Pundziene and Krisciunas, 2006;Cavaleri, Seivert and Lee, 2005;Oyeleran-Oyeyinka, 2004;Engestrom, 2000;Miller and Morris, 1999;Pfeffer and Sutton, 1999;Leonard and Sensiper, 1998;Blackler, 1995). This study suggests that, at least in some cases, the performance of work can result in rapid acquisition of developer knowledge and the resultant changes in practice. It is therefore likely that the developers could rapidly moved toward the arguably more constructive 'adapted' phase if they receive further training in the use of SDLC or were guided by a more experienced developer.
In accord with much of the literature (Galal-Edeen, Riad and Seyam, 2007;Ferneley and Bell, 2005;Sauer and Lau, 1997;Chatzoglou and Macaulay, 1996;Chikofsky, 1989;Avison, Fitzgerald and Wood-Harper, 1988;Curtis, Krasner and Iscoe, 1988), the case study findings demonstrate that the pressure to achieve project deadlines had a significant influence upon the rigour in use of the structured methodology. On smaller projects in particular, with simpler objectives, the findings show that a methodology was not rigorously applied. The developers' experience of using the TSDLC also echoes the observations that structured approaches are often resourcehungry and time-consuming, especially in terms of the quantity of paperwork that is generated (De Grace and Stahl, 1990).
At the close of Phase 2 of the project the developers identified a number of ways in which they could improve their practice, based upon their experiences. The suggested improvements do not require changes to the fundamental configuration of the structured approach. Rather, they are improvements in the daily management of the project and suggest that there are lessons to be learned from the mainstream project management discipline. Standardisation of documentation and establishing timely communications for example, are desirable if not essential features of any project (Standish Group, 2010;Siau and Tan, 2005;Yeo, 2002;Winklhofer, 2002).
Furthermore, understanding the effect of system changes should be achieved by developing comprehensive system architecture maps and assessing the impact of those proposed changes during the systems analysis phase that is present in the majority of approaches to system development (Chaffey and White, 2010).

Conclusion
Previous research into ISD has largely focussed upon the structure, benefits and the difficulties encountered between different approaches to system development. Only relatively recently has attention turned to the human aspects of systems development.
This case study of an international bank has attempted to provide insight into the acquisition of knowledge by ISDs and its effect upon their use of structured system development methodologies. It adopts a concept of 'knowledge as action' that declares that knowledge is both necessary to perform work, and is generated through the performance of that work. Taking this position obviates the difficulties that are presented by attempting to identify or synthesise a universally acceptable definition of knowledge that does not result in epistemological railroading.
The study found that system developers quickly acquire knowledge of the benefits and limitations of system development approaches over consecutive phases of a larger project. The speed at which this acquisition of knowledge resulted in change in practice is much more rapid than the knowledge management literature generally infers. This knowledge enabled them to adopt, abandon or adapt the methodology according to the scope and scale of the project. The developers' suggestions for further adaptation of the structured approach require changes to the management and administration of the project but not to its fundamental composition.
The effectiveness of less mature development teams must be considered when information systems are being developed. This study has implications for practicing ISDs and for organisations that are undertaking information system developments.
System developers need to be aware of their own stage of maturity and that this may differ according to which formal methodology is being employed. Organisations need to be aware of the stages involved in the adoption and adaptation of development methodologies, in particular, the ramifications of changing or specifying methodologies that may subsequently influence the capacity for delivering system innovation.
The observations also concur with much of the literature, finding that development of information systems benefits from the adoption of a structured approach. The developers viewed it as valuable as an aid to communication, to improve consistency across projects, to clarify responsibilities, to facilitate decision-making, and to construct plans to ensure deadlines are met.
This study was based upon a single case study and therefore its results are not wholly generalisable. Methodological triangulation was employed to improve the reliability of the findings. The specific conditions under which the case organisation was observed are unlikely to be replicated exactly in other organisations. However, the insights that it provides into the rapidity of knowledge acquisition of system developers should be of value to organisations, practitioners and researchers.
To further test these findings, research should be undertaken in different contexts, and through examination of multiple sites attempt to identify whether these findings are consistent only within the banking sector or are prevalent across different areas of commerce.
The mainstream project management literature recognises the wider context in which projects exist. Factors such as leadership and management style, effective leadership skills and gender, could be areas in which ISD theory could be advanced and practice could be improved. ISD is a knowledge intensive activity. The choice of development methodology both shapes the experiences the subsequent knowledge and skills of developers and is, in turn, shaped by those developers' tendency to adopt and adapt those methodologies in the future. Future research should explore the relationship between developer experience and their adoption and adaptation of structured approaches. It should examine whether the decisions to adopt or adapt methodologies are most influenced by developer experience, the organisational environment, or the nature of the project at hand.