Negotiating a Systems Development Method - Springer

51 Negotiating a Systems Development Method ¨ Fredrik Karlsson and Karin Hedstrom

Abstract Systems development methods (or methods) are often applied in tailored version to fit the actual situation. Method tailoring is in most the existing literature viewed as either (a) a highly rational process with the method engineer as the driver where the project members are passive information providers or (b) an unstructured process where the systems developer makes individual choices, a selection process without any driver. The purpose of this chapter is to illustrate that important design decisions during method tailoring are made by project members through negotiation. The study has been carried out using the perspective of actor-network theory. Our narratives depict method tailoring as more complex than (a) and (b) show the driver role rotates between the project members, and design decisions are based on influences from several project members. However, these design decisions are not consensus decisions. Keywords Method tailoring



Method engineering



Actor-network theory

1. Introduction Systems development methods (or methods for short) are rarely applied as described in method textbooks. In most situations they are tailored to fit the actual needs of development projects [5]. During systems development projects, method parts are added, omitted, exchanged or modified when necessary. The need to tailor methods is acknowledged by the two schools of information systems development methods [1]: method engineering and method-in-action. The school of method(ology) engineering [4, 14] represents a rigorous approach for creating and tailoring methods. Within this school, it is possible to make a distinction between static and dynamic method adaptation [2]. Static method adaptation is carried out during a project’s initial stage resulting in an initial route map. A wide range of approaches (e.g. [7, 22, 10]) can be found. Dynamic tailoring, or what Rossi et al. [23] term evolutionary method engineering, means changing the method during the development process. Hence, the method requirements are not viewed as known at the start and these approaches rely on shorter feedback loops. However, the method tailoring still seems to be driven by the method engineer. The second school, method-in-action [6], focuses on the relationship between method-in-concept and methods actually used [8]. Several studies discuss that methods are not used, at least not as they are described in the textbooks (e.g. [9, 27]). Fitzgerald et al. [6] provide a more elaborated view. They have shown that method use is U-shaped in relation to experience. When inexperienced developers become more experienced they tend to discard methods. But as developers become even more experienced they start using methods again. This use differs from their initial use, however. Experienced developers use selections of methods based on their needs, experience and viewpoints. Consequently, we find that the concept of the  ¨ Fredrik Karlsson and Karin Hedstrom

¨ ¨ MELAB, Swedish Business School, Orebro University, SE-701 82, Orebro, Sweden.

G.A. Papadopoulos et al. (eds.), Information Systems Development, DOI 10.1007/b137171_51, Ó Springer ScienceþBusiness Media, LLC 2009 491

492

¨ Fredrik Karlsson and Karin Hedstrom

reflective practitioner [24] is embodied in method-in-action research. Method tailoring is, therefore, an integrated activity in the systems developer’s use of methods. Consequently, method tailoring is viewed as either (a) a highly rational process with the method engineer as the driver, where the project members are passive information providers or (b) as an unstructured process where the systems developer makes individual choices, a selection process without any driver. Both these perspectives describe method tailoring as a non-collaborative activity, without social influences. Riemenschneider and Hardgrave [21], however, show that acceptance of methods is dependent of ‘the opinions of developers’ coworkers and supervisors towards using the methodology.’ This means that method tailoring is a highly social activity, where cooperation between coworkers constitute an important aspect of the method tailoring process. Designing methods is an act of making social and technological design choices. We believe that method tailoring, due to the cooperative of method use [11], is best viewed as a negotiating activity, where different interests and values are presented and discussed. The emergent method is a result of negotiation, where different actors hold and promote various and sometimes conflicting values influencing the design. These values are exposed to negotiations during the systems development process, where some values become accepted and part of the method-in-use, while others are excluded [17]. The purpose of this chapter is to illustrate that important design decisions during method tailoring are made through negotiation. It is based on a case study of an information systems development project in a public organization. We provide a rich description of the interplay that takes place during an information systems development project analyzing the impact on the emergent method. For this purpose we apply actor-network theory (ANT) [15, 26], which has been used before in the information systems field (e.g. [18, 20]. This chapter is structured as follows. In the second section, we outline our interpretation of ANT as our research approach and theoretical background. Section 3 contains four narratives and analysis from the case concerning different method tailoring activities. Finally, this chapter ends with reflections on method tailoring as negotiation and a short conclusion.

2. Research Design 2.1. Theoretical Underpinnings Considering the purpose of this chapter, which puts the focus on different actors’ sense-making, this study is classified as interpretative [25, 12]. The case unfolds the negotiation process of method tailoring from the perspectives of different actors. This is important as different actors hold and negotiate different values, influencing the emergent method. By following the translation process through the actions of the actors taking part in the method tailoring process, we disclose how negotiation has formed the emergent method. The analytical units are important design decisions influencing the emergent method. The analytical units as well as the analysis were based on the perspective of ANT (e.g. [15]), but also influenced by the early writings of Mumford [19] and Kling [13]. Mumford [14] illustrated how different actors’ values influenced the development and use of IT systems. This made us view the tailoring of methods as an intrinsically social activity influenced by peoples’ interests and values. ANT has given us, not only theoretical but also methodological support. The consequence being that we have focused on analyzing the translation process by following the actors. We have focused on actors and their actions by studying the method tailoring process as a process of negotiation, where actors try to ‘transcribe’ or include their values and interests in the emergent method by means of interventions. ANT is a social theory that focuses how actors’ relations evolve and changes the coherence in networks [15]. Using this theory as a frame of reference makes it possible to study how existing relations in actor-networks change and new relations as well as networks arise. These relations are of significant importance to understand when analyzing how a method evolves during a project based on the involvement of different actors. These changes are captured through the narrative approach of ANT, where

Negotiating a Systems Development Method

493

different actors are allowed to express their view. In other words, ANT is an appropriate frame of reference for investigating the role of negotiation in method tailoring. Our interpretation of this framework is inspired by Walsham [25] (see Table 51.1). This framework does have a specific characteristic; it does not contain any a priori distinction between human and nonhuman actors. Both concepts are viewed as active makers of actor-networks and are specializations of the actant concept. Furthermore, networks are changed through translation. A translation is establishment of a new relation between actors. Latour [16] describes it as coexisting in a network to achieve a common goal, for example, when a system analyst and a tester agree to document an information system’s external behaviour using use cases. Often translation requires enrollment where an actor seeks to influence how another actor should act. An example of enrollment during method tailoring is when a tester tries to influence a system analyst to write pre-conditions in the use cases – because they are important information when writing test cases. Enrollment and translation can result in inscriptions, where interests are inscribed into written material or technical systems. If we continue our example above, a tester and a system analyst can decide to create a use case template containing a pre-condition paragraph. This template then becomes an inscription of the method.

Table 51.1. Key Concepts in the ANT framework. Concept

Interpretation of the concept

Actor or actant Actornetwork Translation

Both human and non-human actors such as systems analysts, information systems and methods.

Enrollment Delegate Inscription

A heterogeneous collection of aligned interest, including people and methods. The creation of an alliance concerning a specific issue between humans and non humans, for example, an agreement to use test cases during testing. When an actor seeks to influence another actor to act in a particular manner. For example, when a tester provide arguments for the use of use cases because they are excellent starting points for test case writing. An actor who represents the viewpoints of others. For example, if an implementer argues for the use of use cases on the behalf of the tester. A frozen organizational discourse. For example, the decision and use of use cases to capture requirements.

2.2. Case Description and Data Collection The empirical base is an information systems development project undertaken in a public organization. The case is selected as an illustration of the negotiating character of method tailoring. We have chosen to demonstrate the negotiations that occur during the process of method tailoring by the use of design decisions that have had impact on the emergent method. A content management system (CMS) was implemented and an existing Web site was migrated to this platform. The CMS purchased was a framework that needed tailoring in order to fit the organizational needs. It meant creating complementing functionality, integration with existing information systems and designing page layouts (Web page templates). The first author participated as one of 13 regular team members in this project, playing the role as implementer. The project lasted 3 years and the first author spent 1, 200 man hours during the project’s first 18 months. Consequently, the first author participated in the tailoring process as a normal team member, which can give rise to a certain bias. However, the research has been carried out as a retrospective study based on existing data. Furthermore, the high degree of involvement was a trade-off in order to get access to the project. This research is based on several data sources: intermediate project artefacts, e-mails, project notes, the CMS, and the new Web site. Intermediate project artefacts show what has actually been documented with the method-in-use and what kind of templates were used. Furthermore, these artefacts are timestamped making it possible to analyse how they have evolved over time. That is to say, they show the result

¨ Fredrik Karlsson and Karin Hedstrom

494

of method tailoring and how they have affected the method’s product model. The e-mails and the project notes are used to capture tailoring decisions and arguments behind these decisions. Hence, these documents contain traces of the project members’ different viewpoints about the emergent method. Finally, the CMS and the new Web site contain the results of the project work.

3. The Negotiating Process of Method Tailoring The CMS project was carried out as, mainly, an in-house project at the public organization. As described above, the regular project team consisted of 13 people who are the basis for the analysis below. One of the project members was a hired consultant. The project was carried out at three different locations, two locations inside the public organization and one location at the consulting firm. The actors are categorized according to the main roles that have been identified in the project: project manager, systems administrator, implementer, requirements engineer and content manager. No explicit method had been chosen as the starting point for the tailoring activities. The size of this project and the details needed to unfold the negotiation process of the emergent method is to some extent incompatible; it is impossible to provide a description of the complete method tailoring process. Accordingly, we are forced to make a selection of examples based on four negotiation situations where design decisions have had a major impact on the emergent method. This selection covers the project start, requirements, testing and deployment. Hence, we have made an illustration that covers different stages of the development process. 3.1. Negotiation 1 – Basic Principles This example is from one of the initial project meetings. No development work has been carried out, yet. The CMS has been bought and is still waiting to be installed on the development server. Hence, the emergent method is still in its bud. The project manager addressed the need for a starting point at a project meeting. He proposed a basic philosophy anchored in the agile community (e.g. [3]). This proposal is viewed as an enrollment including all project members. Furthermore, this is an enrollment of parts of agile methods. During this project meeting the philosophy was summarized in three bullet points (which do not necessarily correspond to the common understanding among scholars): (1) the use of short timeboxes (iterative development) (2) face-toface communication and (3) interaction with the end users (who the content managers represented). The proposal was well received by the project team and is part of the negotiation results found in Table 51.2. However, one concern was raised by the implementers. They concluded that they would sometimes be working at two or three different locations, making face-to-face communication difficult. Still they agreed, that this principle should be guiding when possible. Furthermore, they made the suggestion to define the timebox as a week. This suggestion was in line with the project manager’s viewpoint and the remaining project members did not object. In addition, the project manager suggested 1 hour project meetings each Friday. These meetings had two purposes (1) to discuss current status of the project and (2) to decide the work package for the forthcoming timebox. During most of the project the 1 week length of the timeboxes was a good choice. However, during some stages of the project the implementers had problems implementing larger user stories within 1 week (for example, the debate forum discussed below). Table 51.2. Negotiation 1 – Summary. Actors Negotiation results

The project manager, the implementers, the content managers, the systems administrators and the requirements engineer Three basic method principles and their initial implementation

Negotiating a Systems Development Method

495

3.2. Negotiation 2 – Storyboards Much of the requirement work during this project concerned the Web page templates in the CMS, because these templates determined what type of Web pages that could be built and their possible layouts. For example, the purpose of a Web page template could act as the starting point for building personal Web pages. Simple sketches were used to capture such layout requirements and the different options that had to be available. This work was carried out by the requirements engineer together with the content managers. However, when it came to more advanced Web page templates, containing interaction possibilities, sketches did not provide enough information. For example, one Web page template concerned a debate forum. The Web page template had to contain functionality to create subject threads, make contributions to the discussion and so forth. The emergent method’s inadequacy was acknowledged by both the requirements engineer and the implementers, for example, in an e-mail conversation: ‘what are the options in this listbox’, ‘how are these [Web] pages linked to each other’, ‘how shall we display the thread overview’ and ‘I know we did not include it [the classification of contributions] in the sketch.’ In a later e-mail the requirements engineer concludes ‘that several options exist’ and she suggests the use of either use cases or storyboards to capture the more advanced requirements. The suggestions she makes are anchored in her knowledge about methods. Hence, she enrolls other methods as a support in this discussion. Through the proposal she tried to enroll both the content managers and the implementers in use of one of these techniques. Two of the implementers preferred storyboards to use cases. This was expressed in an e-mail reply ‘use cases tend to become cluttered . . . difficult to show how [web] pages are related.’ Consequently, the two implementers seem to be concerned, based on their knowledge about other methods, with the amount and the type of details that are captured if they chose to use, use cases. Furthermore, the implementers needed to know how Web pages were related to each other in order to determine possible navigation paths and when to provide a specified functionality. In an additional e-mail to the implementers and the content managers, the requirements engineer referred to a discussion with some of the content managers (it is unclear with whom). She stated that the content managers preferred storyboards as well, ‘since they are easier [to read]’. We can conclude that there exists a mutual agreement between the requirements engineer, the content managers and the implementers about which option to choose. Therefore, the requirements engineer concludes in the above-mentioned email that she would use storyboards to document more advanced requirements. This decision changed the emergent method and is viewed as a negotiation result in Table 51.3. Table 51.3. Negotiation 2 – Summary. Actors Negotiation results

The requirements engineer, the implementers and the content manager The use of storyboards to capture more advanced requirements

The project managers and the systems administrators had, so far as the e-mail conversation can reveal, not been aware of method tailoring activity. The use of storyboards was presented on a project meeting later on. Neither the project managers nor the systems administrators had any objections.

3.3. Negotiation 3 – Bug Report Template The point of departure for this example of negotiation is a situation where there was a need to begin testing some parts of the implemented CMS. The purpose of these tests was to see if implemented Web page templates meet the layout as well as the functional requirements. The implementers concluded that the emergent method lacked support for test reports. The content managers, who are responsible for migrating the Web content and testing the Web page templates, had just begun building Web pages. They gave oral reports to the implementers about the flaws they found. In some cases they documented them on post-it

¨ Fredrik Karlsson and Karin Hedstrom

496

notes. In addition, the project manager, the systems administrators and the requirements engineer did not expressed any concerns with this way of working. One of the implementers addressed this issue with the content managers via e-mail. In an e-mail, the implementer tried to enroll the content manager as he presented the need for one shared artefact for documented bugs, because ‘I believe we can not keep trace of all the bugs we have found.’ The content managers’ answers to this e-mail can be divided as follows: (1) two persons did acknowledge the problem, (2) one person did not acknowledge this as a problem and (3) two persons did not answer. In an e-mail reply to the content managers the implementer proposed ‘a simple Excel sheet . . . on a shared domain’. The implementer received three positive replies on this invitation. In one reply we find ‘. . . we have to discuss the layout [of this document]’. The person who did not acknowledge the need for a formal test report document did not answer the implementer’s e-mail. The implementers discussed the need for a formal test report document with the project manager, arguing that they were not able to manage the change requests with the current way of working. Hence, they enrolled the project manager in the method tailoring process. At this meeting the implementers presented a document template, which was later e-mailed to the content managers. The e-mail conversation shows that the project manager acted as delegate for the implementers: ‘I believe this [the document layout] looks good.’ However, he did not state that the team members had to use the template. The document template was further discussed during a Friday meeting. All project members participated in this meeting except the systems administrators. In the first document layout, which had been sent out via e-mail, we find four columns: serial number as identification, bug description, who has found the bug and status. One of the content managers brought forward the argument that it would be good to see ‘who is or have been working with the bug’. Hence, he suggested an additional column for this purpose. In addition, he suggested three classes for the status column: unsolved, in progress and solved. Two of the implementers explicitly agreed that this was a good improvement. One of the implementers made an additional suggestion – to include a column containing the name of the Web browser that had been used when the problem occurred. He argued this was important information, because Web browsers are implemented differently. A second implementer objected arguing that this information could be provided in the bug description. The first implementer provided a counter-argument ‘it is not obvious [that we need such information]’. The second implementer aligned with this argument. One of the content managers thought it was a good idea to include an extra column. A decision was taken by the project manager to report identified bugs in this document template, and that the template had to include the two improvements described above. This decision was explicitly supported at the meeting by the implementers as well as two of the content managers. Consequently, an inscription in the emergent method was done, see Table 51.4. Table 51.4. Negotiation 3 – Summary. Actors Negotiation results

The implementers, the content manager and the project manager Bug report template

Project documentation, however, shows that two of the content managers disagreed with the decision and the inscription. In most cases, they continued to report bugs via post-it notes, e-mail and orally. This snap shot shows that the emergent method was not shared by all project members when it came to method-in-action, despite that all project members had possibilities to influence the method design. Finally, the e-mail analysis unfold that the implementers tried to enroll the requirements engineer in this part of the method tailoring process. She was carbon copied several of the initial e-mails.

Negotiating a Systems Development Method

497

3.4. Negotiation 4 – Standardization of Web Page Template Documentation The content managers in the project team represented a larger group of content managers. One of the aims with the CMS was to simplify Web publication, allowing all employees of the organization to edit Web pages within their area of responsibility. However, to enable such a deployment in the organization there was a need for user manuals. They had to include advice on when a Web page template was appropriate to use and what layout options that existed for each template. The content managers were responsible for producing the user manuals beside the task to migrate the old Web site to the new platform. However, in order to write these manuals they needed input from the implementers about the meaning of input boxes, options and the dimension that each option had. This information was not evident from using the Web page templates. Consequently, the content managers’ task was made difficult because of lacking documentation routines. The content managers called the project manager’s attention to this issue. At this stage he acted as a delegate and via an e-mail he called the implementers to a meeting ‘concerning the documentation of the Web page templates.’ The implementers agreed with him that they had a backlog, but they argued that much of the documentation was available in the source code. However, the source code was unavailable to the content managers. In addition, the implementers concluded that they had no structured way of documenting the needed information. Hence, this meeting unfolded that neither the implementers nor the content managers were satisfied with the emergent method. One of the implementers created a document template in order to standardize the structure of the Web page template documentation. He e-mailed this template as a suggestion to the content managers and the project manager, which is considered as an enrollment. The suggestion only received positive replies. When the implementers started using the documentation template they made an inscription to the emergent method, which is found as the negotiation results in Table 51.5. The requirements engineer and the systems administrators were still aligning with the emergent method, since this issue did not concern them. Table 51.5. Negotiation 4 – Summary. Actors Negotiation results

The content managers, the project manager and the implementers Document template to standardize the structure of the Web page template documentation

4. Reflections on Method Tailoring as Negotiation All four snap shots of the method tailoring process show that the emergent method is modified based on the needs of project members and the insufficiencies they have identified. Often such problems occur in the intersection between different actor categories, for example, between the implementers and the content managers in third example. The driver of the method tailoring process shifts depending on the problem areas. For example, in the first example the project manager was the driver, while the implementers drove the tailoring process in the second and third example. Consequently, these examples show a problem with the method engineering view with the method engineer as the driver, and where project members are passive information providers. In addition, the examples show two types of enrollments during method tailoring: direct and indirect. Direct enrollment occurs when project members address other project members that are concerned with the problem. One example is when the implementers addressed the requirements engineer about more elaborated requirement specifications. Indirect enrollment, on the other hand, occurs when project members try to involve actors that are not directly concerned with the problem. For example, the implementers addressed the project manager with their concern about the bug report template. Hence, project members try to influence each other using own arguments as well as the arguments of others.

498

¨ Fredrik Karlsson and Karin Hedstrom

Negotiation, however, is no guarantee that the emergent method will become method-in-action. The third example, concerning the bug report template, shows that the decided method was not used by all project members. First, as shown in the example it is not always that negotiation results in consensus. Second, even though the analysis has not explicitly focused this issue, one can suspect that project members are not always involved in the negotiation process under the same conditions. Both these concerns can affect the will to use the method.

5. Conclusion Most of the existing literature view method tailoring as either (a) a highly rational process with the method engineer as the driver where the project members are passive information providers or (b) an unstructured process where the systems developer makes individual choices, a selection process without any driver. The purpose of this chapter is to illustrate that important design decisions during method tailoring are made through negotiation. Our narratives depict method tailoring as more complex than (a) and (b) show; results that are relevant both for the method engineering and the method-in-action communities. Method engineering, being the more normative of the two schools, is often concerned with method tailoring approaches and tools. Our study shows that method engineering tools should enable all project members to be drivers of the method tailoring process – to let them address their needs for design decisions. In addition, the negotiations in our study have been about intersections between actor categories. Hence, method engineering tools should support identification of such intersections, to help identify the need for design decisions and negotiation. To the method-in-action school we contribute with a deeper understanding of the method-in-action concept itself. Our results show that project members try to influence design decisions direct and indirect; direct through their own involvement and indirect through the use of delegates. Furthermore, we found that method tailoring is not a consensus process and is no guarantee that the emergent method, the design decisions, will be followed by all project members.

References 1. A˚gerfalk, P. J. and Fitzgerald, B. (2006). Exploring the concept of method rationale: A conceptual tool for method tailoring. In Siau, K. (ed.) Advanced Topics in Database Research. pp. 63–78, Hershey, PA: Idea Group. 2. Aydin, M. N., Harmsen, F., Van Slooten, K. and Stegwee, R. A. (2005). On the adaptation of an agile information systems development method. Journal of Database Management, 16(4): 24–40. 3. Beck, K. (2000). Extreme Programming Explained: Embrace Change, Reading, MA: Addison-Wesley. 4. Brinkkemper, S. (1996). Method engineering: Engineering of information systems development methods and tools. Information and Software Technology, 38(4): 275–280. 5. Fitzgerald, B., Russo, N. L. and O’kane, T. (2003). Software development method tailoring at Motorola. Communications of the ACM, 46(4): 65–70. 6. Fitzgerald, B., Russo, N. L. and Stolterman, E. (2002). Information Systems Development – Methods in Action, Berkshire, UK: McGraw-Hill. 7. Harmsen, A. F. (1997). Situational Method Engineering, Utrecht, The Netherlands: University of Twente. 8. Iivari, J. and Maansaari, J. (1998). The usage of systems development methods: Are we stuck to old practice? Information and Software Technology, 40: 501–510. 9. Introna, L. D. and Whitley, E. A. (1997). Against method-ism: Exploring the limits of method. Information Technology & People, 10(1): 31–45. 10. Karlsson, F. and A˚gerfalk, P. J. (2004). Method configuration: Adapting to situational characteristics while creating reusable assets. Information and Software Technology, 46(9): 619–633. 11. Karlsson, F. and Wistrand, K. (2006). Combining method engineering with activity theory: theoretical grounding of the method component concept. European Journal of Information Systems, 15(1): 82–90. 12. Klein, H. K. and Myers, M. D. (1999). A set of principles for conducting and evaluating interpretative field studies in information system. MIS Quarterly, 23(1): 67–94. 13. Kling, R. (1987). Computerization as an ongoing social and political process. In Bjerknes, G., Ehn, P. and Kyng, M. (eds.) Computers and Democracy. A Scandinavian Challenge. Aldershot: Avery.

Negotiating a Systems Development Method

499

14. Kumar, K. and Wellke, R. J. (1992). Methodology engineering: A proposal for situation specific methodology construction. In Cotterman, W. W. and Senn, J. A. (eds.) Challenges and Strategies for Research in Systems Development. pp. 257–269, Washington, DC: John Wiley & Sons. 15. Latour, B. (1991). Technology is society made durable. In Law, J. (ed.) A Sociology of Monsters: Essays on Power, Technology and Domination. pp. 103–131, London: Routledge & Kegan Paul. 16. Latour, B. (2007). Reassembling the Social: An Introduction to Actor-Network-Theory, Oxford: Oxford University Press. 17. Mcmaster, T., Vidgen, R. and Wastell, D. (1998). Information system development and ’due process’: The case of the Van Sant map. In Buch, N. J., Damsgaard, J., Eriksen, L. B., Iversen, J. H. and Nielsen, P. A. (eds.) Information Systems Research in Collaboration with Industry. Proceedings of the 21st Information Systems Research seminar in Scandinavia (IRIS). Aalborg, Danmark: Department of Computer Science, Aalborg University. 18. Monteiro, E. and Hanseth, O. (1996). Social shaping of information infrastructure. In Orlikowski, W., Walsham, G., Jones, M. and Degross, J. (eds.) Information Technology and Changes in Organisational Work. pp. 327–343, London: Chapman & Hall. 19. Mumford (1981) 20. Quattrone, P. and Hopper, T. (2006). What is IT? Information and Organization, 16(3): 212–250. 21. Riemenschneider, C. K., Hardgrave, B. C. and Davis, F. D. (2002). Explaining software developer acceptance of methodologies: A comparison of five theoretical models. IEEE Transactions on Software Engineering, 28(12): 1135–1145. 22. Rolland, C. and Prakash, N. (1996). A proposal for context-specific method engineering. In Brinkkemper, S., Lyytinen, K. and Welke, R. (eds.) IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering on Method Engineering: Principles of Method Construction and Tool Support. Chapman & Hall, Atlanta, Georgia, United States, pp. 191–208. 23. Rossi, M., Ramesh, B., Lyytinen, K. and Tolvanen, J.-P. (2004). Managing evolutionary method engineering by method rationale. Journal of Association of Information Systems, 5(9): 356–391. 24. Schon, ¨ D. A. (1983). The Reflective Practitioner: How Professionals Think in Action, New York: Basic Books. 25. Walsham, G. (1995). Interpretive case studies in IS research: Nature and method. European Journal of Information Systems, 4: 74–81. 26. Walsham, G. (1997). Actor-network theory and IS research: Current status and future prospects. In Lee, A. S., Liebenau, J. and Degross, J. I. (eds.) The IFIP TC8 WG 8.2 International Conference on Information Systems and Qualitative Research. Chapman & Hall, New York, pp. 466–480. 27. Wynekoop, J. L. and Russo, N. L. (1995). Systems development methodologies: Unanswered questions. Journal of Information Technology, 10(2): 65–73.