Proceedings of STPIS'18 Socio-technical design in the wild – A report of the STPIS 2017 business case and its aftermath Alexander Nolte1,2, Dörte Hahn3, and Thomas Herrmann4 1 University of Tartu, Estonia 2 Carnegie Mellon University, Pittsburgh PA, USA 3 Projektmanager, Dortmund, Germany 4 Ruhr-University Bochum, Germany alexander.nolte@ut.ee doehahn@googlemail.com thomas.herrmann@rub.de Abstract. This paper presents a business case that was presented and discussed during the 3rd International Workshop on Socio-Technical Perspective in IS de- velopment (STPIS'17). We will analyze the case and summarize the discussions at the workshop including problems the participants identified and solutions they proposed. We found that both the participants of the workshop and the presenter benefitted from the insights gained during discussions at the workshop. The pre- senter experienced a change of her perspective and increased motivation to pro- pose changes at the company. We also conducted and analyzed three follow-up interviews with the presenter of the case as well as her/his manager uncovering that almost none of the proposed changes had been implemented. Based on the results of the analysis we propose three changes to the format of the business case at the workshop in order to facilitate discussions at the workshop and to provide a stronger impulse for follow-up discussions at the company. Keywords: socio-technical, exploratory, experience report. 1 Introduction The 3rd International Workshop on Socio-Technical Perspective in IS development (STPIS'17) which took place in Essen on June 17, 2017 featured a new format. During the workshop, the participants were faced with a real-world case presented by a repre- sentative from a mid-sized German IT company. The case focused on the proposal management department of this company that is responsible for writing project pro- posals based on calls by companies or by government agencies. It thus operates at the intersection between multiple departments within the company, gathering information from different disciplines related to economics, technical fields such as computer sci- ence and others and compiling them into a proposal. This requires frequent communi- cation between the proposal management department and on-site as well as off-site ex- perts. The exchange happens both face-to-face as well as through technology. Technol- ogy also serves as a means to access archived material - e.g. about earlier proposals. Edited by S. Kowalski, P. Bednar and I. Bider 1 Proceedings of STPIS'18 The case thus serves a suitable example for a complex socio-technical system in that successful proposal management requires frequent interaction between people and technological infrastructure in the workplaces [1–5]. During the workshop, the participants were asked to apply their respective back- ground and expertise to analyze the presented case from a socio-technical perspective, identify potential issues and provide suggestions for improvement. The participants came up with a large variety of different suggestions that were intensely discussed and well received by the representative of the company. In the aftermath of the workshop, we conducted interviews with the presenter as well as the manager that is responsible for this particular case at the company. Our results indicate that some suggestions are still under consideration by the company but so far, no changes to the process have been made. Based on the insights gained through the presentation and discussion at the work- shop as well as the follow-up interviews we make an attempt at identifying means to come up with change proposals that will have a stronger impulse for change in this particular case. The remainder of the paper is structured as follows: We will start by describing the case as it was presented to the participants of the workshop. We will then report on the subsequent discussion and the suggestions that were reported at the company. After- wards we will describe the interviews that were conducted three, four and five months after the workshop as well as results of their analysis before discussing potential reasons for why no changes have been made so far based on the suggestions. The paper closes with a reflection of the findings and suggestions on how to move forward from here. 2 The case The presented case focused on the daily operations of the proposal management depart- ment in a mid-sized German IT company which specializes in customizing IT solutions for corporations as well as public services. The main responsibility of this department is to oversee the process of writing proposals for potential future projects. They are also responsible for putting the proposal together and make sure that it fits the call. This particularly includes formal criteria such as the structure of the actual document, sup- porting material and signing. This department was originally established to ensure that deadlines for submitting proposals could be met and to take over as much of the pro- posal writing work from the developer and consultants as possible since they work full time in customer projects and have no time budget and not the competences needed to write competitive proposals for future projects. The proposal process is divided into three main phases. 1. Pre-bid-decision: It is usually initiated by the sales department or by external con- sultants and developers who find an opportunity to participate in an open call. Af- terwards an employee of the proposal management department is assigned as pro- posal manager. The assignment is mainly based on availability and if possible on the fit of the proposal to the expertise of the proposal manager. The proposal manager then gathers information about the call from the person that initiated the proposal as well as additional information from the sales department. Based on this information, ©Copyright held by the author(s) 2 Proceedings of STPIS'18 the proposal manager creates a document that is forwarded to the leader of the busi- ness line that will carry out the project in the case the proposal is accepted. Based on this document the leader of the business line decides whether or not the company will continue with the proposal and submit a bid. A positive decision to participate in the proposal triggers the second phase. 2. Pre-kick-off: The second phase starts with the proposal manager creating a shared document based on the information given by the initiator of the proposal as well as information in the call. Since proposal requirements are never totally the same, each proposal document has to be set up manually. The proposal manager also creates entries for the proposal in other systems. Afterwards s/he gets in contact with indi- viduals that cover the required expertise to write this specific proposal, makes sure that everyone can access and modify the proposal document and plans a kick-off meeting. This kick-off meeting is usually held virtually since consultants and devel- opers usually work at a customer site. Depending on the proposal, the involved de- partments can be marketing and sales, human resources, controlling, legal in addition to consultants and developers. The kick-off meeting marks the end of the second phase. 3. Proposal writing: The actual writing of the proposal takes place during the third phase. The proposal usually is written in two iterations with two separated deadlines. The proposal manager keeps track of those deadlines. During this phase all involved parties jointly edit the previously created shared proposal document. The proposal manager attempts to contribute as much of the required text as possible and tries to re-use existing text from archived proposals. While writing s/he is largely dependent on information and input from experts in particular about technical details and char- acteristics of the customer. Before the proposal can be submitted, the proposal man- ager has to ensure that all the required information is in the document, that the nec- essary additional information such as signatures by superiors and profiles by pro- jected project participants has been included and that the document in general fits the call. After the document is complete the proposal is submitted. Before participating in the workshop, the presenter had already identified multiple problems within each of the three aforementioned phases. The main perceived problems within each phase are: • Pre-bid-decision: The decision to participate in the call comes too late or is not taken based on the provided information. • Pre-kick-off: Manual document setup is error prone and the failure to set up the doc- ument in the required way can result in desk rejection. • Proposal writing: Re-using text can be dangerous because proposals are almost never exactly the same and thus requires different information. In addition, it is sometimes hard to get required information e.g. about technical specifications in time. Edited by S. Kowalski, P. Bednar and I. Bider 3 Proceedings of STPIS'18 3 The workshop After the presentation of the case which took about 25 minutes, the participants asked clarifying questions about the case. During this phase - which lasted for another 30 minutes - the focus quickly shifted away from the previously described problems (sec- tion 2) towards those that “keep the presenter up at night” - as one participant put it. Based on the discussion the participants identified the following five main problem areas: 1. Lack of focus: The current goal seems to be to submit as many project proposals as possible. This however seems to put an additional strain not only on the proposal management department but also on the developers that have very limited to re- sources contribute to proposal writing anyways. 2. Lack of metrics: The only metric that is systematically calculated and distributed to the employees in the proposal management department is the number of successfully submitted proposals. Based on this metric it is neither possible to assess the costs of writing a proposal nor to assess the current success rate because the number of re- jections is not systematically assessed. The cost factor in particular however is cru- cial since there are a number of hidden costs involved such as personnel costs for all employees that contribute to the proposal. 3. Lack of feedback and reflection: After proposals are submitted there is limited to no discussion about the process and about ways to potentially improve it. Proposals are only discussed in retrospect if they are very large or if there was a major communi- cation breakdown during its creation. Moreover, information about whether or not a proposal was successful is oftentimes not spread and does not reach the proposal manager. 4. Lack of incentives for developers: Developers are understandably completely fo- cused on customer projects and perceive work on project proposals as an addition to their full-time work. This sometimes leads to a situation where the proposal manager has to take multiple escalation steps to acquire the necessary information. There is thus a lack of incentives for developers to contribute to project proposals. 5. Lack of well-defined processes: While there is some form of process documentation and while the process seems to be neatly divided into the three aforementioned phases, there are a lot of deviations during its everyday execution. One example for such a deviation is that the decision to participate or to not participate in a call of- tentimes comes after work on a proposal has already begun. Furthermore, it is often not clear how the decision to participate or to not participate has been reached which causes frustration especially when work on the proposal had already begun. After this plenary discussion the workshop participants split into two groups of five and discussed about approaches to address the aforementioned problems. The discussion lasted for about 30 minutes. Afterwards each group had 15 minutes to present their respective solution. They came up with two similar approaches that generally focused on the same aspects. We will thus outline the results of their presentation as one: ©Copyright held by the author(s) 4 Proceedings of STPIS'18 The suggested approach builds on ensuring for the proposal manager to get sufficient support by technical experts. This requires a shift away from current policy in that de- velopers have to be able to take time off of their actual work on a customer project and invest this time to support project proposals. It has to be realized that this approach is a step back from the initial reasons for establishing the proposal management unit as a consequence of the lacking willingness and resources of the technical experts to focus on proposal submission. Such a fundamental shift in the company’s policy however cannot be brought to reality by the proposal manager or the proposal management department. It rather re- quires support by top-management. In order to assure this support, it is necessary to demonstrate that the current approach is wasting resources by focusing on creating as many project proposals as possible instead of establishing a process of priority driven bidding. This in turn requires a thorough assessment of the costs that are associated with drafting a proposal. Particularly, the question of how much an unsuccessful pro- posal costs the company has to be answered since under the current practice, costs are not assessed implying that unsuccessful proposals do not cause a recognizable loss. Furthermore, the workshop participants suggested that it might be useful to specifi- cally target those developers as supporters who could directly benefit from a successful project proposal. Examples are developers that are on a project that will end soon or developers who want to continue working with a specific customer for whom the pro- posal will be written. For some proposals this is already the case but not for all. In addition, the workshop participants proposed to use aforementioned metrics as one part of periodical feedback for proposal managers. The feedback should however not be limited to the metrics alone. It should also include discussions about past expe- riences with successful as well as unsuccessful proposals with the aim to continuously improve the existing proposal development process. The final suggestion was to pilot the metrics in one line of business in order to see how feasible they are. The tracking can subsequently be extended towards other lines of business and can be combined with test cases where e.g. developer get time resources to work on proposal documents. The follow-up discussion to the aforementioned proposals also revealed a large po- tential for frustration on the part of the proposal manager due to the perceived lack of support by other departments. This becomes particularly obvious in the relationship between the proposal manager and the developers. Developers oftentimes mention that they will work on the proposal on the weekend because they literally have no time to work on it during working hours because they have to invest all of their time in cus- tomer projects. This leaves the proposal manager with the dilemma to have to ask for this “favor” in order to do her/his job which adds to the existing emotional stress. 4 The aftermath In order to assess how the suggestions were received by the company we conducted three separate interviews. The interviews took place three, four and five months after Edited by S. Kowalski, P. Bednar and I. Bider 5 Proceedings of STPIS'18 the original discussion during the workshop. The first and third interview were con- ducted with the employee of the proposal management department that presented the case at the workshop (I1). The second interview was conducted with the manager of the proposal management department (I2). We did not interview other members of the proposal management department or other employees of the company since discussions about the proposals from the workshop were limited between the two mentioned indi- viduals. The interviews lasted between 30 and 60 minutes and focused on the following aspects: • Individual expectations about outcomes of the workshop. • Individual views on the suggestions made by the workshop participants. • Current and future plans with respect to the suggestions including potential difficul- ties concerning their implementation. In the following we will report on each interview individually. 4.1 Interview 1 During this interview I1 reported that s/he had had multiple conversations with I2 about the suggestions s/he received during the workshop. During the first conversation which only lasted for a couple of minutes, I2 asked her/him to create a list of suggestions based on the insights from the workshop and to schedule another meeting to discuss them in detail (“s/he asked me to write the suggestions down”1, I1). During this follow-up meet- ing I2 mentioned that s/he cannot take the decision for most of the suggestions and that decisions like these “have to be taken higher up the organizational food chain” (I2 reported by I1). I2 particularly cited strategic decisions about focusing on more pro- posals or focusing on targeted proposals are decisions that cannot be taken by the pro- posal management department alone. I1 reported that s/he generally found it hard to transport the suggestions from the workshop because “I don't have any power to decide anything” (I1). S/he did also not receive support by her/his fellow colleagues because discussions about the suggestions from the workshop were limited to 1on1 meetings between I1 and I2. There was no structured attempt to e.g. put the suggestions on the agenda of a team meeting. The only way to spread the suggestions were informal meetings between I1 and fellow employ- ees of the proposal management department during breaks. During those informal meet- ings other employees have not expressed particular interest in supporting the sugges- tions made by I1 or to indeed change anything about the work environment. I1 stated that “there is almost no dialogue between colleagues” (I1) and moreover that within the department “there is little collaboration despite people working on the same things” (I1). As a potential reason for the perceived resistance to change, I1 cited that “in the past, proposals by employees have not been received well” (I1). This can serve as one aspect to explain the apparent resistance to change within the department. Being asked about how s/he perceived the workshop and the suggestions of the par- ticipants, I1 reported that s/he was surprised by the depth and “critical reflection from 1 All quotes were translated into English because the interviews were conducted in German. ©Copyright held by the author(s) 6 Proceedings of STPIS'18 workshop participants about [her/his] work” (I1). Her/his expectations prior to the workshop were rather “pragmatic approaches” (I1) and not an in-depth critical assess- ment of the process. I1 also stated that workshop changed her/his perspective on the process in that “more is not always better” (I1). S/he did however also admit that “pro- cess is not in [her/his] hand” (I1) but that the workshop sparked the desire to “analyze the process more and understand more about the technical aspects of proposals” (I1). I1 mentioned that s/he had attempted to participate in developer meetings before but that the increasing workload prevented her/him to do so on a regular basis. 4.2 Interview 2 One month after the first interview we conducted a follow-up interview with the leader of the proposal management department (I2) to capture her/his perspective on the sug- gestions and her/his potential plans to assess and implement them. This interview took place after the second meeting between I1 and I2. During the interview it became ap- parent that I2 did not see the necessity to change the current proposal writing process. I2 mentioned that in her/his view the “process works as intended” (I2). S/he also pointed out that the process has “recently been analyzed and restructured” (I2). This analysis had taken place about three years prior and was supported by an external con- sulting company. I2 also pointed out that the proposal management department in gen- eral and s/he in particular has received a lot of positive feedback about the process e.g. at a “large international conference” during which “I presented the process to 800 people” (I2). In addition, I2 also mentioned that s/he perceived the suggestions to be “too much and too far reaching” (I2) citing that most of them cannot be implemented by the pro- posal management department alone thus confirming the assessment of I1 in the previ- ous interview. In particular the suggestion to split proposals into different categories to be able to distribute them to proposal managers based on their expertise was seen as not being very realistic (“others tried it and failed”, I2). I2 did however see the potential benefit of tracking additional metrics in order to be able to assess the costs as well as the profits of the proposal management department as such. S/he mentioned to have been in contact with the controlling department to “track numbers in one business area” (I2). The proposed small business area should thus serve as a testing ground to track different metrics for a certain period of time. Results of the tracking would then be discussed between I2 and “my managers” (I2). The suggestions are generally “not high on the priority list” (I2) but I2 stated the willingness to start tracking aforementioned metrics “next year” (I2). S/he also pro- posed during the interview to utilize the metrics as part of annual performance talks with employees of the proposal management department. Up until the point of the in- terview there has been no presentation or discussion about the suggested changes with any other employee of the proposal management department apart from I1. Edited by S. Kowalski, P. Bednar and I. Bider 7 Proceedings of STPIS'18 4.3 Interview 3 Another month after the second interview we again got in contact with the employee of the proposal management department that presented the case at the workshop (I1) to ask for what had happened in the meantime and whether there was any progress. S/he told us during the time between the two interviews there has been no actual progress towards implementing any of the measures s/he proposed during the first meeting with I2. I1 reported that in the meantime I2 asked her/him to identify suitable metrics to assess the performance of the proposal management department and the costs con- nected to proposal creation. Despite not being given suitable additional resources e.g. in the form of expert advice from individuals in the controlling department (“I have no controlling experience”, I1), I1 created a proposal that s/he discussed during another meeting with I2 that took place a few days prior to this interview. During the discussion I2 proposed that I1 should start tracking “some of the numbers manually” (I1) and report back to her/him after a certain period of time. I1 was notably frustrated about this proposal since s/he was not sure “if I can even track those numbers manually” (I1) and that “I did not get time to do this” (I1). The suggestion to manually track the numbers as well as the fact that s/he will not be given additional time to perform the required tracking led I1 to assume that I2 is not supportive of change. This assumption got reaffirmed during the meeting when I2 reit- erated that s/he does perceive the proposal writing process to be ok and that in order to change it s/he has to ask for permission by her/his manager. I2 however also stated the s/he thinks that “tracking these numbers might be beneficial” (I2 reported by I1) and a “good starting point” (I2 reported by I1). This indicates that I2 is not particularly sup- portive of the suggested changes but that s/he might be convinced based on the results of the aforementioned tracking of certain metrics. I1 also mentioned again a perceived lack of support by fellow colleagues (“they are ok but not enthusiastic about them”, I1). S/he however also mentioned that there still has been no chance for her/him to present the suggestions to the group. Exchanges on the topic remained “informal during coffee breaks” (I1). I1 also reiterated her/his as- sumption from the first interview that “there are problems in the department that no one talks about” (I1) and that there is a “high fluctuation of people” (I1). It is thus unlikely that the suggestions will receive support by the other employees in the proposal management department even if they get the chance to discuss them. 5 Discussion Based on the previous description of the case (section 3) and its aftermath (section 4), we will discuss the described results from two perspectives with the aim to inform fu- ture iterations of a similar format at upcoming workshops: The impact of the sugges- tions made by the workshop participants on the case (section 5.1) and the perceptions of both the workshop participants and the individual that presented the case (section 5.2). Based on the insights gained we will propose changes to the format the might facilitate the transition of the insights gained at the workshop into company practice (section 5.3). ©Copyright held by the author(s) 8 Proceedings of STPIS'18 5.1 Impact of suggestions on the company The analysis revealed that the impact of the suggestions on the company in general and the proposal management department in particular are rather minimal. While there have been discussions about starting to capture some metrics, these discussions remained between the presenter and the leader of the proposal management department and no follow-up activities have been planned yet. The fact that there has been no attempt to implement any of the changes or to discuss them outside of face-to-face meetings be- tween I1 and I2 led us to search for potential reasons. One contributing factor certainly was the perception of the leader of the proposal management department that the pro- cess was working as intended and that there is no need for change. This led to a lack of support by her/him which potentially affected her/his willingness to provide resources for deeper investigation and for supporting the presenter to spread the news about the suggested changes beyond the confines of their face-to-face meetings. The leader of the proposal management department however showed interest in tracking certain metrics in order to discuss them with her/his superiors. This provides an indication for interest to implement changes that benefit the perception of the department within the company. It also appeared as if the majority of the proposed changes was perceived as being too far reaching. They were perceived to require major changes outside of the proposal management department which would require support by decision makers on a higher organizational level. Most of these changes were never considered and the main focus shifted to metrics that should be tracked manually within the proposal management department. Another potential reason for the lack of implementation of the proposed changes was the lack of support for any form of change by the presenter’s fellow colleagues. We uncovered multiple potential reasons for this lack of support. One potential reason is that the proposals by the workshop participants were never officially presented or dis- cussed in a team setting. The only time the proposals were discussed was during infor- mal meetings such as coffee breaks. Another potential reason for the lack of support is the perceived high fluctuation of employees within the department. This could contrib- ute to a climate where change is not perceived as necessary. This climate might be emphasized by the dismissal of previous proposals by employees within the depart- ment. The presented case in general represents a somewhat typical example of an organi- zation where that is highly dependent on customer projects. These projects bind all the resources of the personnel working in those projects thus leaving no time for them to support the acquisition of future projects. They do however constantly need to acquire new projects in order for the company to continue their business strategy. The resulting dilemma becomes even more prevalent in this case since the expertise of those employ- ees working in customer projects is crucial for the success of project proposals and cannot be subsidized otherwise. It is thus surprising that the apparent shortcomings of the current approach are not recognized. As a consequence, it appears more reasonable for similar cases to start with suggestions for incremental improvement considering fine-grained aspects of the interplay between technology and human activities instead of aiming on fundamental changes. Before a company can be convinced to change its Edited by S. Kowalski, P. Bednar and I. Bider 9 Proceedings of STPIS'18 priorities, it has to understand that the potentials for incremental improvement of its processes have been completely exhausted. 5.2 Perception of stakeholders on the format The format was well received by the presenter as well as the other workshop partici- pants. Both sides stated that they enjoyed working on the case and the presenter reported that the presentation and the following discussions allowed her/him to see the process from a different perspective. This change of perspective also convinced her/him about the necessity for changes and motivated her/him to reflect on the proposed changes and come up with a list of aspects that s/he would like to be implemented. Despite being left on her/his own and having to invest additional time next to her demanding everyday work, s/he still pursued the attempt to implement some of the proposed changes. This indicates that s/he was committed to support the change even after it had proven to be a difficult if not impossible task. On an individual level it can thus be stated that the discussion of the business case can be considered a success since it served both as a suitable exercise during the workshop and as a source of motivation for the presenter to attempt change. 5.3 Proposals to change the format The feedback of both the presenter as well as the participants at the workshop were overwhelmingly positive. People were excited to discuss about a practical case and the problems that the participants identified as well as the solutions they presented appeared to have had a profound impact on the presenter. It thus appears that the format does not require changes on that level. There are however some challenges to be overcome re- lated to the applicability of the changes as well as their general potential to spark a willingness to consider follow-up discussions and the potential implementation of change at the company. We do not want to pretend that one workshop during which one representative of a department presents a case can change the work practice of an entire department. We do however believe that some changes to the workshop format could provide a stronger impulse to discuss about the current situation at the department from a socio-technical perspective which might in turn lead to change. In particular we would propose the following changes to the format: • Keep it practical: The execution of most of the suggestions were outside of the scope of what the proposal management department could handle. While the overall pic- ture certainly is valuable and should be neglected, the workshop participants might also want to include practical changes that can be applied directly and that have a direct visible effect. • Produce some variety: Since the workshop participants have different approaches and perspectives on how socio-technical improvement and solutions of a practical problem should look like, it appears reasonable to use those approaches to discuss the presented case from multiple perspectives. This could lead to a larger variety of proposals which might spark more follow-up discussions at the company. It might ©Copyright held by the author(s) 10 Proceedings of STPIS'18 also enliven discussions at the workshop because it allows participants to focus on demonstrating how their different views can be explained with respect to the same practical case. • Show them how: The workshop participants proposed an overall deployment strategy that covered all involved departments and stakeholders. They did however not focus on how to communicate the strategy internally and how to gather support for the proposed changes especially within the department. Similarly, to the first point it might thus be beneficial if the workshop participants could focus more on the details of the deployment strategy especially for the first changes within the department. • Ask them to bring a friend: One of the major challenges that were revealed was that the presenter had to be the lone messenger for the changes proposed at the workshop. Despite her/him being convinced about the feasibility of the proposed changes and being motivated to spread the message and implement at least some of the changes, s/he failed to gather support. Bringing a second person to the workshop might not solve the problem but it might help to spark follow-up discussion at the company which go beyond 1on1 meetings. It might also enrich the discussion at the workshop since it allows participants to discuss problems and solution proposals based on two different perspectives. 6 Conclusion During the course of this paper we presented a report on the business case that was presented and discussed during the 3rd International Workshop on Socio-Technical Per- spective in IS development (STPIS'17) in Essen, Germany. Our analysis of the work- shop itself and three follow-up-interviews that took place after the workshop revealed that participating in the workshop changed the perspective of the presenter on the pro- cess. We did however also find that almost none of the proposed changes had been implemented mainly due to a lack of support and due to the necessity for most changes to be implemented outside of the confines of the department that the presented repre- sented at the workshop. Based on these insights we proposed for the next workshop to focus more on the different socio-technical approaches that are pursued by the work- shop participants and to up with a larger variety of practically applicable changes as well as approaches on how to implement them. Such an elaboration of differences be- tween certain approaches seems to be more promising with respect to not only making the workshop a more interesting experience but also with respect to the potential fol- low-up discussions at the company. Acknowledgements We would like to thank both representatives from the company as well as all partici- pants of the STPIS workshop in 2017 for their valuable time and input. Edited by S. Kowalski, P. Bednar and I. Bider 11 Proceedings of STPIS'18 References 1. Cherns, A.: Principles of Sociotechnical Design Revisted. Hum. Relat. 40, 3, 153– 162 (1987). 2. Eason, K.: Information Technology and Organisational Change. Taylor and Francis, London (1988). 3. Herrmann, T.: Systems Design with the Socio-Technical Walkthrough. In: Whit- worth, B. and de Moor, A. (eds.) Handbook of Research on Socio-Technical Design and Social Networking Systems. Information Science Reference (2009). 4. Mumford, E.: The story of socio-technical design: reflections on its successes, fail- ures and potential. Inf. Syst. J. 16, 4, 317–342 (2006). 5. Trist, E., Bamforth, K.: Some social and psychological consequences of the long wall method of coal getting. Hum. Relat. 4, 3–38 (1951). ©Copyright held by the author(s) 12