<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Socio-technical design in the wild - A report of the STPIS 2017 business case and its aftermath</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Alexander Nolte</string-name>
          <email>alexander.nolte@ut.ee</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff3">3</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Dörte Hahn</string-name>
          <email>doehahn@googlemail.com</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Thomas Herrmann</string-name>
          <email>thomas.herrmann@rub.de</email>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Carnegie Mellon University</institution>
          ,
          <addr-line>Pittsburgh PA</addr-line>
          ,
          <country country="US">USA</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Projektmanager</institution>
          ,
          <addr-line>Dortmund</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>Ruhr-University Bochum</institution>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff3">
          <label>3</label>
          <institution>University of Tartu</institution>
          ,
          <country country="EE">Estonia</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>This paper presents a business case that was presented and discussed during the 3rd International Workshop on Socio-Technical Perspective in IS development (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 presenter experienced a change of her perspective and increased motivation to propose 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.</p>
      </abstract>
      <kwd-group>
        <kwd>socio-technical</kwd>
        <kwd>exploratory</kwd>
        <kwd>experience report</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        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
representative from a mid-sized German IT company. The case focused on the proposal
management department of this company that is responsible for writing project
proposals 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
science and others and compiling them into a proposal. This requires frequent
communication between the proposal management department and on-site as well as off-site
experts. The exchange happens both face-to-face as well as through technology.
Technology also serves as a means to access archived material - e.g. about earlier proposals.
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 [
        <xref ref-type="bibr" rid="ref1 ref2 ref3 ref4 ref5">1–5</xref>
        ].
      </p>
      <p>During the workshop, the participants were asked to apply their respective
background 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
workshop 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.</p>
      <p>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.
Afterwards 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</p>
    </sec>
    <sec id="sec-2">
      <title>The case</title>
      <p>The presented case focused on the daily operations of the proposal management
department 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,
supporting 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
proposal 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.</p>
      <p>The proposal process is divided into three main phases.
1. Pre-bid-decision: It is usually initiated by the sales department or by external
consultants and developers who find an opportunity to participate in an open call.
Afterwards an employee of the proposal management department is assigned as
proposal 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,
the proposal manager creates a document that is forwarded to the leader of the
business 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
individuals 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
developers usually work at a customer site. Depending on the proposal, the involved
departments 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
characteristics of the customer. Before the proposal can be submitted, the proposal
manager has to ensure that all the required information is in the document, that the
necessary additional information such as signatures by superiors and profiles by
projected project participants has been included and that the document in general fits
the call. After the document is complete the proposal is submitted.</p>
      <p>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
document 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.
3</p>
    </sec>
    <sec id="sec-3">
      <title>The workshop</title>
      <p>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
(section 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
resources 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
rejections is not systematically assessed. The cost factor in particular however is
crucial 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
communication 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
focused 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
oftentimes 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:</p>
      <p>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
developers 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.</p>
      <p>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
requires 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
proposal 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.</p>
      <p>Furthermore, the workshop participants suggested that it might be useful to
specifically 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
proposal will be written. For some proposals this is already the case but not for all.</p>
      <p>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
experiences with successful as well as unsuccessful proposals with the aim to continuously
improve the existing proposal development process.</p>
      <p>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.</p>
      <p>The follow-up discussion to the aforementioned proposals also revealed a large
potential 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
customer 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</p>
    </sec>
    <sec id="sec-4">
      <title>The aftermath</title>
      <p>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
the original discussion during the workshop. The first and third interview were
conducted 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
individuals. 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
difficulties concerning their implementation.</p>
      <p>In the following we will report on each interview individually.
4.1</p>
      <sec id="sec-4-1">
        <title>Interview 1</title>
        <p>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
meeting 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
proposals or focusing on targeted proposals are decisions that cannot be taken by the
proposal management department alone.</p>
        <p>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
employees of the proposal management department during breaks. During those informal
meetings other employees have not expressed particular interest in supporting the
suggestions 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.</p>
        <p>Being asked about how s/he perceived the workshop and the suggestions of the
participants, 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.
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
assessment 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
“process 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</p>
      </sec>
      <sec id="sec-4-2">
        <title>Interview 2</title>
        <p>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
suggestions 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
apparent 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
consulting company. I2 also pointed out that the proposal management department in
general 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).</p>
        <p>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
proposal management department alone thus confirming the assessment of I1 in the
previous 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).</p>
        <p>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).</p>
        <p>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
proposed 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
interview there has been no presentation or discussion about the suggested changes with
any other employee of the proposal management department apart from I1.
4.3</p>
      </sec>
      <sec id="sec-4-3">
        <title>Interview 3</title>
        <p>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
connected 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).</p>
        <p>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
reiterated 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
supportive of the suggested changes but that s/he might be convinced based on the results
of the aforementioned tracking of certain metrics.</p>
        <p>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
assumption 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</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Discussion</title>
      <p>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
future iterations of a similar format at upcoming workshops: The impact of the
suggestions 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).
5.1</p>
      <sec id="sec-5-1">
        <title>Impact of suggestions on the company</title>
        <p>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
between 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
process 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.</p>
        <p>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.</p>
        <p>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
discussed in a team setting. The only time the proposals were discussed was during
informal 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
contribute 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
department.</p>
        <p>The presented case in general represents a somewhat typical example of an
organization 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
employees 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
priorities, it has to understand that the potentials for incremental improvement of its
processes have been completely exhausted.
5.2</p>
      </sec>
      <sec id="sec-5-2">
        <title>Perception of stakeholders on the format</title>
        <p>The format was well received by the presenter as well as the other workshop
participants. 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</p>
      </sec>
      <sec id="sec-5-3">
        <title>Proposals to change the format</title>
        <p>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
related 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
picture 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
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</p>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>Conclusion</title>
      <p>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
Perspective in IS development (STPIS'17) in Essen, Germany. Our analysis of the
workshop 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
process. 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
represented 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
workshop 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
between 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
follow-up discussions at the company.</p>
      <sec id="sec-6-1">
        <title>Acknowledgements</title>
        <p>We would like to thank both representatives from the company as well as all
participants of the STPIS workshop in 2017 for their valuable time and input.</p>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Cherns</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Principles of Sociotechnical Design Revisted</article-title>
          .
          <source>Hum. Relat</source>
          .
          <volume>40</volume>
          ,
          <issue>3</issue>
          ,
          <fpage>153</fpage>
          -
          <lpage>162</lpage>
          (
          <year>1987</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Eason</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          : Information Technology and
          <string-name>
            <given-names>Organisational</given-names>
            <surname>Change</surname>
          </string-name>
          . Taylor and Francis, London (
          <year>1988</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Herrmann</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          :
          <article-title>Systems Design with the Socio-Technical Walkthrough</article-title>
          . In: Whitworth,
          <string-name>
            <given-names>B.</given-names>
            and
            <surname>de Moor</surname>
          </string-name>
          ,
          <string-name>
            <surname>A</surname>
          </string-name>
          . (eds.)
          <source>Handbook of Research on Socio-Technical Design and Social Networking Systems. Information Science Reference</source>
          (
          <year>2009</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Mumford</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          :
          <article-title>The story of socio-technical design: reflections on its successes, failures and potential</article-title>
          .
          <source>Inf. Syst. J</source>
          .
          <volume>16</volume>
          ,
          <issue>4</issue>
          ,
          <fpage>317</fpage>
          -
          <lpage>342</lpage>
          (
          <year>2006</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Trist</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bamforth</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Some social and psychological consequences of the long wall method of coal getting</article-title>
          .
          <source>Hum. Relat. 4</source>
          ,
          <fpage>3</fpage>
          -
          <lpage>38</lpage>
          (
          <year>1951</year>
          ).
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>