Keywords

1 Introduction

As a direct consequence of the technological developments of the last 10 years, internal crowdsourcing (IC) represents a new, digital form of internal knowledge networking and cross-functional collaboration. IC means that employees of a company (the crowd) generate ideas and solutions that contribute to the improvement of existing products, processes and services or their new developments (innovations) in exchange via a digital platform. This makes IC both a tool for innovation management and employee participation and at the same time an implementation method.

In various forms and with different designations, the digitally mediated process has meanwhile established itself in numerous companies in Germany (Pohlisch 2019). Regardless of the form in which internal crowdsourcing is used in a company, the role model is essential for the practical implementation in all cases. Together with the IC Process and the technical solution, the so-called Crowd Technology Architecture (CTA), it forms the ICU System (see Wedel and Ulbrich, chapter ‘Managing the Crowd: A Literature Review of Empirical Studies on Internal Crowdsourcing’ in this book). It describes the division of responsibilities for the different process levels and process components of the individual process phases, as well as the associated steering tasks. The role model also specifies what support from other areas of the company is required for successful execution. As part of the research project ‘ICU—Internal Crowdsourcing in Companies’, such a role model has been realized on the basis of a prototypical application of IC.

The aim of ICU is to develop a cross-industry reference model for Good Practice in internal crowdsourcing with a focus on employee-friendly design of the application. The so-called ICU Model consists of a process strategy addressing the dimensions of innovation management, employee participation as well as employee qualification and an ICU Platform. In their role of industry partner in the ICU Project, the GASAG AG, an energy service provider based in Berlin, Germany, applied that model in its own company. The model development took place in stages: first a basic model was realized and tested as a pilot (first iteration); then the optimized model was revised by GASAG AG and further developed into a Good Practice example (second iteration). The Good Practice Model was then transformed into a cross-industry reference model of IC.

In this article, we will present the main features of the role model that have emerged from the research project. We deliberately based the design of the ICU Role Model on Scrum’s role concepts, because in the light of the ICU pilot phase, we came to a fundamental realization. Partial aspects of the IC Process as well as necessary activities of process control and the principles inscribed in it show parallels to the procedure, principles and the task descriptions of the agile method Scrum. Therefore, Scrum had an exemplary character for us in developing a functional and differentiated ICU Role Model. In order to better understand the presentation of our ICU Role Model, first we will examine the IC Process with regard to its characteristics and then highlight the existing similarities between IC and Scrum. On this basis, we will then derive and describe in detail the ICU Role Model in discussion with the Scrum role approach.

2 Process Design of Internal Crowdsourcing in ICU

Scrum, especially used for agile software development, has never been considered from a process perspective because its developers Ken Schwaber and Jeff Sutherland described it as a method or better as:

A framework within which people can tackle complex adaptive tasks consisting of Scrum Teams and their associated roles [Scrum Master, Product Owner, Development Team], Events [Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective], Artifacts [Product Backlog] and Rules [Principles, Values]. The rules [...] define relationships and interactions between roles, events and artifacts. (Schwaber and Sutherland 2017)

However, the aforementioned elements of the framework structure the working activities in a certain way and thus, despite the freedom of design of the individual elements in terms of content, provide a predefined workflow. Using the definition of Petersen et al., which describes a process as a series of activities carried out by all participants to achieve a particular result or solve a particular problem (Pedersen et al. 2013, p. 581), it is safe to say that Scrum can be classified as a process.

In contrast, internal crowdsourcing as a technology-based procedure model is referred to either as a method, process or tool, depending on which aspect is put in the foreground. This is due to the different components that make up an ICU System. As explained by Wedel and Ulbrich earlier in this book, there are a number of possibilities for systematizing IC, whereby the postulated concepts, the selection of components and their relationship to one another vary. Our understanding of an ICU System in this article comprises only the three components of ‘activity’ (method), ‘process’ (process) and ‘information technology’ (tool).

In order to be able to explain the deliberately created similarities between IC and Scrum roles, the ‘naturally’ existing similarities between the IC and Scrum processes must be identified first. We will demonstrate this by describing the IC Process developed in ICU, i.e. describing the process phases, process components and process levels, and relating them to the corresponding process elements and the role descriptions of Scrum. Building on this, we describe the ICU Role Model at the end.

2.1 Main Phases and Components of an IC Process

There is a wealth of contributions in research dealing with the description of crowdsourcing processes. Thuan et al. divide these process descriptions, which are primarily aimed at external crowdsourcing, into two categories: studies with analytical approaches of high granularity and studies with analytical approaches of low granularity (Thuan et al. 2017, pp. 4; Thuan 2019, pp. 27).

Those in the high granularity group focus on conceptualization and strive to design the crowdsourcing process as a whole, also to recognize events at the macro level and to bring them into a temporal sequence (establishment of process models and framework conditions). According to Thuan et al., this group includes the works of Brabham (2008), Leimeister et al. (2009), Geiger et al. (2011), Zogaj et al. (2014) and Zogaj et al. (2015). In contrast, the research activities with low granularity are concerned only with partial aspects of the process. They highlight specific components with a focus on the associated workflows at the micro level (definition of tasks and procedures), such as studies on mechanisms of selecting and matching the appropriate target group with the right task like the work of Erickson et al. (2012), Geiger and Schader (2014) and Cullina et al. (2016) or studies on motivation and incentive systems like the work of Andrae (2012), Zhao and Zhu (2014), Machine and Ophoff (2014), Spindeldreher and Schlagwein (2016) and Feng et al. (2018).

Against this background, only the high granularity perspective is relevant for the following description of the IC Process with its process phases and process components, which we have developed in the ICU Project. Since for internal crowdsourcing the number of process-oriented investigations is manageable, we will build on fundamental features of existing process models for crowdsourcing in general (for an in-depth literature overview). In particular, we will use the phased model of Gassmann et al. (2013a, 2017) and supplement the missing steps and linkages. Zuchowski et al. have made a proposal specifically for structuring IC (Zuchowski et al. 2016, p. 169), but it does not close the gaps that we have identified in ICU with regard to the IC Process. Therefore, Zuchowski et al. will not be considered in the further explanations.

Gassman et al. (2013b, 2017, pp. 29) divide the process flow of a crowdsourcing project into five phases, starting with:

  1. 1.

    Preparation: The starting point is that a company has a problem that it wants to solve for itself. The first step is therefore to become clear about the desired result, i.e. what should be achieved and in what way should it be delivered in the end [process component: target definition]Footnote 1. It is also important to clarify who the adequate target group for the task to be worked on is, which platform is suitable and whether it is worthwhile in perspective to build up an own community [process component: community management]. After weighing up these aspects, the basic decision for or against a crowdsourcing project is made.

  2. 2.

    Initiation: Next, the task is published to the crowd on the platform of choice and the idea generation starts. This is preceded by the appropriate preparation of the tasks [process component: task design] and by determining the remuneration [process component: motivation mechanisms/incentive systems].

  3. 3.

    Implementation: The crowdsourcing project is underway, and the first ideas are beginning to develop. These must be communicated to the relevant people in the company, and any resistance that may arise must be addressed and resolved [process component: process monitoring]. The activities of the crowd must also be managed to steer the dynamics in the desired direction.

  4. 4.

    Evaluation: Once the crowdsourcing activities on the platform have been completed, the solutions submitted will be evaluated. At this point it must be clear who is responsible for the evaluation and which criteria are to be applied.

  5. 5.

    Utilization: The final step is to compile the results, so they can be used further or developed and integrated into ongoing business processes [process component: decision]. Idea contributors should be informed about how their ideas will be used further. Sharing this information as an act of transparency contributes to building and maintaining the community [process component: crowd/community management].

As the previous explanations make clear, a process phase is the sum of its individual components, because it is impossible to describe individual process phases without simultaneously describing their process components. As a matter of fact, we define process components as events that occur within a process phase.

In the phased model of Gassmann et al., components were not explicitly pointed out as such. However, highlighting and naming the process components is important in order to be able to better distribute the responsibilities to the roles later on. If you do not have these clearly in mind, the role descriptions will get lost in the maze of individual workflows. Workflows are the action-oriented design of the process components and referred to in ICU as steering tasks. They belong to the ‘activities’ element of an ICU System (see chapter ‘Managing the Crowd: A Literature Review of Empirical Studies on Internal Crowdsourcing’). Steering tasks can vary from company to company, but also over time within a company, as they have to be continuously adapted to the respective framework conditions in place. Process components, on the other hand, are constant in time and for all application contexts.

2.2 ICU Phases and Components

In principle, we were able to build the prototypical ICU Model roughly on the process flow of Gassmann et al. presented above. However, for the special form of internal crowdsourcing, we had to supplement and differentiate the process phases and components as well as rearrange the chronological order.

Our understanding of internal crowdsourcing in the ICU Project is not only about the one-sided mobilization of employees’ knowledge and experience to solve a company’s problems. It is also about striving for internal cooperation and employee participation. That is why the IC Process does not begin with a given problem per se, but rather with a proposal for an existing or prospective issue. With that in mind, the ICU Process is structured as follows:

  1. 1.

    Impetus: Employees from all areas of the company as well as executives, management and employee representatives are entitled to name topics. They submit potential topics either digitally via the ICU Platform or by email or face to face to the responsible department in the company, the so-called crowd team [process component: topic proposal].

    The responsible people in the crowd team, the Campaign Owner and the Crowd Master, filter the incoming proposals according to their relevance for the company. The relevance results from the target goals for internal crowdsourcing set by the management board [process component: probing].

    Then there is a discussion within the crowd team about which department might be interested in one of the topics. The Crowd Master reaches out to the head/key player of the potential department and makes agreements regarding the subject matter and the Content Ownership [process component: exploratory talks]. If an employee approaches the crowd team directly on behalf of a business unit, the steps of a probing and exploratory talks can be omitted.

  2. 2.

    Decision (No/Go): The decision to pursue a topic and to set up a crowdsourcing project, in ICU and hereinafter referred to as a campaign, depends on two conditions: firstly, whether there is a need in one of the company divisions for the results that will be developed on the topic and, secondly, whether a division will take over Content Ownership for it [process component: content ownership]. If no one in the company takes Content Ownership, the campaign cannot be embedded in ongoing activities in a useful way. Nor could the principle of process transparency be guaranteed.

    Process transparency means that the participating employees can clearly understand at any given point in the process, what interest the company/department has in the topic, what are the objectives of the specific campaign and how the efforts of the crowd, i.e. the results, are being utilized.

  3. 3.

    Conceptualization: Once the decision to start a campaign has been made, the campaign team must develop a campaign concept. In doing so, the team must take various aspects into account. In order to productively exploit the potential of the crowd, the Campaign Owner must prepare the topics in a structured and targeted manner, so that the crowd can handle it in a meaningful way and produce usable results.

    First of all, it is therefore necessary to clarify what the aim of the campaign should be. This goes hand in hand with the definition of the expected results to be presented at the end. The Content Owner, together with the Campaign Owner, has to consider in which form the retrieved knowledge should be available at the end of the campaign, for example, as a prototype, a concept draft or a forecast [process component: target definition]. Directly related to this is the definition of the criteria according to which the delivered results are selected [process component: selection of criteria]. This also includes considerations of how the selected results can then be integrated into the Content Owner’s work activities. This depends, of course, on the complexity of the campaign’s objective. In most of the cases, it will be a list of ideas of how to tie in acquired knowledge. The concrete use can only be determined based on the results obtained further on [process component: intention of utilization].

    Furthermore, it must be decided how employees are to be motivated to participate and what incentives are appropriate. According to Palin and Kaartemo (2016, p. 27), there are five factors that influence the extrinsic and intrinsic motivation of employees: (1) well-being in the work environment, (2) incentive system, (3) feedback from superiors and time windows for task dedication, (4) user experience and functionalities of the technology and (5) marketing and communication regarding the process and the platform (goal of site/results of site) (Palin and Kaartemo 2016). In the ICU Project, we were also able to identify these factors through employee surveys and participatory workshops. In our experience, the biggest influencing factor was ‘marketing and communication’. Specifically, process transparency, which enables a comprehensive understanding of the activities on the platform, was of particular importance.

    In conclusion, internal crowdsourcing does not necessarily require extrinsic incentives for employees to participate. Intrinsic motivation is far more important and can be stimulated through open communication and process transparency. Against this background, the process component ‘incentive system’ is closely linked to the process component ‘crowd/community management’ [process component: motivation mechanisms/incentive system].

    The preceding process components provide the prerequisites for developing the task design. The task design is composed of different aspects. These include the description of the task in which the overriding interest is made clear, the goal definition, result definition, possible incentives, selection criteria, possible exploitation of results and the time schedule. It also includes the selection of task types.

    A basic typology of tasks has been introduced by Pohlisch earlier in this book (see chapter ‘Introduction to “Internal Crowdsourcing: Theoretical Foundations and Practical Applications”’). In the ICU Project, we have applied a total of five different types of tasks. These correspond largely to the basic types mentioned by Pohlisch, but we have also integrated other types that we also find frequently in the research literature (Chiu et al. 2014; Leimeister and Zogaj 2013; Zogaj et al. 2015; Brabham 2008; Jaafar and Dahanayake 2015):

    • Crowdstorming—The crowd is called upon to point out facets of content in the set topic and to identify opportunities and challenges. The objective of the call is to explore the issue at hand.

    • Crowdvoting—The crowd is called on to give ratings, votes, opinions or recommendations concerning set topics. The objective of the call is to gather estimations and forecasts.

    • Crowdsolving—The crowd is called upon to develop solutions to problems to benefit the company’s existing services, products and processes. The objective of the call is to optimize the portfolio offer.

    • Crowdcreation—The crowd is called on to create new ideas and concepts for products, services and processes. The objective of the call is to generate innovation.

    • Crowdtesting—The crowd is used to test prototypes for services, products and processes with regard to usability and user experience. The objective of the call is to obtain constructive feedback and suggestions for improvement.

  • Depending on the overall objective of the campaign, task types can be selected as independently implemented measures, so-called standalones. But more often, the campaign team chooses a task combination according to the mix & match principle. This combination of different types of tasks enables a multistage, iterative development of results by continuously increasing the degree of complexity in the activity required of the crowd. The mix & match principle is depicted in Fig. 1 [process component: task design].

  • The success of a campaign depends on its visibility within the company. In order to draw attention to a campaign and encourage participation, it must be advertised internally using all available communication channels: digital, such as social media applications and the intranet, and analogue, such as events, posters and flyers. To achieve the greatest possible reach in the company, strategic planning is necessary. The campaign team must select appropriate communication measures and determine the launching order [process component: marketing strategy]. In addition to that, the team needs to coordinate the marketing activities with the sequence of the selected task types and the accompanying events, which are specified in the campaign schedule. The schedule also defines the start, end and duration of the individual phases of the campaign, for example, the duration for participation in a campaign, results evaluation and results publication. At the end of the conception phase, the technical implementation of the campaign concept is due [process component: IT template].

  1. 4.

    Execution: As a prequel to the campaign, marketing starts with a teaser announcing the topic and its background information. Subsequently, a call is issued. The call goes out to every employee in the company. The group of employees are the so-called crowd or the community. In ICU we make a distinction between these two terms. In our view the term community refers to the sum of all employees, while the term crowd addresses the specific part of the community that actively participates in an IC campaign. In other words, we understand the crowd to be the active subset of the community, whereas the community represents potential crowd participants not activated yet [process component: crowd/community management]. Once the campaign has started, the campaign team must coordinate the process activities [process component: process coordination].

    In addition, continuous process monitoring is required with regard to IT functionalities, progress and scheduling. The team must report continuously to the Content Owner, who can give feedback to steer the campaign in the right direction [process component: process monitoring].

    At the technical level, processes must be set up and configured to ensure that the campaign runs smoothly. These must be continuously monitored and supported. In addition, the content, such as the definition of tasks, must be managed [process component: IT & content management].

    Ongoing and open communication with the crowd has very high priority in this phase. At this point, the campaign team is seeking to strengthen and keep up the crowd’s commitment through active interaction both on the platform in the manner of feedback and moderation and at analogue events planned for in the marketing strategy [process component: crowd/community management].

  2. 5.

    Assessment: When the active working part of the crowd is finished, the results must be evaluated. First of all, the designated persons in the campaign team (Campaign Owner and Crowd Master) check the results with regard to their relevance to the originally formulated objectives of the campaign. They do so on the basis of the defined selection criteria in the beginning [process component: selection]. This preselection must then be compiled for the Content Owner [process component: preparation], who evaluates it in consultation with his department team [process component: evaluation].

  3. 6.

    Exploitation: The initially stated intentions to utilize the outcomes of the campaign can be identical with the final exploitation. This is often the case when departments want to compare their assessments on a particular issue with the assessments and evaluations of the crowd. However, when the objectives of the campaign are more complex and therefore the development of solutions is more open, the question of how to handle the final results and effectively exploit them has to be raised again. The final and binding decision can only take place in view of the results available at the end [process component: decision]. The campaign’s output, of course, can also become a spin-off for a new campaign.

  4. 7.

    Feedback: As we have already mentioned above, consistent and transparent communication throughout the entire process is an important factor for the long-term success of IC. Therefore, the closure of the campaign is an essential last step. First, the crowd/community has to be informed about the selected results and the reasons why the specific results were chosen. Second, it has to be announced how the results will be used for further activities.

    The results should be published on the platform so that they can be viewed and, if necessary, commented on by the campaign participants and all staff registered on the platform. The outcome of the campaign should also be made available to employees who are not part of the active crowd. It is therefore advisable to also publish the results and decisions through the company’s other communication channels [process component: communication of results].

    If the campaign concept initially provided incentives for participation such as prize draws, these must ultimately be redeemed. For challenging activities, such as developing a concept, the efforts of participants who were not selected as winners should also be taken into account. Their work should be recognized by giving them an explanation why their solution was not selected [process component: honouring].

Fig. 1
An illustration depicts the input with employees and departments, sourcing with the campaign of crowd voting, crowdsolving, and output with products, lawsuits, and rulings.

Task design using the mix & match principle (own representation)

Full size image

One observation we have made in the ICU Project is that the steering tasks within the individual process components take place in parallel or can be combined. However, the process components themselves remain the same (Fig. 2).

Fig. 2
An illustration depicts 7 phases namely, impetus, decision, execution, assessment, exploitation, and feedback, connected by flow arrows.

Phases and process flow of the ICU model (own representation)

Full size image

2.3 ICU Process Levels

It is clear from the above that the successful implementation of internal crowdsourcing requires a high level of communication and coordination. In the ICU Model, we have identified three different levels of process communication addressing different aspects and target groups:

  • Macro level: overall process

    At the macro level, it is important to represent the idea and the spirit of internal crowdsourcing within the company and to show the value added by the process for current business activities (process marketing). Here, the focus is on looking at the overall process and ensuring that the defined framework conditions for IC in the company are in line with the progress of the process and that process integrity is guaranteed. The target group for process communication is senior management, the executive board and the works council.

  • Meso-level: campaign

    The IC campaign represents the operational implementation of an IC topic and thus forms the core of the ICU Process. It consists of ‘visible’ process phases with communication activities running in the foreground (execution, final feedback) and ‘non-visible’ process phases with communication activities running in the background (conception, evaluation, exploitation).

    While the ‘visible’ phases take place at the micro level, the ‘non-visible’ process phases are located at the meso-level and are aimed at defining and coordinating the sense and purpose of the campaign in a selected circle. Here, process communication is aimed at the corporate divisions involved in the conception and implementation of the campaign.

  • Micro level: crowd/community

    At the micro level, process communication in the so-called ‘visible’ phases targets the employees, meaning the community and the crowd. Campaign marketing therefore initially serves to convey the purpose of the campaign and to solicit participation.

    In the further course of the campaign, progress is then reported in order to keep the crowd activities going and to maintain the principle of transparency. There is also direct interaction within the campaign in the form of moderation on the platform or IT support.

The distinction made here between the process levels is helpful in order to be able to better differentiate the responsibilities of the roles and clearly assign control activities later on.

3 Parallels Between Internal Crowdsourcing and Scrum

In this section we first compare the components of the Scrum process relevant for the IC and then introduce the roles defined in Scrum. Based on this we present and explain the ICU Role Model. There are two main similarities that suggest a role distribution for the IC that is similar to Scrum.

3.1 Process Levels

A basic agreement between IC and Scrum exists in the different process levels on which process communication takes place. This fact is only indirectly expressed in Scrum literature (Goll and Hommel 2015; McKenna 2016; Schwaber and Sutherland 2017; Maximini 2018). This is because Scrum is seen as a set of rules and is not viewed from a process-oriented perspective. But, as already shown in the explanations on IC, Scrum also has a macro level, meso-level and micro level on which separate communication activities are carried out.

  • Macro level: overall process

    As with IC, the macro level is also about representing Scrum with its principles, practices, rules and values in the company and making the added value of the process model comprehensible to everyone (process marketing). This level is also where the set of rules is located that determines the teamwork on the micro level.

  • Meso-level: product definition

    The product is designed on the meso-level. Here a catalogue of requirements is created, the so-called product backlog. It defines which problem the product should solve for the customer, which properties it should have, how it should perform and what it should look like.

  • Micro level: product development

    The requirements recorded in the product backlog are implemented on the micro level in an iterative procedure, the so-called sprintFootnote 2. Here it must be decided which requirements from the product backlog are to be realized in a sprint (creating a sprint backlog) and how the work on the upcoming tasks is to be organized.

3.2 The Principle of Transparency

The Scrum framework not only includes guidelines such as practices and rules but also specifies values and principles for the teamwork. One of the three principles is transparency. Ken Schwaber and Jeff Sutherland define transparency in ‘The Scrum Guide’ (2017) as follows:

The essential aspects of the process must be visible to those responsible for the outcome. Transparency requires that these aspects be defined according to a common standard, so that viewers share a common understanding of what they see. (Schwaber and Sutherland 2017, p. 7)

Transparency therefore means that everyone involved knows at all times in the work process what the current development status is. They know which features and problems are being worked on specifically, who is carrying out which activities and how the individual components contribute to the final product. Transparency is created by events such as the Daily Scrum, in which the team members (process participants at the micro level) discuss the status of their work on a daily basis and compare it with the set sprint goals (Schwaber and Sutherland 2017, p. 12). The fact that everyone has an overview of the work process and the progress made creates trust in the teamwork and the process, which motivates the team members (McKenna 2016).

In the ICU Project, we also conducted employee surveys and workshops on this issue. These revealed that process transparency is the key component in building a stable internal crowdsourcing process, ensuring that employees (crowd/community) have trust and confidence in the process and are highly motivated. Transparency also has a great influence on the perception of the employees’ personal engagement as useful, because they can comprehend what happens with their effort and feel appreciated. These findings are in line with the knowledge provided in the recent research literature as well (Garcia Martinez 2017, p. 298; Bañón-Gomis et al. 2015, p. 114; Schön et al. 2011, pp. 12; Abdul-Rahman and Hailes 2000, pp. 2; Ebner et al. 2009, p. 347). This leads us to conclude that the transparency of the process is achieved firstly through the open exchange of campaign objectives and background information with employees; secondly, by making it clear how the results and the individual steps within the campaign are used, so that employees can understand; and lastly by showing that the process serves a useful purpose in the company.

3.3 Scrum Role Model

The process levels just described refer to specific areas of responsibility that need to be managed or steered. In Scrum there are three roles that perform the following tasks:

3.3.1 Scrum Master (Macro Level)

The Scrum Master (SM) is responsible for representing the basic idea as well as the practices, rules and values of Scrum in the company (function: ambassador). The SM has to implement them and make them align with existing company values and structures (function: business developer). As coach and servant leader, the SM helps employees at different levels to understand and apply the agile framework. For example, the SM supports the Scrum Team in its work to always adhere to the agile principles and, if necessary, refers to the correct implementation of the rules. The SM assists the Product Owner with the setup and management of the product backlog and the communication with the Scrum Team. Furthermore, the SM teaches employees and managers outside the Scrum Team how they can interact with them in a way that is meaningful to them and increases the productivity of the Scrum Team (Schwaber and Sutherland 2017, pp. 7).

3.3.2 Product Owner (Meso-level)

The Product Owner (PO) is the communicative interface between the Scrum Team, the customers and the rest of the company (function: stakeholder manager). The core task of the PO is to exchange information with the customers about the desired product and to create a catalogue of requirements for product development, the so-called product backlog. The requirements are presented in the form of user stories, which the PO has to develop and present to the Scrum Team. As a representative of the customer’s perspective, the PO is solely responsible for the product backlog and decides whether to accept or drop further requirements from outside. Also, the PO holds the position that can influence the course of action during the sprint. Starting from the product backlog, the PO is the one that checks the potentially deliverable product increments for compliance and then accepts or rejects them. In addition, the PO must also manage the financial aspects and keep an eye on key performance indicators (KPIs) such as ROI (return on investment) (McKenna 2016, p. 39; Schwaber and Sutherland 2017, p. 6).

3.3.3 Scrum Team (Micro Level)

The Scrum Team is a cross-functional development team that is self-organized in its work. The team members usually do not have defined roles. The idea behind it is that everybody should be able to do everything in a sprint meaning writing, testing, documenting and delivering software. Together the team decides which items from the product backlog are the most relevant at the moment and are to be implemented in the upcoming sprint transferring them to the sprint backlog (steps: sprint planning and sprint goal). During the sprint, the team works self-sufficiently. The SM and optionally also the PO only check in with the team during the Daily Scrum, which is used to jointly check and ensure the development progress. At the end of the sprint, the team members present their potentially deliverable product increment (step: sprint review) to the PO and all the stakeholders, who give feedback. Afterwards, the team has a sprint retrospective with the SM present. This serves the purpose of analysing the completed sprint (steps: lessons learned and how to improve), so that the team can improve their next sprint process (McKenna 2016, p. 42; Schwaber and Sutherland 2017, p. 7).

The principle of transparency in Scrum can be understood as a cross-cutting task for which all roles bear equal responsibility. However, the implementation of transparency looks different on every process level and results in different requirements for the individual roles:

All of the team’s success and failure is out in the open for all to see. The team is operating in a transparent manner and sharing information; the Product Owner is also being transparent and sharing. The Scrum Master posts all relevant team information on information radiators so that stakeholders can easily find out how the Sprint is progressing. […] Instead of hiding information, a Scrum Team broadcasts everything about what they are up to. (McKenna 2016, p. 36)

3.4 Design of the ICU Role Model

The role model that we have developed in the ICU Project is essentially based on the division and design of roles described in Scrum but also has other actors. It describes the division of responsibilities for the different process levels as well as process sections and the associated steering tasks. In addition, it indicates the relations to other company divisions, which are needed as support for a successful execution of IC. With reference to Porter’s process model (Porter 1985), they are referred to here as ‘primary’ and ‘secondary’ units.

3.4.1 Primary Roles

We have identified three main roles that are essential for the successful implementation of IC: (1) Crowd Master, (2) Campaign Owner and (3) Crowd Technology ManagerFootnote 3. Together they form the so-called crowd team. It is the department of contact for the topic in the company and is responsible for the entire process. In concrete terms, the three roles perform the following tasks:

3.4.1.1 Crowd Master (Macro Level/Meso-level)

The Crowd Master (CM) is responsible for the general direction and the implementation of IC in the company. To this end he consults with the Board of Directors, senior management and the workers’ representatives [process component: marketing strategy]. The CM ensures that the established framework conditions are adhered to and that the integrity and quality of the process are guaranteed [process component: process monitoring].

The idea of IC is promoted by the CM in the company in order to create an awareness of the possible use cases, the structure and process of internal crowdsourcing campaigns as well as to establish them as everyday working routines (ambassador function). The CM does this through direct discussions and organizing workshops or information events [process component: marketing strategy]. As an advocate for IC, the CM proactively networks within the company and establishes rapport with the people in the so-called specialist departments. Thus, the CM forms alliances with important key players and creates potential commitment with regard to Content Ownership [process component: exploratory talks].

The CM is a supportive sparring partner to the Campaign Owner during the development and implementation of campaigns as well as during the preselection of campaign results. In this context the question of employee motivation is of great importance. The CM summarizes the incentive mechanisms common in the company in a kind of catalogue and makes further adjustments to the incentive system [process component: incentive system/employee motivation].

In order to ensure support within the company, especially from the board of directors and senior management, the CM must create regular reports and document success using significant KPIs, for example, number of registered employees, number of active campaign participants, satisfaction of Content Owners and so forth [process component: process monitoring].

3.4.1.2 Campaign Owner (Meso-level/Micro Level)

The Campaign Owner (CO) is the linchpin at the operational level and is responsible for the development and implementation of internal crowdsourcing campaigns. The CO works together with the Content Owner to define the goals, intention of utilization and content design of the campaign [process component: target definition; intention of utilization]. Based on their exchange, the CO drafts the task design for the specific campaign, selecting task types and formulating task descriptions [process component: task design; selection criteria], and chooses the appropriate incentives from the incentive catalogue created by CM best to motivate participation [process component: incentive system/employee motivation].

When planning the single steps of the campaign communication, the CO coordinates with the secondary units and integrates all activities into a higher-level campaign plan. The CO shares the campaign plan with the entire team, so that the process is transparent for everyone involved [process component: marketing strategy; process coordination]. The Crowd Technology Manager (CTM) is informed of the task design by CO so that they can set up the campaign technically, and they receive the task description to enter into the IT template [process component: IT template] (Fig. 3).

Fig. 3
An illustration depicts the macro model with management, crowd master, and works council, meso level with secondary and specialized units, and micro level with crowd.

ICU role model (own representation)

Full size image

During the implementation phase, the CO coordinates all activities, carries out campaign monitoring and is in touch with the crowd, for example, moderating on the platform or answering questions [process component: crowd/community management].

After the active work phase for the crowd has been completed, the CO, in tandem with the CM, preselects the results with the established selection criteria in mind. The CO processes the results, so that Content Owner and a selected committee can evaluate them. Once the decision has been made, the CO acknowledges the campaign participants for their efforts (feedback, award ceremony, etc.) and prepares the information for the final feedback [process component: selection; preparation; evaluation; decision; communication of results; honouring].

3.4.1.3 Crowd Technology Manager (Meso-level/Micro Level)

The Crowd Technology Manager (CTM) configures the IT process of the campaign and is responsible for the technical implementation of the campaign guided by the Campaign Owner. Based on the given task design, the CTM builds an IT template and manages the content provided by the CO (uploads, changes) [process component: IT template]. The CTM is also in charge of the communication activities on the platform, initiating the go-live of campaigns, announcing the different work phases (first crowdvoting, then crowdstorming, etc.) and publishing information regarding the campaigns [process component: IT & content management].

The CTM ensures a flawless run of the platform and a smooth user experience (continuous bug fixing) providing user support in case of technical problems with the platform or campaigns.

3.4.2 Secondary Roles

As mentioned in the CO’s role description, the planning and implementation of campaigns requires the support of employees from other company departments belonging to the so-called secondary units. In order to coordinate the cooperation, a so-called campaign team is formed which, in addition to the Campaign Owner and the Crowd Technology Manager, consists of the Content Owner, the individual representatives of the secondary units (secondary counterparts) and the employees in the crowd.

3.4.2.1 Content Owner

As mentioned in the role description of the CO, the planning and implementation of campaigns requires the support of employees from other departments of the company, which belong to the so-called secondary units. The goal and purpose of the campaign are defined by the Content Owner so that the specialist department can then continue working with the results achieved [process component: target definition; selection criteria; task design].

The Content Owner may or may not be the same person who submitted the topic to the crowd team. In principle, all employees can suggest topics for which they can take responsibility/ownership but are not obliged to do so. If there is no ownership, the CM and the CO must ask a suitable specialist unit in the company to take over the ownership and provide a Content Owner. When evaluating the results, the Content Owner is part of the selection committee [process component: evaluation; decision].

3.4.2.2 Secondary Counterparts

The CO seeks support for the planning and implementation of campaigns from the relevant experts in the company. When developing a suitable communication strategy for a campaign, for example, the CO contacts the internal marketing or employee communication department with a draft so that they can work together on the details (marketing counterpart). For the implementation of offline community events to accompany the digital internal crowdsourcing campaigns, the CO seeks the support of the department that conducts internal events and participative formats (events counterpart). For further training formats or qualifying initiatives in connection with campaigns, the CO works together with the HR department (HR counterpart). The Crowd Technology Manager works actively with the IT department to adapt the platform to the guidelines of the company’s IT architecture (IT counterpart).

The areas of the company where the necessary internal contacts are located depend on the structure of the company.

3.4.2.3 Crowd

Although the crowd in the ICU Role Model is assigned to the campaign team, it is not a conventional team member like the others shown above. The crowd is the general condition to execute campaigns. It is the role that accomplishes the tasks set in the campaign and produces results. Since the crowd is just active during the campaign and a mutual exchange with the conventional team members can only take place within this situation, it is rather a component in the campaign team than a team member.

3.4.3 Tertiary Roles

The success of IC essentially depends on the commitment of the (7) Board of Directors or senior management and the support of the (8) employee representatives or works council. Together with the CM, these two stakeholders must negotiate and define the framework conditions for IC in the company and clearly demonstrate that they believe in the process and its benefits.

4 Conclusion

In this article we have presented a new process and role model for the application of internal crowdsourcing in companies, which we have derived from the practical implementation in the ICU Research Project. Based on Gassmann et al. (2013a, 2017), we developed differentiated process phases and components (ICU Process) and combined them with a process management approach described as the ICU Role Model. Due to the demonstrated similarities with Scrum, we were able to identify and formulate roles for internal crowdsourcing with specific task descriptions in relation to the developed ICU Process. The role distribution is ideal-typical and can be scaled according to the circumstances and the availability of resources in the company. This means that some of the roles can be performed by one person, depending on the workload. This is true for the roles of the Crowd Master and Campaign Owner, or the Crowd Technology Manager and IT Counterpart, especially in the initial phase of applying internal crowdsourcing.

The ICU Process and role model are intended to assist companies interested in applying internal crowdsourcing and therefore indicate how to plan if internal crowdsourcing is to be implemented successfully. As part of the IC System, introduced in chapter ‘Managing the Crowd: A Literature Review of Empirical Studies on Internal Crowdsourcing’ of this book, it is primarily aimed at companies that need a stronger orientation in their individual transformation journey and want to use digital processes to mobilize internal knowledge and competencies to connect and process them faster, so they can be useful for ongoing business processes.