agile methods for off shore information systems ... - CiteSeerX

First Information Systems Workshop on Global Sourcing: Services, Knowledge and Innovation Val d'Isère, France 13-15 March 2007

JIT 06-198

AGILE METHODS FOR OFFSHORE INFORMATION SYSTEMS DEVELOPMENT Frank Harmsen1 E-mail: [email protected] Mischa van den Brand1 E-mail: [email protected] Jos van Hillegersberg2 Email: [email protected] *

Mehmet N. Aydin2, E-mail: [email protected] 1

Capgemini IT Sourcing Consulting and University of Utrecht Department of Organization and Information P.O. Box 2575, 3500 GN Utrecht, The Netherlands 2

University of Twente School of Management and Governance Department of Information Systems and Change Management P.O. Box 217, 7500 AE Enschede The Netherlands

*

Corresponding author

1


AGILE METHODS FOR OFFSHORE INFORMATION SYSTEMS DEVELOPMENT ABSTRACT This research is concerned with effectiveness of agile methods for off shore Information Systems Development (ISD). Recently, agile methods have been promoted as an alternative for conventional methods because they are flexible and adaptable to different project situations including off shore ISD projects. But, empirical evidence supporting appropriateness of agile methods to off shore ISD is scarce. In this study we have investigated a number of challenges faced in using agile methods in off shoring ISD. We examine the differences between on-site and off shore ISD as perceived by the practitioners. We further present what measures can be taken to mitigate the perceived risks and discuss to what extent agile methods are effective to deal with the perceived challenges occurred in off shore ISD.

Keywords: agile methods, outsourcing IT development, off shore systems development, global software development

INTRODUCTION Information systems development (ISD) methods are essential for structuring project participants’ thinking and actions and therefore can be an effective means to achieve successful projects. The benefits of effectively using systems development methods in a traditional, “on site” context are beyond doubt: they help to achieve quality, re-use best practices and keep projects “on track”. Agile methods tend to emphasize these characteristics, as they strongly focus on managing risk and time by applying prioritization of requirements, relatively short time cycles, time boxes and early

2


involvement of important stakeholders. Agile – denoting having a quick resourceful and adaptable character – Information Systems Development Methods, agile methods in short, have appeared as a solution to the long-standing problems related to conventional methods (Abrahamson, Warsta, Siponen, and Ronkainen, 2003). Recently, a number of studies, including (Schatz and Abdelshafi, 2005) have discussed benefits of agile methods in empirical setting. More and more, projects contain one or more “off shore” components, i.e. in global virtual teams spread across time, space and culture (Jarvenpaa and Leidner, 1999; Damian and Moitra, 2006; Lee et al., 2006). Several studies conclude, that there are issues regarding off shore systems development projects (Cramton, 2001; Chan and Chung, 2004) , notably costs of overhead, quality problems, cultural misfit and overruns (Kuni and Bhushan, 2006; Conchuir et al., 2006; Herbsleb et al., 2001). Given their focus on managing risk and time, agile methods might be an appropriate answer to these problems (Paasivaara and Lassenius, 2006). The research described in this paper investigates this assumption. We use a risk-based approach by analyzing the main differences between on site and off shore development and associate risks and mitigation measures to them. We investigate whether these measures are present in two popular agile methods and, if absent, suggest ways to incorporate them.

RESEARCH BACKGROUND Information systems development (ISD) is a change process taken with respect to object systems in a set of environments by a development group to achieve or maintain objectives (Welke, 1981). Such a process embodies people, development activities, artefacts, and methodical means and is configured based on working

3


principles and design options concerning aspects of IS development (the way of thinking, working, modeling, supporting and controlling (Seligmann et al., 1989). There are two particular domains in the IS research discipline, often called information systems development (ISD) research (see Iivari, Hirschheim, and Klein, 1999) and method engineering (see Harmsen, Brinkkemper and Oei, 1994) respectively that focus on specifically on the development of IS and possible ways and means (methods, tools and techniques) to support it. Among all the cited problems and issues hindering a better use of methods, it is argued by many scholars that methods have their own limited views on the reality of IS development and may often fall short in accommodating the uniqueness of a ISD project situation. This particular limitation of methods is usually referred as a “one-size-fits-all issue in the ISD literature (Truex, Baskerville, and Travis, 2000). As empirical evidence shows that method users in practice comment that conventional methods are monolithic, difficult to adapt, or modify for a project situation (Hiddink, 1997), scholars in the ISD research and method engineering literature address this one-size-fits- all issue from their own perspectives. Fitzgerald, Russo, and O’Kane (2000) have studied how an espoused method has been tailored and resulted in method-in-action in several projects on site. Recently, Aydin et al. (2005) have further examined how an agile method has been adapted on site ISD and distinguished two forms of adaptation: static and dynamic adaptation. The former refers that a method is adapted based on perceived and foreseen characteristics of project situation (such as formality, stability and complexity of business requirements, a degree of user participation, power structures of involved parties, etc) and the latter indicates that an agile method is adapted on-the-fly based on emerging characteristics of the project. Central to both types of adaptations is the idea of characterizing a

4


project situation (perceived ‘reality’ or state of affairs one holds in a given project context at a particular moment in the project) based on foreseen or emerging properties. It is this characterization process that leads to different ways of developing information systems. These ways are often codified as either method espoused or method-in-action. We presuppose that off shore IS development differs from on site development in terms of a number of salient characteristics. Then the focus of this paper is to understand how practitioners characterize offshore ISD in contrast with on site ISD. Thus, in this study we consider a number of practitioners as the main source of knowledge to identify perceived differences between on-site and off shore IST. While identifying salient characteristics of off shore ISD we examine how practitioners relate them to possible risks and their mitigation measures. This examination is based on the assumption that the salient characteristics are the sign of possible risks or opportunities that might occur.

Offshore outsourcing of IT has been studied from various perspectives such as flexible communication (Gobal et al., 2002), architecture (Chandrasekaren and Ensing, 2004), alignment (Lee et al., 2006) and management decision-making (Hall and Liedtka, 2005). But, empirical evidence supporting appropriateness of agile methods to off shore ISD is scarce. Based on the empirical findings in a large scale ISD organization, Aydin et al. (2005) have shown that agile methods can be used as proactive risk mitigation means. In line with this line of reasoning, in this study we examine to what extent and in which ways two prominent agile methods address possible risks that are related to salient characteristics of off shore ISD.

5


RESEARCH APPROACH Since the research is aimed to understand the phenomenon at hand – that is, examining effectiveness of agile methods for off shore ISD, we adopt an explorative research approach and inductively draw lessons from the use of agile methods in off shore ISD practice - rather than tests hypotheses defined in advance. The research was conducted in a large international systems development and consultancy company (Capgemini), with sites all over the world, including the traditional off shore countries. The employees involved, 33 in total, are all experienced consultants with more than 10 years experience, working in an off shore context, i.e. working in projects with one or more off shore components (in most cases executed in India). In the majority of the projects, the Rational Unified Process (RUP) was used as a prevailing method. The consultants were asked to list the three fundamental differences between on site and off shore systems development, to associate risks with these differences and to provide the mitigation measures that were proven successful in their projects. We analyzed the data using a clustering approach, which resulted in a number of risks. Note that this is a purely qualitative analysis, aimed at the elicitation of a set of risks. In step 2, we analyzed two popular agile methods, RUP and the Dynamic Systems Development Method (DSDM) (Aydin, Stegwee, Harmsen and Slooten, 2005) and investigated whether the measures used are also provided by these methods. The analysis was done by using metamodelling (Brinkkemper, 1990). In step 3, we analyzed which constructs should be added to RUP and DSDM to make them suitable for off shore development.

6


PERCEIVED CHARACTERISTICS OF, ASSOCIATED RISKS AND MEASURES IN OFF SHORE DEVELOPMENT Considerable research has been done into the gaps that usually emerge in global off shore development when using conventional methods (e.g., (Herbsleb and Moitra, 2001; Fenema, 2002)). The consultants interviewed confirmed the gaps reported in literature, suggested mitigation measures, and commented on their presence in agile methods. Their statements are summarized below for each potential off shore gap (see also Appendix). Culture and Language Off shore development mostly takes place in countries with a culture different than the Western European and American cultures, leading to various interpretations, misunderstandings and thus poor communication. Cultural misunderstandings can be, in general, avoided by working as explicit as possible: confirm agreements in e-mails, put all products (including the written agreements) under version control and test, review and inspect thoroughly. Despite popular belief, most agile methods already contain techniques and concepts to facilitate explicit communication – they can be enhanced by emphasizing the principles of agile methods (“good is good enough”, for instance) and by adding a cultural risk mitigation plan which tackles the issue of management of expectations. By agreeing on an official language for verbal and written communication, misunderstandings due to language problems can be avoided. Key actors such as business analysts or project managers can be trained to improve their communication skills (i.e. technical English) to avoid miscommunication. Agile methods do not recognize measures for this.

7


Geography The client and supplier are geographically separated, often many hours flight. Regular meetings, workshops and team building become difficult to organise. Important stakeholders from the supplier are not able to provide input on time, leading to a deliverable that is not “fit for purpose”. This risk could be mitigated by collaboration tools and by allowing the most important stakeholders to travel between project locations and by clearly defining the communication (responsibilities and timing) between on site and off shore locations. Since agile methods consider input from stakeholders essential, they focus on recognizing stakeholders for a project. However, agile methods do not explicitly consider how communication in an off shore development scenario should be set up. Another risk is, that activities off shore are not controlled, leading to a lack of overview. This risk could be mitigated by implementing a change management procedure for the project. Most agile methods recognize such a procedure. Furthermore, the mandates and responsibilities at client and supplier site need to be agreed upon. Agile methods normally break the development process into sub processes and activities, and provide responsibilities for roles in the project. These sub process/activities and roles can be used to divide responsibilities over the sites. A further measure could be to report on progress and install a project board, with clear mandates on progress. Although agile methods recognize the need for progress reporting, they do not indicate how governance (i.e. project board) is to be set up. A third risk related to geography is, that the client has no control over intra-supplier communication, leading to unclear communication about agreements between supplier and client. This could be dealt with by clearly specifying the communication lines between the client and supplier, but also the lines within the supplier and client. Another measure would be to implement mechanisms

8


that enable the check of agreements, for instance by keeping a mail history on agreements or a repository of important decisions/agreements that is available to client and supplier personnel. Agile methods do not recognize these measures. Time Difference Because of the geographical dispersion, the client and supplier work in different time zones. When the client’s working day starts, the supplier’s working day is already well on under way. A measure would be to agree on office hours and communication moments. If it is not possible to agree on synchronous communication, agreements must be made on asynchronous communication. As a last resort the supplier could adapt to the office hours of client. As stated earlier, agile methods recognize the need to involve stakeholders. However, they do not specify how this involvement should be set up. Control When off shore development is performed with an external supplier (outsourcing), the client holds no control over the work performed by the supplier. This renders effective control over the supplier’s software development process impossible. This could lead to poor interfaces between the client’s and supplier’s process, for instance on the specification of the work to be performed off shore. Effective measures to overcome this risk are to review and inspect products and to measure the extent to which agreements are met, which are key concepts of agile methods. This can be supplemented by an additional role, the liaison officer, which is a representative of client and supplier working at the site of their counterpart. The most obvious measure to mitigate control risks can be found in the software process maturity area: select the supplier based on process maturity and client process fit, provide mutual training and

9


coaching to understand each others processes, agree on the interfaces and mapping in the processes and agree on process changes during the project. Technology When a supplier contracts work for more than one client, technological differences might exist between the client and the supplier. The supplier can not guarantee flawless software, since the supplier does not have a production-like environment to test the software sufficiently. In most agile methods, standards and guidelines are established, communicated and accepted, a Proof of Concept is tested on the client’s platform and sample software is reviewed with the supplier to establish an understanding of the technical platform. These are effective measures, which can be supplemented with broad band network solutions and the selection of the supplier based on the client’s technology. Stability Some off shore countries are politically instable. Governments may tumble, civil wars could break out. Other risks could be caused by corruption, disloyal employees and labor disputes. These factors could render contracts and cause agreements useless. Agile methods are not particularly suitable or unsuitable to handle stability risks – this is simply a matter of selection of countries and of betting on more than one country. Security In outsourced software development a part of the client’s operation is put on the table. When the operation is strategic, security of data and intellectual property is an issue. It might be financially interesting for a supplier to “sell out” a customer’s strategic initiative. Mitigation measures have more to do with watertight contracts and strict

10


selection and auditing of suppliers, than with (agile) methods. Another measure is to provide only non-sensitive data to the supplier (in off shore situations this is often a prerequisite, since privacy legislation of most countries forbid sensitive data to travel abroad) Legislation Privacy and regulatory laws can throw up barriers for off shore development. A detailed contract should avoid these pitfalls. Managing such a contract can be hazardous, since a supplier does not understand the full implications of the conditions. Furthermore, litigation in off shore countries may be costly and useless. Again, agile methods do not provide constructs to mitigate these risks. Measures are watertight contracts and the translation of these contracts in the essential plans and models of the projects. This is often the job of lawyers, which is the reason why legal staff should not be forgotten when assigning roles.

AGILE METHODS AND OFF SHORE DEVELOPMENT We have investigated how well the two most popular system development methods in the UK and the Benelux countries bridge the differences between on site and off shore development. DSDM (DSDM, 2003) and RUP (Kruchten, 2003) contain agile concepts such as iterative and incremental development, timeboxing, prioritization and active user involvement. Besides practical experience and the investigation of the method manuals, we have used additional sources concerning RUP and DSDM (see Cammarano, 2004; DSDM, 2005). RUP and DSDM were conceived as traditional on site methods, but they are more and more used in cross-boundary projects, especially off shore projects in India. Both methods seem suitable for these projects, as they both offer most practices that were

11


identified as essential. Important processes such as requirements management, testing, and configuration and change management are sufficiently implemented and some other measures to bridge differences are available as well (see table 1). Practice, i.e. a large body of off shore projects executed by Capgemini, shows that the huge advantage of agile methods in off shore development is their risk-driven, iterative approach. This is an important prerequisite for getting grip on the activities that are “beyond reach”. The alternative, implementing a large number of controls and thus creating more overhead, causes a lot of frustration and could undermine the cost and time advantage of execution in low wages countries. The processes, products and roles must be, however, supplemented by the following: – In RUP, the Development Case must contain clear schemes describing the responsibilities between on site and off shore roles; – The Software Architect, and software architectures, are of eminent importance. The software architecture provides the framework that enables clear agreements between on site and off shore about who does what and which high level requirements should be met; – A role “Liaison Officer” (between on site and off shore) must be added to both methods; – A role “Contract Manager” must be added to both methods. The person playing this role is responsible for contractual aspects and the subsequent translation of these aspects into role and product descriptions; – More attention must be spent to security and legal aspects, especially in testing; – Risk management considers cultural and cross-boundary risks as well.

12


A method engineering approach for agile methods (Aydin, Stegwee, Harmsen and Slooten, 2005) can be used to add the supplements, to obtain agile methods that are fully equipped for off shore development.

CONCLUSION AND FURTHER RESEARCH Agile methods have been promoted as a panacea for the long-standing problems of conventional methods for on-site and/or off shore ISD in practice (Aydin et al., 2005). This research explores how well agile methods achieve premises of offshore ISD put forward by the agile community where the belief in ‘agility’ appears to be mythical or religious. Both the interviews conducted with consultants as well as the analysis of DSDM and RUP reveal that agile methods are, in principle, suitable for an off shore systems development. They provide optimal, risk-based control without generating too much overhead. However, some measures that are essential to mitigate the risks of off shore development are still lacking and should be added to the “standard” agile method using method engineering techniques. In particular measures related to control, stability, security and legislation are to be added in order to mitigate risks and enjoy agile methods to their full extent in off shore projects. Further research focuses on applying method engineering on agile methods and constructing a situated agile method, based on either RUP or DSDM, that can be used in practice. The practical application of this method is then monitored in projects. By adopting the idea of control flexibility mentioned in method engineering research (Harmsen et al., 1994), one can cope with challenges that novice consultants face when an agile method is fine tuned to specific project characteristics.

13


References Abrahamsson, P., Warsta, J., Siponen, M. T., and Ronkainen, J. (2003) New Directions on Agile Methods: A Comporative Analysis. Paper presented at ICSE 2003, May 3-10, Portland, Oregon, USA, 244-254. Aydin, M., R. Stegwee, F. Harmsen, C. van Slooten (2005). On the Adaptation of Agile Information Systems Development Method, Journal of Database Management 16(4): 25-40. Brinkkemper, S. (1990), Formalisation of Information Systems Modelling, Dissertation, University of Nijmegen, Thesis Publishers, Amsterdam. Cammarano, B. (2004). Geographically distributed development: IBM’s unified lifecycle approach. IBM Rational developerWorks, September. Chan, K.C.C. and Chung, L.M.L. (2004). Integrating process and project management for multi-site software development. Annals of Software Engineering 14: 115143. Chanderasekaren, N. and Ensing, G. (2004). ODC: a global IT services delivery model, Communications of the ACM, 47(5): 47-49 Conchuir, E.O., Holmstrom, H., Agerfalk, P.J. and Fitzgerald, B. (2006). Exploring the assumed benefits of global software development. IEEE International conference on global software engineering (ICGSe’06), Florianópolis, Brazil. Cramton, C.D. (2001). The mutual knowledge problem and its consequences for dispersed collaboration, Organization Science 21(3): 346-371. Damian, D. and Moitra, D. (2006). Global software development: how far have we come? IEEE Software, September/October.

14


DSDM Consortium (2003). Framework for Business Centred Development – Manual version 4.2, DSDM Consortium. DSDM Consortium (2005). Guidelines for applying DSDM in an offshore environment. DSDM Consortium. Fenema, P.C. van (2002) Coordination and Control of Globally Distributed Software Projects,

Erasmus

University

ERIM

PhD

Thesis,

2002,

http://hdl.handle.net/1765/360 Fitzgerald, B., Russo, N., and O’Kane, T. (2000). An Empirical Study of Systems Development Method Tailoring in Practice, the 8th International Conference on Information Systems, Vienna. Gopal, A., Mukhopadhyay, T., Krishnan, M. S. (2002). Virtual extension: The role of software processes and communication in offshore software development, April 2002, Communications of the ACM 45(4). Hall, James A. and Liedtka, S. L. (2005). Financial Performance, CEO Compensation, and Large-Scale Information Technology Outsourcing Decisions, Journal of Management Information Systems. 22 (1): 193 - 222 Harmsen, F., Brinkkemper, S, and Oei, H. (1994). Situational Method Engineering for Information Systems Development Projects. In: T. W. Olle and A. V. Stuart (Eds). Methods and Associated Tools for Information Systems Life Cycle, Amsterdam, North-Holland, 169-194. . Herbsleb, J. D., Mockus, A., Finholt T. and R. E. Grinter (2001). An Empirical Study of Global Software Development: Distance and Speed, Proceedings of the 22nd International Conference on Software Engineering (ICSE '01). Toronto, Canada.

15


Herbsleb, J.D. and Moitra, D. (2001). Global software development, IEEE Software 18(2): 16 – 20 Hidding, G. J. (1997). Reinventing Methodology. Communications of ACM 40(11) Iivari, J., Hirschheim, R. and Klein, H. K. (2001). A Dynamic Framework for Classifying

Information

Systems

Development

Methodologies

and

Approaches, Journal of Management Information Systems, 17(3): 179-218. Jarvenpaa, S.L. and Leidner, D.E.(1999) Communication and trust in global virtual teams, Organization Science 10(6): 791-815. Kruchten, Ph. (2003). The Rational Unified Process. Addison-Wesley. Kuni, R. and Bhushan, N. (2006). IT application assessment model for global software development. IEEE International conference on global software engineering (ICGSe’06), Florianópolis, Brazil. Lee, O.K., Banerjee, P., Lim, K.H., Kumar, K., Van Hillegersberg, J. and Wei, K.K. (2006). Aligning IT components to achieve agility in globally distributed system development. Communications of the ACM 49 (10): 48-54. Paasivaara, M. and Lassenius, C. (2006). Could global software development benefit from agile methods? IEEE International conference on global software engineering, (ICGSe’06), Florianópolis, Brazil. Schatz, B. and Abdelshafi, I.(2005). Primavera gets agile, A successful transition to agile development, IEEE Software, May/June. Seligmann, P. S., Wijers, G. M. and Sol, H. G. (1989). Analyzing the structure of IS methodolfogies. In R. Maes Ed. Proceedings of the First Dutch Conference on IS, Amersfoort, The Netherlands.

16


Truex, D. Baskerville, R. and Travis, J. (2000). Amethodical system development: the deffered meaning of systems development method. Accounting, Management & Technology.10: 53-79. Welke, R. J. (1981). IS/DSS: DBMS Support for Information Systems Development. ISRAM WP-8105-1.0, Faculty of Business, McMaster Univ., Hamilton, ON, Canada.

17


APPENDIX Difference Culture

Risk Expectations between client and supplier do not match

Other notion of “Quality”

Issue and Change Management do not function due to misunderstandings between client and supplier Agreements fail to be met

Geography

Important stakeholders are not able to provide input on time, leading to a deliverable that is not “fit for purpose”

Activities are not controlled, leading to lack of overview

Measure Discuss cultural differences and agree how to handle them (cultural risks mitigation plan). [1] Record client-supplier agreements. [2] Review and inspect products. [3] Version control of all documents concerning agreements about products to be delivered. [4] Version control of all products delivered by the supplier. [5] Make the requirements concerning quality explicit and discuss them with the supplier. When is good, good enough? [6] Version control of all agreements concerning quality requirements. [7] Review and inspect products. [3] Agree test approach for all products. [8] Agree on competences of the staff involved in the project. [9] Clarify terminology – what is an issue? [10] Agree on issue and change management, communicate procedure. [11] Create intercontinental “safety net”, besides local escalation procedures. [12] Agree on planning and delivery of products and services. [13] Agree on penalties. [14] Create incentives if agreements are met. [15] Implement Change Management procedure. [16] Allow most important stakeholders to travel between project locations. [17] Agree on tasks and responsibilities concerning communication. [18] Agree on fixed communication moments. [19] Provide additional communication tools. [20] Implement Change Management procedure. [16] Agree on mandates and responsibilities. [21] Agree on, and implement, progress control and reporting. [22]

18

RUP +

DSDM ++

-++ +

-++ +

++

++

++

++

+

+

++ + O

++ + O

+

--

++

-

O

--

++

++

++ ++

---

++

-

--

++

++

++

++

++

--

++

++

-

+

+

++

+


Difference

Time difference

Control

Risk No control over intrasupplier communication, leading to unclarity of the communication about agreements between supplier and client. Language barriers lead to misunderstands

Communication is hampered due to office hours mismatch between client and supplier System development process of the client is poorly attuned to the process of the supplier

Client does not have sufficient grip on the supplier

Technology

Language

Technology of the supplier differs from client’s technology, as a result of which testing is difficult or impossible

Miscommunication caused by poor language skills

Documentation not in

Measure Agree on communication between client and supplier, but also intra-client and intrasupplier. [23] Implement mechanism to check agreements, e.g. mail processing with history. [24]

RUP --

DSDM +

++

--

Agree on language for verbal and written communication and other products. [25] Send most important stakeholders to language training. [26] Agree on office hours and communication moments. [27] Asynchronous communication. [20] Supplier adapts to office hours of client. [27] Select the supplier based on process maturity and client process fit. [28] Provide mutual training and coaching, to understand each others processes. [29] Agree on the interfaces and mappings in the processes. [30] Record the quality requirements for the products constituting the interfaces. [31] Agree on process changes during the project. [32] Review and inspect products. [3] Liaison officers of the client at the supplier’s site. [33] Implement a “demand management” role, managing the supplier. [34] Deliver frequently plans and progress reports. [22] Jointly implement a measurement tool to indicate whether agreements are met. [22] Select supplier based on technology. [35] Develop proof of concept and test this on client’s platform. [36] Create network connection between client and supplier to enable production like testing [37] Establish, communicate and accept standards and guidelines [38] Review example software with supplier to establish understanding of the platform [39] Agree on certification level (TOEFL 500 English) of reading, writing and verbal skills [40] Arrange courses in official language [26] Select off shore countries based on mastery of the official language [41] Translate essential documentation [42]

--

++

--

O

--

--

---

++ --

--

+

--

--

+

++

+

++

--

--

++ --

++ ++

--

--

++

+

++

+

-++

+ ++

--

++

++

++

++

++

--

+

---

O +

--

--

19


Difference

Measure Agree to follow official language as of moment x [43] Stability Conflicts and wars Spread the risk and do not bet on one supplier and/or country. [44] Define and test contingency plans and procedures. [45] Select off shore countries on stability. [46] Social upheaval Select off shore countries on stability. [46] Corruption Select off shore countries on stability. [46] Instable labour market Provide adequate conditions of employment and benefits [47] Spread the risk and do not bet on one supplier and/or country. [44] Security Leakage of sensitive data Water tight contracting [48] and information Select off shore suppliers on reliability [49] Audit supplier’s security [50] Only provide non sensitive data to supplier [51] Legislation Breach of laws and Water tight contracting on laws and regulations regulations [52] Involve lawyers in off shore decision making [53] Involve lawyers in managing running off shore contracts [54] Cooperate with lawyers in off shore country and/or position a legal office off shore [55] Table 1: Support of offshore risk mitigation measures by agile methods ++ = += O= -= -- =

Risk official language

RUP --

DSDM O

--

--

--

--

-----

-----

--

--

-----

-+ ---

--

--

--

+

--

--

--

--

Measure fully incorporated Measure incorporated, but not specific enough Measure partially incorporated Measure to some extent partially incorporated Measure not incorporated

(The numbers associated with measures indicate unique identifiers of measures to be included in the method; similar measures are combined)

20

agile methods for off shore information systems ... - CiteSeerX

agile methods for off shore information systems ... - CiteSeerX

Suggest Documents

Agile methods for embedded systems development - a ... - CiteSeerX

Suggestions on communications systems for off- shore vessels

Potential on-shore and off-shore reservoirs for ... - Semantic Scholar

REDESIGN OF FLARE SYSTEMS AT OFF-SHORE ... - AVPG

Methods for Ranking Information Retrieval Systems Without ...

Methods and Tools for Information Systems Development ...

Environmental Footprint Analysis of On-shore and Off-shore Wind ...

Agile methods for embedded systems development - a literature ...

Geographic information systems: Providing information for ... - CiteSeerX

Agile SYSTEMS ENGINEERING vs. AGILE SYSTEMS ...

Agile SYSTEMS ENGINEERING versus AGILE SYSTEMS engineering

Agile SYSTEMS ENGINEERING versus AGILE SYSTEMS engineering

Agile SYSTEMS ENGINEERING vs. AGILE SYSTEMS ...

Tassal announces plans off-shore, not off-mission

Source Code Repositories and Agile Methods - CiteSeerX

Agile Information Systems for Mastering Supply Chain Uncertainty - Core

Agile Information Systems for Mastering Supply Chain Uncertainty

Improvisational Theater for Information Systems: an Agile, Experience ...

Agile methods: a comparative analysis - CiteSeerX

HYDRO-ENVIRONMENTAL MODELlING OF OFF-SHORE AND ...

Information Extraction Tools and Methods for ... - CiteSeerX

Assessment Methods for Information Quality Criteria - CiteSeerX

Economic and technical criteria for designing future off-shore HVDC ...

Guidelines for the development and operation of off-shore helicopter