In the present paragraph, we interpret the FX-case through the Socratic dialogue model presented above. First, we identify communicative acts, which we find are representative for the case. Second, we interpret the acts with the use of the model, thereby we identify how the communicating parties acted and reacted in the process, and we seek to explain how their acting and reacting influenced the process over time. Third, we speculate how the process might have evolved if the Socratic dialogue had been applied.
Identifying Communicative Acts
For the purpose of interpretation of the case, we needed communicative acts represen- tative for the case. Hence, we began our analysis by looking for such acts in the case.
As communicative acts, we defined points in time where either of the involved parties
“send messages” to the other party leading to some kind of response. As our first example, we identify the point in time where developers in Unique make contact with West Bank and suggest themselves as potential suppliers of an FX-system to West Bank. West Bank, which we now term the user, responds by agreeing to visit Unique on-site and see a presentation of the system. In total, we identified eight communicative acts. These, however, vary with regard to both content and form. Foremost, it is important to note that the form changes significantly after the first unsuccessful delivery of modules of the FX- system. We therefore talk about phase 1 initial communicative acts and phase 2 adapted communicative acts.
Initial Communicative Acts
As the first five communicative acts, we have identified the following:
Example A1:
• Developers make contact to users and suggest their firm as supplier of an FX- system
• Users accept invitation to visit developers’ site and take a look at the system
Example A2:
• Developers present the proposed system to the users
• Users accept the proposed system as a suitable response to their needs
Example A3:
• Users pose questions regarding technical and functional aspects of the proposed system
• Developers answer the technical questions, and the currency dealers borrowed from existing customers answer questions about functional aspects of the system
Example A4:
• Developers write up contract about sale and delivery of the FX-system
• Users sign contract and buy the proposed FX-system
Example A5:
• Developers initiate development of the proposed FX-system
• Users passively await delivery of the FX-system
Looking at these communicative acts, it appears that they all have a similar form and content. Starting with the form, it can be observed that the communication is initiated by the developer-side as it approaches the user-side and suggests itself as an appropriate supplier of the FX-system that the user-side is looking for. From the developer-side, this gives the communicative acts a focus on convincing the user-side about the appropri- ateness in choosing it as the FX-system supplier. Also, it gives the communicative acts a flavor of being orchestrated by the developer-side constantly looking for the user’s approval of its points of view.
As the dialogue evolves, the developer-side increasingly focuses on getting the user- side to confirm that it is on the right track regarding the proposed FX-system. This happens even though the developer-side must have some doubts about their actual capacity to deliver the proposed FX-system. In other words, no uncertainty is revealed and communicated by the developer-side. Viewing this from a Singerian perspective, it would be perceived as a highly unethical act. We do not claim that the developer-side knew that it would be difficult to deliver the system, but we assume that they must have had some doubt and that this doubt could have been articulated in an early stage of the
dialogue. However, little dialogue about the users’ requirements to the system took place in the initial stages of the process.
When interpreting the communicative acts in the light of the Socratic dialogue, we are afforded the following picture. The central question is formulated by the developer-side and is never tested in the dialogue with the user-side. The central question may be formulated as “We have an excellent FX-system here, don’t you think?” If we then move on to Step 2 in the Socratic dialogue, the provision of concrete examples, it happens as the developer-side demonstrates the constructed FX-system to the user-side, and experiences that the user-side accepts the shown system as a suitable response to its needs, not even questioning the existence of the system. In neither of these two examples does the user-side inquire about the developer-side’s understanding of its demands to such a system. Instead, “feedback” from users continuously confirmed the developers’
formulation of the central question.
Adapted Communicative Acts
As the final three communicative acts, we have identified the following:
Step B1:
• Users respond to delivery by stating that this is not an FX-system
• Developers respond by assigning a new project manager who reorganizes the project team
Step B2:
• Developers begin to inquire into the users’ demands to the system
• Users accept the developers’ invitation to inquiring dialogue
Step B3:
• Developers suggest a step-by-step procedure for identification of the demands of the users, based on the one-liner contractual descriptions of the functionality of the FX-system
• Users engage in this activity by joining the dialogue with the developers When looking at these three communicative acts, it appears that the initial failure by the developer-side to deliver what the user-side expected had an impact on how the dialogue evolved. In the adapted phase, far more open-ended communicative acts dominate. The weaknesses of the developer-side, which used to be hidden, are now obvious and need to be dealt with if the project is to continue. However, these inquiries from the user-side only emerged as the developer-side failed to fulfill the user-side’s expectations to the
delivery of the first modules of the system. The reorganization of the managerial setup following the failed delivery provided for initiation of an inquiring dialogue between the two parties.
Viewing the adapted communicative acts in the light of the Socratic dialogue, we can say that the new project manager initiates reformulation of the central question. Basically, the developer-side says: “What does an FX-system look like?” And essentially, the user- side replies: “That is actually a very good question.” Here we witnesses a break point in the way the developer-side approaches the problem of developing the FX-system, and the user-side responds by accepting that this break with the prior pattern of communi- cative acts is highly needed. Hence, a new central question is being formulated through the involvement of both parties.
As the Socratic dialogue proceeds, the step-by-step procedure for identification of the user-side’s needs implies inquiring into the meaning of the one-liner descriptions of the various functions in the proposed FX-system. If we perceive these one-liners as high- level abstractions containing a huge amount of exformation, it obviously becomes important that each party’s interpretation of the one-liner is revealed, as most likely each interpretation is unknown to the other party. Hence, in this instance, the Socratic dialogue is about transforming abstractions to raw data. This happened as the involved parties provided concrete examples of how they interpret the one-liners. Examples may have been elaborated by provision of counter-examples or more detailed examples. Then, as the parties discuss and agree on best concrete examples, they obtain verification of their reciprocal understanding. Of course, the parties can never be sure of their full common understanding, and that is exactly why continuous dialogue is important.
Based on these discussions and agreements, formulation of main statements about the functionalities could take place. The main statements then serve as the basis for elaboration about the content of the functionalities to be included in the system. We cannot say much about E and F in the model, although we would expect that uncovering of crucial and case related exformation takes place here. We are however quite sure that in the FX-case testing of statements happened as modules were delivered and accepted or rejected by the users.
An important insight, which emerged in the adapted phase is that the user-side had a very vague picture of their demands to the FX-system. We see this in the fact that the user- side constantly changes its requirements to the system, and this uncertainty may have influenced them to not inquire about the presented FX-system in the initial phase.
Closure on Case Interpretation
Our interpretation of the FX-case has demonstrated that inquiring practice based on Socratic dialogue can make a difference in the quality of the output produced in IS development processes. The question that, of course, emerges is whether the developer- side had succeeded if the initial communicative acts with the user-side had started with an inquiring approach. Although we emphasize the importance of an inquiring approach in the user-developer communication, we cannot neglect that this kind of dialogue may foster uncertainty and anxiety in and among participants. However, all face-off actions
demand boldness and courage, and we must take into account that our behavior may influence our counterparts to perceive us as less trustworthy. Another question is whether it was the developer-side that held the key to the initiative of inquiring practice.
Addressing the first question, we acknowledge that West Bank openly expressed that it was looking for a complete FX-system and that it would not buy a turn-key delivery.
Yet, we maintain that the possibility for succeeding with an inquiring approach depends on the perspective taken by the counterpart, whether that be a developer or a user.
Therefore, if West Bank had responded positively to an inquiring approach taken by Unique, we submit that the firm would have succeeded with this approach.
So, why did an inquiring approach not develop earlier on? Of course, the developers were quite street-wise in the initial phases, but on the other hand, the users did not act intelligently. They did not pose critical questions, and thereby they did not insist on engaging in an inquiring practice. In a Socratic dialogue perspective, neither the developers nor the users took responsibility for their own organization. We thus maintain that inquiring practice is always a two-way responsibility, which however might be provoked by one of the involved parties. Every stage must include inquiry, reflection, and active listening, with active listening including both listening to the counterpart and, perhaps even more important, listening to oneself.
Until now, we have argued for the Socratic dialogue method, but little has been said about how to initiate this method. From an information systems development point of view, we believe that the initiative must come from the developer-side, and in a sales context, it is probably the seller who has the greatest interest in implementing this kind of dialogue.
We are aware of the problems arising when one party explicitly tries to introduce a philosophical tool in this situation, mainly, because tradition and norms tells us that this is not the way of conducting business. Therefore, we suggest that the developer-side initiates this in a manner that tells the user-side that it is important to open up ones basic thoughts and values without experiencing that these issues are too simple to highlight.
Hence, the developer-side must state early on an example that is in line with the Socratic dialogue method.