Participative Process Introduction:
Three Case Studies From the indiGo Project¹

Abstract: In software engineering, the quality of development and business processes and their models is of utmost importance for (a) the quality of the software products developed and (b) the operational success of the organization. Nevertheless, many organizations neglect these processes and leave the knowledge about them in the heads of their experts. In this paper, we present the indiGo method and platform for eParticipative Process Learning. Furthermore, we present the results of a three case studies for the evaluation of these methods. The results indicate that processes introduced and modeled with process user participation result in process models with higher acceptance and better perceived quality.

Keywords: Distributed participative process evolution, process introduction, process improvement, process inspection, eParticipative Process Learning, indigo

Categories: K.4.3, D.2.m, H.5.3

1 Introduction

Process models of organizations operating in the software industry are considered major assets for these, and range from business to software development process models. Especially in the innovative software market, they are constantly subject to changes caused by changing business, new technology and scientific advances. To survive these changes, process models need to be constantly inspected, evaluated, revised, and improved. Furthermore, they need to be enriched with lessons learned about their application in practice.

The approach of the BMBF-funded project indiGo (grant number 01 AK 915 A http://indigo.fhg.de/) is to increase their applicability as well as support their inspection and improvement. indiGo offers members of an organization to engage in moderated discussions about the structure, content or execution of a process model. The results of these discourses are process-related improvement suggestions and lessons learned. In particular, indiGo allows Communities of Practice (CoP) to establish themselves based on business processes, to provide their opinion about the process to other CoPs, and to solve problems during execution of the processes.

This general approach is called eParticipative Process Learning, according to process learning as defined by Argyris and Schoen [ArSc78]. This paper presents the results of a case study where eParticipative Process Learning was used to introduce two processes into an organization.

In Figure 1, the eParticipative Process Learning cycle of indiGo is depicted for one process. Read clockwise, the cycle starts with the original, plain process model. This process model is annotated, discussed, and enriched with lessons learned by the members of an organization. Lessons Learned are then extracted from the discussions with the support of text-mining methods. Finally, the experience enriched process model is revised into the applicable process model based on corporate goals. To support the evolution of process models in an organization, indiGo offers an integrated, comprehensive set of methods and a technical infrastructure as a joint effort of two German Fraunhofer institutes: Fraunhofer IESE (Institute for Experimental Software Engineering) in Kaiserslautern and Fraunhofer AiS (Autonomous Intelligent Systems) in Sankt Augustin. Both the developed methods and the indiGo architecture were evaluated by three case studies between 2002 and 2003.

The paper is structured as follows: The next section describes the motivation for eParticipative Process Learning and the advantages for the members of an organization deriving from this approach. The third section describes the indiGo methodology and technical infrastructure for eParticipative Process Learning. The fourth section gives an example how the methodology and technical infrastructure is used for eParticipative Process Learning. The fifth section gives an overview of related work. In the sixth section, three case studies performed at IESE are described. The paper closes with a summary and outlook to future work.

2 Motivation of eParticipative Process Learning

As mentioned in the introduction, well-defined and applicable process models constitute a competitive advantage for an organization. However, when organizations try to implement a process, they will likely face the following problems: (a) employee resistance due to insufficient involvement, (b) insufficient knowledge to execute the process, and (c) high process-modeling and maintenance effort. In this section, each of these problems mentioned above is described in detail, followed by the solution provided by eParticipative Process Learning.

The influence of employee resistance due to insufficient involvement is mentioned in a study by the German Institute for Learning Organization [Moc97]: four of ten projects to accomplish organizational change achieve less than 60% of their objectives. The reason for this failure are not technical or factual obstacles, but mental-cultural barriers like missing consciousness regarding problems, missing network among stakeholders, and active as well as passive resistance to change. Due to the organization-wide influence of processes, these findings also apply to process modeling. When these barriers are not considered, process users show resistance in applying the process model. One means to tackle these barriers is the communication of the need for change and the involvement of the stakeholders of a process. This involvement is often neglected, as shown by the 2002 change management benchmark of Prosci [Prosci02]: Communication is one of five major success factors, but communication-related issues are also two of five major issues that are neglected.

With web-based, moderated discussion, eParticipative Process Learning offers an opportunity to involve potentially all employees, thus overcoming these barriers. This advantage for the organization - having an implemented and accepted process model - is supported by further advantages for the regular employee. The first and direct advantages of using indiGo are (a) that meetings dedicated to process improvement can be shortened or even substituted by eDiscussions, and (b) that participating in eDiscussion is self-determined with regard to time and space.

A new or changed process implies that the knowledge of an organization has to be adapted or needs to be newly created. This applies in particular to processes that describe creative and innovative work. This may create an insufficient supply with needed experience. First, a user can use private notes attached to the process model as a reminder for personal opinion and questions. Then - again using eDiscussions - an employee can state the opinion or question, which is the answered by one of the other process users or the process owner. These contributions are then compacted into Lessons Learned that are stored in the experience base. The Lessons Learned that fits best to the current situation of a user are retrieved, thus supporting the process execution with experience. This approach offers a quick solution to a question on the one hand, but also stores proven and discussed solutions for later use.

The advantages for regular employees described before, such as self-determined participation in eDiscussions are valid for Process Owners as well. For this group, the following advantages are added: First, potentially all stakeholders concerned about a process can be involved into the discussion about a process.

This holds in particular when participation is enforced by law, e.g., participation of workers representatives. The consensus building about the process facilitates application of the process as defined. Second, the modeling phase is shortened, since open questions about how a process should be performed can be solved during eDiscussions. Third, eDiscussion can be done in a constructive manner, i.e., change suggestion can indicate what the process should look like. For example, process performers can take quotes from the process description and rephrase them to express their opinion.

During the operational phase, indiGo supports process maintenance in several ways: Lessons Learned offer a lightweight opportunity to capture specific hints to execute a process, which would otherwise clutter the process description. Furthermore, Lessons Learned also stretch the timespan between process revisions, since small changes of the process can be described as Lessons Learned and thus be evaluated before they are integrated into the process. Lessons Learned also offer a criterion as to when to perform process maintenance: Based on the analysis of the Lessons Learned, process maintenance is triggered, which tries to integrate the evaluated Lessons Learned collected so far.

3 The indiGo Methodology and Technical Infrastructure

The objective of the indiGo project is provide a methodology and technical infrastructure for process learning into an integrated social-technical system. To provide the context for the case study, the methodology and technical infrastructure are described in the following.

3.1 indiGo Methodology

The indigo methodology consists of five sub-methods: introduction method, process learning method, eModeration method, text-mining method, and process evolution method.

The introduction method is used to instantiate an indigo system in a new organization. How an organization can accomplish process improvement and enhancement using the indiGo platform (its technical side) is the core of the process learning method. It is based upon the Experience Factory and the Quality Improvement Paradigm [Basi+94]: The experience-based, evolutionary improvement of an organizations experience base by a dedicated team within the organization. The process learning method encapsulates the eModeration-, text-mining and process-evolution method by proving a framework for initialization and results handling.

The eModeration method explains to potential eModerator how a discussion should be initialized, conducted and finalized. The text-mining method helps in using text-mining techniques to support process learning (e.g., by creating initial versions of discussion summarizations. Finally, the process evolution method takes care that changes in the process models are implemented, communicated and recorded. The process learning method and process evolution method themselves are described as processes, so that they can be adapted and improved using indigo.

3.2 indiGo Technical Framework

The indiGo technical infrastructure consists of the Zeno groupware tool of AIS [GoKa97, Moc97], IESE's experience management environment INTERESTS [Alth+01], IESE's tool for process modeling and publishing Spearmint [Beck+99, Kell+98], as well as tools for text mining of discourses from AIS.

Figure 3 shows the indiGo platform as installed at IESE. The systems mentioned above are connected by the Integrator to provide completely new services to a user of a process model. Furthermore, the Integrator allowed to build upon operating systems implemented with previous versions of the above mentioned IESE technologies. These systems are part of the Corporate Information Network (CoIN), called CoIN-IQ (IESE Quality Management System), CoIN-PR (Project Registry) and CoIN-EF (Experience Factory).

The business process model repository CoIN-IQ [Deck+01]- which is edited and created using Spearmint - acts as the document source. CoIN-PR contains information about past and current projects at IESE. From these projects, a user can select his / her the project, that they are currently working on or which is of other relevance to them. This project data - called project context - is used by Zeno to label discussions and annotations in the associated business process descriptions within CoIN-IQ. Furthermore, the project context is used to query CoIN-EF (build with INTERESTS) from a certain business process description. CoIN-EF then uses Case-based reasoning [Kolo93] to retrieve lessons learned from similar projects and processes.

4 An Example of eParticipative Process Learning

This section describes how a process performer and process owners are using indiGo for eParticipative Process Learning. It is structured according to the indiGo process lifecycle depicted below in .

The first step for him and the moderator is to define several goals for the discussion like: "Should the payment method made more explicit or should every project manager negotiate his own payment method with the customer?" Subsequently he publishes the process model on the intranet and invites some process users. Thereon every participant inspects the process model based on the given goals to understand, comment, and enrich it with their own experiences. Simultaneously they look for typing errors, evaluate the ease of use, or make a dry-run of the process. Each participant can attach private annotations to the process and discuss it with other participants. The moderator summarizes the discourse from time to time and extracts ideas and Lessons Learned assisted by text mining techniques.

Finally the project manager uses the ideas and experiences from the discussions to rework the process model. After the finalization of the process model he publishes it on the corporate intranet and informs all concerned parties of the new process model.

During the operational phase the members of the organization use the process model. In this phase, the process model remains stable. The goal of discussions in this phase is to provide an up-to-date, fix minor problems and collect experiences and opinions about the application of the process model.

For example, assume Ms. Legrelle (another Project Manager) has to compose an offer for a subcontract from a small start-up. The project acquisition process has a subprocess devoted to the contract. It suggests that the payment method should not be too fine-grained in order to minimize administrative overhead. Ms. Legrelle feels uncomfortable with this guideline. The year before she had had a subcontract with another start-up, MoCom, which got bankrupt, so that the last payment was lost although they had completed the work. Ms. Legrelle prefers to design the new offer with a frequent payment schedule, at the cost of more overhead in the administrative unit. Clearly, she should not modify the organization's process model for industrial project acquisition on her own. She would probably attach a personal note to the subprocess and initiate that her experience is recorded as a lesson learned and shared with her colleagues through the discussion forum.

Either way, if a new solution or conclusion turns up and finds approval, it may be added as a new experience to the experience base. The process model would be improved periodically as substantial feedback is accumulated from the discussions and new experiences.

The process enters the revolution phase, when either (a) the number of problems reported is determined critical by the Process Owner or (b) major changes of a process are triggered elsewhere (e.g., strategic decisions). The general direction for this phase is to criticise the process to gain topics what aspect of the process should be changed and which one should be kept.

5 Related Work

One central issue in knowledge management is how to offer the right knowledge at the right time. As the domain of indiGo is based on process models, they form the backbone for knowledge delivery. While applying a particular process model, members of the organization find supplementary knowledge with regard to the user's current project context. This supplementary knowledge is provided through associated discussions in the users' groups, his private annotations and, of course, records lessons learned from other projects. In the remainder of this section, we discuss several related systems for participative process learning as realized by the indiGo approach.

As a preliminary conclusion, indiGo is more comprehensive than other approaches to organizational process learning [Tau00, Berg01] and distributed knowledge management because it bridges the gap between informal, communication-oriented knowledge and formal, organization-oriented knowledge and provides a socio-technical solution that covers individual knowledge usage as well as social knowledge creation. The solution is built upon established base technologies like process modeling tools, discussion group software, and case-based reasoning. These technologies are integrated to provide easy access to discussions and Lessons Learned services. Furthermore, Text-Mining techniques are a substantial part of indiGo (a) to lower the cost of experience acquisition by summarizing discussions to lessons learned and (b) by providing overviews of discussions. The methodology ensures that the organizational aspects of eParticipative Process Learning are considered as well and thus, that the platform is integrated into the flow of work in an organization.

The related work in the area of process learning can be subdivided into discussion group software, collaborative modeling of business processes, process model related discussion and experience capturing as well as lessons learned systems. Each of these areas is presented in the following with one or more examples. (For a more detailed overview from a technical perspective, please refer to [Alth+02].)

Concerning discussion group software, this area itself can be subdivided into three sub-areas that are relevant to process learning: consensus building, collaborative problem solving and document review. Since all these areas can be supported more or less by conventional web-based discussion groups or new-servers, examples are only given for systems specializing in one of the sub-areas. For consensus building, i.e., deciding about a disputed topic, the German town Esslingen acts as an example for eGoverment [Märk+02]. Concerning collaborative problem solving, i.e., several people working on solving a problem, there are examples from general decision-making like Compendium [Comp03], or dedicated eLearning systems like WBT-Master from the Coronet project [AnPf02]. As third sub-area, examples for document review software are D3E [D3E03], which allow to discuss a document as a whole or in sections.

Tools for collaborative process modeling allow locally and temporally distributed persons to design a process. A commercial example is the ARIS collaborative suite from IDS-Scheer [ARIS03]. CHIPS [HaWa99] from Fraunhofer IPSI offers additional support for process execution by linking process instances with resources on BSCW servers.

Examples for process annotating systems are a combination of the Electronic Process Guide with the discussion software page seeder [Scot03] and the WESPI system from DaimlerChrysler [vHun00]. Both of them allow to discuss process models, the latter also allows to create frequently asked questions lists based on email contributions.

Finally, lessons learned-based decision support systems capture experience. Examples that capture experience from software engineering projects are CoIN-EF [Deck+01] and the Lids System from Daimler Chrysler [vHun00].

6 Case Studies on eParticipative Process Introduction

Since its start in mid-2002, indiGo has been used at IESE. The methodology and technical system developed for indiGo were evaluated through several a case studies, which were performed at the Fraunhofer Institute for Experimental Software Engineering (IESE) between mid 2002 and mid 2003. These case studies are presented in the following: The first case study- being the main part of the evaluation of indiGo - was about the introduction of two processes at IESE. In the second case study, the refinement of a process draft was evaluated. In the third case study, indiGo was used to capture additional experience relevant for the performance of a process.

To give the context of these case studies, the Fraunhofer IESE is described before the description of the case studies itself. The IESE employed about 97 full time employees at the time of the case studies. Of these, 70 scientists work on applied research as well as in the evaluation and transfer of software engineering knowledge in a broad range of industrial and publicly funded projects. IESE's knowledge management is performed by the CoIN team (Corporate Information Network). They maintain the components and the content of the indiGo infrastructure mentioned in the previous sections. As applied research is the core business of IESE, process models about research and project execution are central and affect most of IESE's staff. It is vital that they accept and "live" the process models and cooperate to continuously improve them. Due to the variety of projects, the processes can reasonably be captured at an abstract and decontextual level only. That means, the execution of an abstract process model is knowledge-intensive.

6.1 Case Study No 1: Participative Introduction of Processes

The main objective of the first case study was to evaluate whether discussing process models in the introduction phase would increase their acceptance and perceived quality. Another objective was to gather practical experience with the use of the technical infrastructure and (parts of) the methodology. A summarization of this case study will be described with the following structure: First, the context and design of the case study will be described. Second, the results of the case study regarding the above mentioned objectives will be presented. Third, an outlook to further evaluation activities closes this section. A more detailed description of the results is available in [Deck03].

6.1.1 Case study design

To give an impression of how this case study was executed, its design are presented in this section. First, IESE and the used process models as context of the case study are described. Second, design and tools used for the evaluation are presented.

Concerning participation, each IESE member decided on his/her own to participate in this case study. Each IESE member had the opportunity to contribute to the discussion or to answer the questionnaires. Actual participation was voluntary and supported by upper management.

The process models that were introduced using indiGo were Industrial Project Acquisition and Conference Participation Planning: Industrial Project Acquisition, describes the creation of an offer for an industrial customer. Conference Participation Planning coordinates the attendance at conferences. The main reasons for selecting these processes was their importance for IESE: They address the research as well as the application part of applied research. Furthermore, they have a high potential of uncertainty and conflicting interpretations, which implies a need for discussions about these process models. Both process models were created by IESE members experienced in the execution of the process and possessing process modeling skills.

The design of the case study was focused on the main objective of examining whether the evaluation of acceptance and perceived quality would improve. To show this effect, evaluation before the discussion and evaluation after the discussion (when the results have been integrated into the process model) is necessary. Consequently, a pre-post design was chosen: At the start of the discussion in June 2002, a questionnaire was distributed via email among all IESE members to give a personal evaluation of each of the two processes. After the improvement suggestions resulting from the discussions were implemented, a second questionnaire with the same evaluation questions was distributed to evaluate the changed process in July 2002. This second questionnaire was again distributed to all IESE members by email. This email also contained a summary of the discussions and the notification that the accepted changes were implemented. Then the results of the participants who completed both questionnaires were compared. Each questionnaire contained a set of 13 questions for each process about acceptance and different aspects of perceived quality. For each item, a statement was given to which agreement could be stated on a scale from one (high agreement) to six (high disagreement). The quality aspects were then condensed to two condensed metrics to facilitate evaluation: "single quality aspects", and "overall quality aspects".

6.1.2 Case study results

The presentation of the case study results is divided into two parts: First, the differences in acceptance and perceived quality are presented. Second, the main practical experiences and findings are presented. Both parts rely on the distribution of participants that is presented in Table 1. In particular, the differences in acceptance and perceived quality are based on the participants who completed both questionnaires, who are about 16% of all IESE members.

None of the participants who completed the 1^st and 2^nd questionnaire were part of the project members of indiGo. Since the absolute number of participation is quite small, transferring these results to other organizations should be done with caution. Nevertheless, the results of this case study give hope that the effects observed can be replicated in these future evaluations. (Threats to validity are discussed in detail in [Deck03].)

Participant in	No. of participants	% (from 97)
1st questionnaire	24	25 %
2nd Questionnaire	15	16 %
1st and 2nd Questionnaire	15	16 %
Discussion	21	22 %

For measuring acceptance and perceived quality (single quality aspects and overall quality aspects), two major findings hold for both processes: When the results of the pre-phase (1st questionnaire) are compared to the ones in the post-phase (2nd questionnaire), the median of all results improves. The only exception is the median of acceptance for Conference Participation Planning, which remains stable. Furthermore, the bandwidth of results decreases, i.e., participants evaluate the process in the pre-phase more differently than in the post-phase. In other words - assuming that these effects are caused by the process discussion - the resulting processes are evaluated better and more consistently with respect to acceptance and perceived quality.

These effects are depicted exemplarily by the results of Industrial Project Acquisition in 0 and 0. For the single quality aspect measure shown in 0, the median increased from about 0.77 to 0.90 (with 1.0 being the best possible result for this measure). The overall quality aspect measure (also shown in 0) increased from about 0.8 to 0.83 (again, 1.0 being the best possible result). As depicted in 0, the median of acceptance measurement increased 2 to 1 (with 1 being the best and 6 being the worst measure).

The significance of the difference - i.e., whether the difference is caused coincidentally or has a statistical significance - was investigated using the Wilcoxon matched pair test [Shes01]. For case studies like these, a level of significance or P-value of 10 % or lower [Bria+99] is an acceptable indicator of significance. Based on this level of significance, the Wilcoxon-matched pair test was successful for two of the three criteria of each process. The criterion where it failed differed between the two processes: The test for Overall Quality Aspects failed for Industrial Project Acquisition. For Conference Participation Planning, the test failed for the aspect Acceptance. Therefore, the improvement observed has to be checked in future evaluations especially for these aspects with failed tests. Furthermore, due to the low number of participants, the power could not be calculated. Consequently, no statement can be made on whether no difference is in fact present. (For details, refer to [Deck03].)

In Figures 5 to 8, the decreasing result bandwidth between the results of questionnaire one and two is shown graphically by smaller boxes (25% - 75%) and the distance between the non-outlier min and non-outlier-max (see legend for details) between the pre- and post-phase.

The practical experiences gathered about indiGo add to the above findings: The major findings concerned the indiGo technical infrastructure, the process learning method, and the eModeration method. These findings were drawn from the answers of further questions within the two questionnaires, the discussion groups intended for user feedback and by analysis of the process-related discussion groups.

For the indiGo technical infrastructure, discussion groups about indiGo itself were the most important source of improvement suggestions. From 36 contributions, 26 improvement suggestions could be deduced. In addition, four improvement suggestions were issued in process-related discussion groups and were directly implemented. From the first questionnaire, sufficient usability and availability could be deduced.

Concerning process learning, 26 improvement suggestions could be deduced from 120 contributions in four weeks. 16 of them were implemented. Since IESE-internal processes were discussed, these improvement suggestions can be described on an abstract level only due to reasons of confidentiality. Table 2 gives an overview of the improvement suggestions and the number of improvement suggestions implemented and rejected. For each category mentioned in the upper row of the table, an explanation and an example will be given in the following. Information Flow states the number of suggestions concerning documents or other data passed in the course of the process. An implemented example was a set of rules concerning registration for conferences. Role responsibilities are suggestions to change the responsibilities of a role within the process. A rejected example for this category was late involvement of the Project Manager. Deregulation summarizes suggestions to delete rules mentioned in the process description. An implemented example was changing the mandatory creation of a conference travel report to a voluntary basis. Clarification counts suggestions where parts of the process should be detailed. An implemented example for this category was adding a checklist about customer expectation clarification.

The first questionnaire revealed a generally positive attitude towards process discussions and experience sharing. Asked about their participation in the future, six participants of the 2nd questionnaire answered that they would not participate. Nineteen participants stated that they would participate in future discussions. The most important factor for future participation is relevance of the topics and processes discussed.

The eModeration Method was improved by several Lessons Learned from the case study. For example, the role of the Moderator and Process Author should not be performed by the same person. Furthermore, most of the participants in the 2nd questionnaire were satisfied with the relevance, results and moderation of the discussions.

Simplified, the case study showed the following: acceptance and perceived quality increases with process discussion. indiGo supports this discussion well. Due to the (potential) involvement of all organizational members, improvement suggestions concerning the processes could be collected that would not have been (practically) collected in classical, workshop-based process modeling.

6.2 Case Study No 2: eParticipative Refinement of a Process Draft

In the second case study, process-models that were the result of a complete process modeling effort were the objects of the study. To evaluate whether elaborated, but incomplete drafts of processes could be improved via eParticipative Process Learning, another application of indiGo was performed in Mai 2003. The object of this application was the After Sales Marketing process, which belongs to the group of project process like the process Industrial Project Acquisition mentioned before. This process describes the activities to be performed after a project has been executed. In particular, it describes how to stay in contact with a customer to gain real-life application experience of IESE methods and technologies. Therefore, this process also acts as a source of new Lessons Learned for the Experience Base.

The main process performers of this process are IESE members responsible for coordinating projects in several application domains. Due to this business, these stakeholders have conflicting schedules caused by their out-of-office activities. IndiGo offered an opportunity to involve all process performers in the discussion about how the process should be executed.

In a regular meeting of the process performers, a short, 30-minute introduction to the content of the process and the objectives of the discussion was given. The discussion itself was then performed via indiGo. The process performers not present at this meeting were invited via a separate email. Therefore, no separate process improvement meeting had to e schedules, and all process performers were offered the opportunity to participate.

Eleven IESE members participated in the discussion. Five of the participants belonged to the group of the nine major process performers. They created 50 contributions, from which nine new Guidelines for the process could be extracted. Furthermore, the templates for data collection and procedures concerning data evaluation were improved or newly defined. However, no quantitative data concerning the pre- and post evaluation of these participants can be given, since only the insufficient data could be derived from this case study.

In the authors' opinion, this application shows the advantage of participating asynchronously (i.e. independent of time and space). Furthermore, since discussions were directed to web-based discussion groups, the time needed for conventional process improvement meetings with process performers present was decreased. In addition, further stakeholders like the workers council were easy to involve in the discussions about the process.

6.3 Collaborative Experience Creation and Capturing

In the third application of indiGo, a combined approach of meetings followed by subsequent eDiscussions was used to create and capture Lessons Learned. He topic of this effort was the creation of proposals for public projects to enrich the respective process with further experience. The initial group of participants consisted of four IESE members who were involved in the creation of at least one public project proposal. The starting point were two 1.5 hour meetings to get an initial set of guidelines, checklists, and further topics to be discussed. These results were then transferred into eDiscussions and refined further by the initial group. After one month, and after a critical mass of contributions was reached, the eDiscussion was opened for all IESE members.

The result of this discussion were 42 contributions, which contained 21 new Lessons Learned (like checklists about financing and proposal creation) and text fragments (like templates for workpackages). These results were integrated into the process models and the experience base.

Again, this application showed the advantages of self-determined participation. Two further practical advantages supported the discussion: First, the participants attached text fragments and examples of proposals, which could be used instantly for future proposals. Second, a discussion about potential project proposals was built upon the results of this discussion group. In the future, more discussions like this will be performed when more than three IESE members are involved in a discussion, since compared to exchanging ideas via email, eDiscussions are open to all participating members and the contributions to these discussions do not get lost in the email account of a user.

7 Summary and Outlook

indiGo has shown to be a valuable system for a process-related discussion to learn about and improve an organization's processes. It is used to identify and record experiences from participants of discussions in order to feed them back in to an organization-wide experience base. Applied in a distributed environment, it can be used at the same time for distributed inspection (i.e., eProcessInspection). indiGo is designed to support all kinds of knowledge that have been identified as being important for organizational process learning. These knowledge units are process models, experiences from real projects, discourses in several goal-oriented groups, and private annotations to process models.

Starting in May 2002, indiGo was evaluated in three case studies carried out at Fraunhofer IESE in Kaiserslautern, Germany. In the first case study, two new processes were introduced with the indiGo technical infrastructure as a platform. Besides improving the discussed process models, we received valuable feedback for all the described methods and technologies of indiGo. In the second case study, a draft of a process was refined to a defined process model. The third case study showed that indiGo can be used to capture experience relevant to execute processes.

Through indiGo's process learning method, stakeholders of a process can decide which issue that attracted their attention should be discussed within a selected group of people. The technical infrastructure enables the organization of parallel discussion groups. The structured and goal-oriented execution of those discussions is ensured by the eModeration Method.

At the end of the project in 2003, we consider the possibility to extend the in-diGo approach to applications where process models do not play such a central role. Although a platform for organizational learning should eventually cover all knowledge categories treated in indiGo, the first steps to organizational learning need not necessarily involve process models. An organization can introduce indiGo in a stepwise manner by starting with an experience factory or an eParticipation forum.

Acknowledgements

indiGo (Integrative Software Engineering using Discourse-Supporting Groupware) is funded by the German Ministry for Education and Research (BMBF) under grant number 01 AK 915 A [see http://indigo.fhg.de/ ].

Thanks go to Astrid Haas for her work on eModeration and Torsten Willrich as well as Markus Nick for their help in the de velopment of indiGo. We also thank our students for their work on the first protoypes of the indiGo technical architecture and process model processing framework.

References

[Alth+02] Althoff, K.-D.; Becker-Kornstaedt, U.;Decker, B.;Klotz, A.;Leopold, E.; Rech, J.; Voss, A.: The indiGo Project: Enhancement of Experience Management and Process Learning with Moderated Discourses. In P. Perner (Ed.), Data Mining in Marketing and Medicine, Springer Verlag, LNCS, 2002.

[Alth+01] Althoff, K.-D., Decker, B., Hartkopf, S., Jedlitschka, A., Nick, M. Rech, J.: Experience Management: The Fraunhofer IESE Experience Factory. In P. Perner (ed.), Proc. Industrial Conference Data Mining, Leipzig, Institut für Bildverarbeitung und angewandte Informatik, July 2001, pp. 24.-25.

[ArSc78] Argyris, Chris; Donald A., Schön: Organizational Learning: A theory of action perspective, Addison Wesley, Reading, Mass, 1978

[AnPf02] Angkasaputra, N.; Pfahl, D.: The CORONET System - A Methodology-Driven Infrastructure for Collaborative Learning at the Workplace. Proc. of LLWA2002 (ILLS), Hannover, Germany, http://www.iese.fhg.de/coronet/documents/ publications/pub_coronet_ills02.pdf, 2002, Link checked on 21.1.2003.

[ARIS03] ARIS collaborative suite. IDS-Scheer AG, http://www.ids-scheer.com/ link checked on 22.1.2003

[Basi+94] Basili, V.R.; Caldiera, G.; Rombach, D.: Experience Factory. In Marciniak, J.J. ed., Encyclopedia of Software Engineering, vol 1, John Wiley & Sons: 1994, pp. 469-476.

[Beck+99] Becker-Kornstaedt, U.; Hamann, D.; Kempkens, R., Rösch, P.; Verlage, M.; Webby R.; Zettel, J.: Support for the Process Engineer: The Spearmint Approach to Software Process Definition and Process Guidance. In Proceedings of the 11th Conference on Advanced Information Systems Engineering (CAISE '99), Heidelberg, Germany, June 1999. Lecture Notes on Computer Science, Springer­Verlag, 1999.

[Berg01] Bergmann, R.: Experience management - foundations, development methodology, and internet-based applications. Postdoctoral thesis (Habilitations-Schrift), Department of Computer Science, University of Kaiserslautern, 2001.

[BiTa98] Birk, A.; Tautz, C. : Knowledge Management of Software Engineering Lessons Learned In Proc. of the 10th Conference on Software Engineering and Knowledge Engineering (SEKE'98), San Francisco Bay; USA. 1998.

[Bria+99] Briand, L.; Bunse, C.; Daly, J: A Controlled Experiment for Evaluating Quality Guidelines on the Maintainability of Object-Oriented Designs, ISERN Technical Report, 99-07, Kaiserslautern, 1999

[Comp03] Compendium. Compendium Institute, http://www.compendiuminstitute.org/ tools/compendium.htm, link checked 22.1.2003

[Feld+00] Feldmann, R. L.; Frey, M.; Habetz, M.; Mendonca, M.: Applying Roles in Reuse Repositories. In Proceedings of the Twelfth Conference on Software Engineering and Knowledge Engineering, Kaiserslautern, Germany, July 2000. Knowledge Systems Institute, Skokie, Illinois, USA, 2000.

[D3E03] Digital Document Discourse Environment (D3E), http://d3e.sourceforge.net/, link checked on 22.2.2003

[Deck+01] Decker, B.; Althoff K.-D,; Nick, M.; Jedlitschka, A.; Rech, J.: Corporate Information Network (CoIN): Experience Management at IESE. In Proceedings of Knowtech 2001 conference, http://www.community-of-knowledge.de/pdf/f27.pdf, 2001, Link checked on 21.1.2003.

[Deck03] Decker, B.: IndiGo: Fallstudie Prozesseinführung (to appear, German), indiGo Fallstudie http://www.iese.fhg.de/Projects/indigo 2003, Link checked on 11.5.2003.

[GoKa97] Gordon, T.F.; Karacapilidis N.: "The Zeno Argumentation Framework.". In Proceedings of the Sixth International Conference on Artificial Intelligence and Law, 1997, pp. 10-18.

[HaWa99] Haake, J. M.; Wang, W.: Flexible Support for Business Processes: Extending Cooperative Hypermedia with Process Support. In: Information and Software Technology, Vol. 41, No. 6, pp. 355-366, 1999. ftp://ftp.darmstadt.gmd.de/pub/concert/ publications/IST98.pdf, link checked on 21.1.2003.

[Joac98] Joachims, T.: Text categorization with Support Vector Machines: Learning with many relevant features. In Proc. of 10th European Conference on Machine Learning (ECML 98), LNCS 1398, Springer Verlag, 1998. pp137-142.

[Kell+98] Kellner, M. I.; Becker-Kornstaedt, U.; Riddle, W. E.; Tomal, J. Verlage, M.: Process Guides: Effective Guidance for Process Participants. In Proceedings of the Fifth International Conference on the Software Process, Chicago, IL, USA, June 1998. ISPA Press. pp. 11­25.

[Kind+01] Kindermann, J.; Paaß, G.; Leopold, E.: Error Correcting Codes with Optimized Kullback-Leibler Distances for Text Categorization. In Proceedings of the European Symposium on Principles of Data Mining and Knowledge Discovery (PKDD'01); 3-7 September 2001 in Freiburg, Germany.

[Koho01] Kohonen, T.: Self-organizing maps. Springer: Berlin, Heidelberg, New York, 2001.

[Kolo93] Kolodner, J. L.. Case-Based Reasoning. Morgan Kaufmann, 1993.

[LeKi02] Leopold, E.; Kindermann, J.: Text Categorization with Support Vector Machines. How to Represent Texts in Input Space? in: Machine Learning 46, pp. 423 - 444, 2002.

[Märk+02] Märker, O., Hagedorn, H., Trénel, M. and Gordon, T. F.: Internet-based Citizen Participation in the City of Esslingen. Relevance - Moderation - Software. In M. Schrenk (ed) CORP 2002 - "Who plans Europe's future?" Wien: Selbstverlag des Instituts für EDV-gestützte Methoden in Architektur und Raumplanung der Technischen Universität Wien, 2002.

[Mehl02] Mehler, A.: Hierarchical analysis of text similarity data. In: Joachims T.; Leopold E. (eds.): Künstliche Intelligenz 2/02, Schwerpunkt Textmining, pp. 12-16, 2002.

[Merk97] Merkl, D.: Exploration of Document Collections with Self-Organizing Maps: A Novel Approach to Similarity Representation, a novel approach to similarity visualization. In Proceedings of the European Symposium on Principles of Data Mining and Knowledge Discovery (PKDD'97), Trondheim, Norway. June, 1997.

[Moc97] Management of Change: Erfolgsfaktoren und Barrieren, Internationales Institut für lernende Organisation und Innovation, 1997

[Scot03] Scott, L.: EPG/ER Empirical Evaluation Method. Technical Report of the University of New South Wales http://www.caeser.unsw.edu.au/publications/ pdf/Tech02_4.pdf, link checked on 22.3.2003.

[ScBe01] Scott, L.; Jeffery, D.R.; Becker-Kornstaedt, U.: Preliminary Results of an Industrial EPG Evaluation. In Maurer, F.; Dellen B.; Grundy J.; Koetting B. (eds.), Proc. 4th ICSE Workqshop on Software Engineering over the Internet, Toronto, Canada, 12-19 May. 2001. IEEE Computer Society, California, USA, pp55-58. 2001.

[Shes01] Sheskin: Handbook of parametric and non-parametric statistical procedures (2nd edition), 2001

[Tau00] Tautz, C: Customizing Software Engineering Experience Management Systems to Organizational Needs. Doctoral Dissertation, Department of Computer Science, University of Kaiserslautern, Germany, 2q000.

[Tu+99] Turoff, M.; Hiltz, S. R;, Bieber, M.; Fjermestadt, J.; Ajaz, R.: Collaborative discourse structures in computer-mediated group communications. Journal of Computer-Mediated Communication, 4, 1999.

[Prosci02] Prosci 2002 Change Management benchmark report, http://www.prosci.com/mod1.htm, Last visited June 2003

[vHun00] von Hunnius, J.-P. (2000). WESPI - Web Supported Process Improvement. In Althoff, K.-D.; Müller W. (eds.), Proc. 2nd International Workshop on Learning Software Organizations, June 20, 2000, Oulu, Finland, Fraunhofer IESE, Kaiserslautern, Germany, 2000.

[Voss+02] Voss, A.; Roeder, S.; Wacker, U. (to appear): IT-support for mediation in decision making - A role playing experiment. In Märker, O. Trenél, M. (eds.): Online-Mediation. Theorie und Praxis computer-unterstützter Konfliktmittlung. Sigma, Berlin, 2002.