2 projekt M A N A G E M E NT 2/ 20 07 aktuell Einleitung Da ein Projekt per Definition ein Vorhaben ist, das im Wesentlichen durch die Einmaligkeit seiner Bedingungen gekennzeichnet ist, ist nicht ohne Weiteres klar, wie und mit welchem Mehrwert sich Erfahrungen oder Wissen von einem Projekt auf ein anderes übertragen lassen. Das gilt unabhängig davon, ob das Projekt die Unternehmensziele unterstützen soll, zum Beispiel die Einführung einer CRM-Software bei einem Handelsunternehmen, oder den eigentlichen Unternehmenszweck darstellt, zum Beispiel als Beratungsprojekt einer Technologieberatung. In jedem Fall hängt der Erfolg eines Projektes entscheidend von den beteiligten Personen, wie Projektmitarbeitern, Projektmanagern oder dem Entscheidungsgremium, ab. Die hinter diesen Rollen stehenden Personen nehmen im Laufe ihrer Firmenzugehörigkeit mit großer Wahrscheinlichkeit nicht an jedem ähnlich gearteten Projekt teil. Die Speicherung und Wiederverwendung von in der Organisation bereits vorhandenem Wissen zur Projektdurchführung sind aus diesem Grund nicht nur von Vorteil, sondern dringend notwendig, wenn das Unternehmen effizient arbeiten möchte. Dabei lassen sich gemachte Erfahrungen gewinnbringend in jeder Projektphase sichern, insbesondere gegen Ende des Projektes ist eine Aufarbeitung des Projektverlaufs und der Projektinhalte angebracht. Das Beispiel der großen Unternehmensberatungen zeigt sehr deutlich, dass Erfahrungssicherung ein wesentliches Element für den Unternehmenserfolg sein kann, wenn sie entsprechend umgesetzt wird. 2 IT-Projektmanagement und die Notwendigkeit zur Sicherung von Erfahrungen Im Folgenden werden einige Besonderheiten von IT-Projekten aufgelistet, die deren besondere Komplexität verdeutlichen und die Sicherung von Erfahrungen notwendig erscheinen lassen. 2. Gesunkene IT-Budgets Nach der Beendigung der Boomphase im Jahr 2000 haben sich IT-Budgets jahrelang stetig nach unten entwickelt. [1, S. 1]. Mittlerweile haben sich die Budgets wieder erhöht [2, S. 1], aber die lange Phase sinkender Budgets zwischen 2000 und 2005 hat Spuren hinterlassen, denn die Geschäftsleitung eines Unternehmens interessiert sich nun stärker für das Kosten-Nutzen-Verhältnis eines Projektes. Es ist in zunehmendem Maße wichtig, den „Business Value“ eines IT-Projektes durch Wirtschaftlichkeitsrechnung nachzuweisen und ihn anschließend im Rahmen des Projektmanagements auch zu erreichen. 2.2 Komplexität der IT-Integration Die Schnittstellen, die ein neues IuK-System zu bedienen hat, werden aufgrund der gewachsenen IT-Landschaften in den Unternehmen immer zahlreicher. Gleichzeitig gewinnt die IuK-Technologie zunehmend an Bedeutung, da sie nicht nur eine unterstützende Funktion von Geschäftsprozessen übernimmt, sondern diese erst ermöglicht. Der geschäftliche Erfolg eines Unternehmens hängt daher in Zukunft verstärkt davon ab, ob die IT diese Enabling-Funktion zuverlässig erfüllt. 2.3 Bedeutung der Qualität in IT-Projekten Bedenkt man, welche gravierenden Folgen fehlerhafte Software oder fehlerhaft arbeitende Systeme unter Umständen haben können, so wird klar, dass Qualität ein wesentlicher Aspekt der Bewertung von IuK-Projekten sein muss [3, S. 1]. Die Explosion von Ariane 5 im Jahr 1996 aufgrund eines Programmierfehlers ist hier eines von vielen Beispielen. Verantwortliches IT-Projektmanagement muss sich deshalb auch an der Qualität seiner Leistungen messen lassen. Für Deutschland ermittelte die LOT Consulting im Jahr 2000, dass 36 Prozent der IT-Budgets für die Beseitigung von Fehlern in Software ausgegeben Erfahrungssicherung in IT-Projekten Ein Prozessvorschlag zur Sicherung von Erfahrungen aus IT-Projekten Marko Hunger IT-Projekte sind ein Dauerthema in der Fachliteratur, weil sie fast jeden Unternehmensbereich betreffen und häufig nicht das gewünschte Ergebnis liefern. Trotz zahlreicher Versuche, die Erfolgsquoten deutlich zu steigern, scheitern nach wie vor viele Projekte. Der vorliegende Artikel, der auf einer Dissertation mit dem gleichen Titel basiert, möchte einen Beitrag dazu leisten, diesen Missstand zu beseitigen, und stellt zu diesem Zweck auf die systematische Sammlung von Erfahrungen aus vorhergehenden IT-Projekten ab. Es wird ein Modellvorschlag unterbreitet, der aus drei Teilprozessen besteht, die unabhängig voneinander ablaufen können, sich aber auch sinnvoll zu einem Gesamtprozess integrieren lassen. 22 WISSEN aktuell projekt M A N A G E M E NT 2/ 20 07 wurden. Daraus ergab sich für Mittelstands- und Großunternehmen ein Schaden von damals 28 Milliarden DM. Außerdem musste nach dieser Untersuchung die Gesamtwirtschaft in Deutschland Verluste in Höhe von 137 Milliarden DM durch Systemausfälle und die damit verbundene Minderung der Produktivität hinnehmen [4, S. 1]. 2.4 Unternehmenszusammenschlüsse Bei Fusionen und Unternehmenskäufen könnte unter anderem die vergessene Betrachtung technologischer Aspekte in den vormals getrennten Unternehmen ein Grund für die hohe Misserfolgsrate sein [5, S. 34]. Doch auch bei einem erfolgreichen Unternehmenszusammenschluss müssen innerhalb kürzester Zeit die IT-Strukturen so zusammengeführt werden, dass der Betriebsablauf in beiden Unternehmen nicht gestört wird. Erschwerend kommt hinzu, dass das eigentliche IT-Projekt inmitten von anderen Projekten, wie beispielsweise der Entwicklung von neuen Produkten, abläuft. Statt eines Einzelprojekts ist deshalb ein ganzes Portfolio an Projekten abzuwickeln. Ähnlich verhält sich die Situation bei virtuellen Unternehmen, bei denen eine komplexe IuK-Technologie überhaupt erst die Arbeitsfähigkeit der Organisation ermöglicht [6, S. 496]. 2.5 Verändertes Software-Engineering Sowohl in kleinen Firmen als auch bei großen Unternehmen wird in steigendem Maße auf Standardstatt auf Individualsoftware gesetzt. Die Struktur der IT-Projekte hat sich deshalb geändert, da für den Kauf meist unabhängige Institute oder Unternehmensberatungen mit einbezogen werden. Das IT-Projektmanagement muss diese größere Anzahl an Stakeholdern erfolgreich einbinden. Ebenso führt bei der objektorientierten Softwareentwicklung ein sehr intensiver Abstimmungsprozess mit den Kunden zur Notwendigkeit eines kontinuierlichen Projektmanagements [7, S. 28]. 3 Inhalte der Erfahrungssicherung Versteht man ein IT-Projekt als soziotechnisches System, in dem die Elemente Mensch, Technik und Aufgabe zusammentreffen, ergeben sich die möglichen Inhalte für eine Erfahrungssicherung. Zum einen sind dies alle Arbeits-, Kommunikations- und Entscheidungsprozesse, die sich im Rahmen der Zusammenarbeit im Projekt ergeben. Zum anderen ist dies das technische Wissen, das zur Inbetriebnahme eines produktiven IuK-Systems erforderlich ist. In einer Gesamtübersicht können demnach in IT-Projekten die Lernfelder der Abb. 1 bestimmt werden. Es ist zunächst davon auszugehen, dass die Inhalte aller Lernfelder personales Wissen, also das Wissen einer einzelnen Person, darstellen. Der Übergang von personalem zu organisationalem Wissen vollzieht sich, wenn geeignete Wissensbestandteile in Routinen, Standardprozesse oder die Unternehmenskultur eingehen. Prinzipiell lassen sich Erfahrungen in allen angesprochenen Lernfeldern sichern, wobei Aufwand, Nutzen und Verfahren unterschiedlich sind. Insbesondere der Nutzen, den man sich von einer Erfahrungssicherung erwartet, ist davon abhängig, wie lange die gesicherten Inhalte ihre Gültigkeit behalten. Eine Sicherung kann dabei in Textform, bildlich oder mündlich erfolgen. Sicherungsdokumente in Textform sollten einfach, übersichtlich, kurz sein und zusätzliche Anreize, wie Beispiele und Analogien, verwenden [8, S. 142]. Eine bildliche Sicherung wird nur in Ausnahmenfällen als Filmdokument erfolgen, häufiger dürfte die Einbettung von Grafiken in Texte sein. Eine mündliche Sicherung kann dadurch geschehen, dass vorhandenes personales Wissen auf eine möglichst breite Basis gestellt wird. Durch die Kommunikation und Interaktion verschiedener Organisationsmitglieder kann eine solche Sicherung erfolgen. Dadurch wird es entweder zu einem von allen geteilten Wissen und gehört damit zur Unternehmenskultur (organisationales Wissen) oder es gibt zumindest mehrere Personen, die danach über dieses Wissen verfügen (personales Wissen). Der Prozess des Erfahrungsaustausches entspricht damit gleichzeitig einer Wissensbewahrung und Wissensverteilung. Außer den Inhalten und Darstellungsformen einer Sicherung lassen sich auch die Prozessformen einer Sicherung unterscheiden. 4 Prozessformen der Sicherung 4. Kooperative Projektevaluierung Ein möglicher Prozessansatz ist die kooperative Projektevaluierung. Dazu erstellt ein externes Team aus Interviews mit Projektbeteiligten einen Ergebnisbericht, der Kommunikationsprozesse Mensch Aufgabe Technik - Besprechungen gestalten - Workshops durchführen - Ergebnisse präsentieren - Team motivieren - Konflikte lösen - Stakeholder einbinden - Projekt vermarkten Entscheidungs- und Arbeitsprozesse - Projekt definieren - Team zusammenstellen - Projekt planen - Aufgaben gliedern - Ressourcen steuern - Projektphasen beenden - Erfolgsfaktoren verfolgen Produktwissen - Konzepte entwickeln - Lastenheft erstellen - Angebote bewerten - Software entwickeln - Prototypen bauen - Pilotprojekte aufsetzen - Software konfigurieren Abb. 1: Lernfelder in IT-Projekten 23 projekt M A N A G E M E NT 2/ 20 07 aktuell anschließend in einer gemeinsamen Sitzung mit allen Projektbeteiligten diskutiert wird. Dieser gemeinsame Workshop ist also über alle Hierarchiestufen und Funktionsbereiche besetzt und führt dazu, dass man „die enge Verknüpfung der jeweiligen Perspektiven mit den funktionalen und persönlichen Interessen behandelt.“ [9, S. 249] 4.2 Projektreviews Eine zweite Möglichkeit, Erfahrungen im Rahmen des Projektmanagements zu sammeln, besteht in der Durchführung von Projektreviews, die der Ermittlung von Mängeln im Projektmanagement und der Dokumentation eines ordnungsgemäßen Ablaufs dienen. Sie werden orientiert an wichtigen Ereignissen, zum Beispiel dem Erreichen von Meilensteinen, und/ oder am Projektende durchgeführt und von einem teamunabhängigen Projektrevisor oder Gutachter begleitet [10, S. 316]. Dadurch haben sie den Vorteil, dass sie zeitnah zu den relevanten Ereignissen im Projekt stattfinden und deshalb gesammelte Erfahrungen bereits im laufenden Projekt zu positiven Veränderungen führen können. Diese Prozessorganisation ermöglicht ein schnelles Eingreifen in das aktuelle Projektgeschehen, wobei der Schwerpunkt eines Projektreviews bzw. einer -revision eher auf der Überprüfung von harten Fakten, also von Kosten, Terminen oder Qualität, liegt, sodass eine Erfahrungssammlung zur Kooperation im Projekt oder die Stärkung des Vertrauensverhältnisses unter den Beteiligten nicht erfolgt [10, S. 316]. Wird ein Review dagegen mit dem Ziel durchgeführt, neben Leistungsdaten auch Prozesse zu bewerten, kollektives Wissen zu sammeln oder Schaden am Team zu reparieren, dann bietet sich ein Termin nach dem Projektende an, weil die entsprechenden Erfahrungen erst dann im vollen Umfang vorliegen [11, S. 83]. Eine Variante dieses Verfahrens stellen schlanke Projektreviews dar, bei denen möglichst alle der am Projekt Beteiligten für einen halben Tag in einem Raum versammelt werden und man anschließend per Kärtchenabfrage die positiven und negativen Aspekte Revue passieren lässt. 4.3 Lessons-learned-Methode Eine dritte Möglichkeit der prozessualen Gestaltung ergibt sich mit der „Lessons-learned-Methode“. Zunächst werden dabei in einem Brainstorming vom gesamten Projektteam wichtige Lernfelder ermittelt. Als Leitfaden dazu dienen Fragen nach den Erfolgen und Misserfolgen im Projekt oder nach der Kommunikation und der Zusammenarbeit im Team und mit Stakeholdern. Anschließend werden zu den so ermittelten Aspekten des Projekts in kleinen Gruppen von zwei bis vier Personen sogenannte „Lessons learned“ erarbeitet. Sie beschreiben die Erfahrungen aus der Projektarbeit und beinhalten konkrete Empfehlungen für zukünftige Projekte. Neben dieser gemeinschaftlichen Aufgabe des Projektteams muss der Projektleiter im Rahmen der „Lessons learned“ auch seine eigenen Schätzungen bezüglich der harten Faktoren Zeit, Kosten, Qualität und bezüglich der weichen Faktoren wie Kommunikation und Partizipation kritisch hinterfragen. Insbesondere soll er seine eigene Rolle im Projekt, zum Beispiel die Rolle als Führungskraft mit Vorbildfunktion, reflektieren. Als Zeitpunkt sowohl für die Reflexion im Team als auch für die des Projektleiters wird das Ende einzelner Projektphasen, zumindest jedoch das Projektende genannt [12, S. 111 f.]. Neben diesen grundsätzlichen Überlegungen zur Erfahrungssicherung in IT-Projekten konnten im Rahmen der oben erwähnten Dissertation folgende Aspekte ermittelt werden. 5 Istzustand der Erfahrungssicherung in IT-Projekten 5. Untersuchungsergebnisse im Rahmen des International Project Management Award Es wurden 16 IT-Projekte, die im Rahmen des International Project Management Award zur Begutachtung eingereicht worden waren, auf die Handhabung der Erfahrungssicherung untersucht. Die Begutachtung erfolgte dabei mithilfe des Modells Project Excellence, das von der GPM Gesellschaft für Projektmanagement e. V. entwickelt wurde und als projektbezogene Variante des European Quality Award gesehen werden kann. Es lassen sich aus den Bewerbungsunterlagen und den zugehörigen Bewertungen drei übergeordnete Defizite in der Erfahrungssicherung ermitteln: o Vorhandene Dokumente und Unterlagen werden nicht aufbereitet oder sie werden nicht so aufbereitet, dass man sie unabhängig von Personen nutzen könnte. o Die gesammelten Erfahrungen werden nicht konsequent zu einer Verbesserung der Organisation und der Wettbewerbsfähigkeit genutzt. o Es gibt keinen systematischen Prozess, der die Sicherung von Projekterfahrungsdaten abbildet. Bei einer durchschnittlichen Bewertung von 50 Prozent beim Kriterium „Erfahrungssicherung“ sind noch viele Verbesserungen möglich. Sie betreffen vor allem die zweckmäßige Aufbereitung von Projektunterlagen und den systematisch organisierten Ablauf der Erfahrungssicherung. Zudem bestehen Defizite in der Nutzung der so fixierten Erfahrungen. Es bestätigt sich damit, dass das Nutzenpotenzial einer Erfahrungssicherung bei Weitem nicht ausgeschöpft wird. ' 2005 www.first- Projektmanagement Wenn es einen Weg gibt, etwas besser zu machen, finde ihn. T. A. Edison Beratung - Hilfe zur Selbsthilfe Fach- und Methodenberatung bis zur erfolgreichen Umsetzung Ihr Ansprechpartner: david.barcklow@ibo.de Software - ibo netProject effiziente und pragmatische Plattform für alle Projekte Ihr Ansprechpartner: kai.steinbrecher@ibo.de Training - Projektleiter mit ibo-Zertifikat Reihen, Modular, Blended Learning, internationale Zertifizierung Ihre Ansprechpartnerinnen: Barbara Bausch , Heike Borschel training@ibo.de ibo Beratung und Training GmbH ibo Software GmbH Im Westpark 8 | D-35435 Wettenberg T: +49 641 98210-00 F: +49 641 98210-500 ibo@ibo.de | www.ibo.de Anzeige 24 WISSEN aktuell projekt M A N A G E M E NT 2/ 20 07 5.2 Untersuchungsergebnisse bei weiteren IT-Projekten Eine weiter gehende Untersuchung wurde in insgesamt acht Unternehmen aus unterschiedlichen Branchen durchgeführt. Dabei wurden insgesamt vier verschiedene Sichten - eine Funktions-, eine Daten-, eine Organisations- und eine Systemsicht - auf die Handhabung der Erfahrungssicherung angelegt. Aus der Datensicht ergibt sich folgendes Bild: Eine Grundlage für die Ableitung von Erfahrungen bezüglich der harten Projektziele Zeit, Kosten, Qualität ist in jedem der Projekte vorhanden. In Berichten, Fortschrittspräsentationen und Abschlussberichten ist das Faktenwissen des Projekts gespeichert und elektronisch in Verzeichnissen abgelegt. Außer bei diesem Faktenwissen erfolgt eine schriftliche Fixierung von Erfahrungen kaum und wird auch nicht verpflichtend eingefordert. Fehler bei der Entwicklung bzw. beim Customizing von Software werden zwar festgehalten, aber nicht bis zum einzelnen Mitarbeiter zurückverfolgt. Aus Organisationssicht kann festgehalten werden: In nur zwei von acht Projekten ist eine Rolle zur nachträglichen Beurteilung und damit einer institutionalisierten Auswertung von Erfahrungen des Projektes vorgesehen. In allen anderen Projekten beschränken sich die Rollen auf die übliche Teilung in Entscheidungsgremium, Projektleiter, Teilprojektleiter und Mitarbeiter mit fachbezogenen Aufgaben. Die Projektbesetzung erfolgt vor allem nach der Erfahrung der Mitarbeiter. Die Arbeitsverteilung wird überlappend gestaltet. Auf diese Weise entstehen eingespielte Teams, die Know-how-Verluste in begrenztem Umfang ausgleichen können. Des Weiteren zeigt sich, dass personelle Veränderungen in Projekten eher die Regel als die Ausnahme sind. Nur selten ist damit kein Know-how-Verlust verbunden. Als Folgerung daraus sollte eine Sicherung von Erfahrung nicht nur auf das Ende des Projektes beschränkt sein. Aus Systemsicht wurden folgende Aussagen gewonnen: Die Verarbeitung und Speicherung von Erfahrungen aus dem Projekt erfolgen in Textform durch das Erstellen und Speichern von Dokumenten. Die Dokumente stellen Faktenwissen dar und beschreiben das explizite Wissen, das in den Projekten gewonnen wird. Zum überwiegenden Teil sind diese Dokumente in einer Dateiorganisation abgelegt, weshalb das Wiederauffinden ohne eine Suchmaschine und die Versionsverwaltung der Dokumente problematisch ist. Die verwendeten Systeme sind in allen Projekten annähernd gleich. Die Systemunterstützung wird von der Mehrzahl der Interviewpartner als ausreichend für eine Erfahrungssicherung erachtet. Die Betrachtung der Erfahrungssicherung aus Funktionssicht lieferte folgende Erkenntnisse: Tätigkeiten zur Erfahrungssicherung sind kaum formal geregelt. Das gilt auch für Unternehmen mit einem Projektmanagementsystem. In großen Unternehmen mit einer entsprechenden Aufbauorganisation (Portfoliosteuerung bzw. Organisationsentwicklung) hat eine Erfahrungssicherung einen größeren Stellenwert als in kleineren Unternehmen. In der Projektplanung werden meist keine Zeiten für eine Erfahrungssicherung reserviert. Die Projektmitarbeiter sind bei einer Erfahrungssicherung nur zu einem sehr geringen Anteil involviert. Trotz dieser Tatsache sind die Projektleiter davon überzeugt, dass in ihrem Projekt eine offene Projekt- und Fehlerkultur herrscht. Jeder Mitarbeiter macht seine persönlichen Erfahrungen, ohne seine subjektive Sicht mit anderen abzustimmen und ohne sie schriftlich festzuhalten. Das Projektwissen liegt deshalb überwiegend in personengebundener Form vor. Eine Aufbereitung von Dokumenten zum Zweck der Wiederbzw. Weiterverwendung findet selten statt. Ebenso wenig erfolgt eine systematische Suche nach wiederverwendbaren Ressourcen. Die Untersuchung der acht IT-Projekte ergab, dass in keiner der Organisationen ein umfassender Geschäftsprozess zur Erfahrungssicherung definiert ist, auch wenn der Umfang der Maßnahmen, die in den einzelnen Projekten ergriffen wurden, erheblich differiert. Dieser Umstand zeigt sich sowohl in den einzelnen Sichten, die man auf die vorhandenen Prozesse legen kann, als auch in den Rahmenbedingungen, die einen solchen Prozess begleiten. Im Abschnitt 6 werden die bisherigen Ergebnisse zur Entwicklung eines Modellprozesses der Erfahrungssicherung verwendet. 6 Modellprozess der Erfahrungssicherung Grundsätzlich soll bei der Erfahrungssicherung ein Wissensaustausch zwischen einem Projekt und der Betriebsorganisation stattfinden. Um das grundlegende Ziel mit angemessenem Aufwand zu erreichen, ist es notwendig, die Inhalte, die Zeitpunkte und die Intensität einer Erfahrungssicherung dem jeweiligen Projektfortschritt anzupassen. So, wie es keinen allgemeingültigen Phasenplan für die Durchführung eines IT-Projekts gibt, kann es auch nicht einen für alle IT-Projekte gültigen Prozess der Erfahrungssicherung geben. Aus diesem Grund wird hier ein Modell bestehend aus drei Teilprozessen vorgeschlagen. Die Teilprozesse können unabhängig voneinander ablaufen, lassen sich aber auch sinnvoll zu einem Gesamtprozess integrieren. Der Gesamtprozess muss einfach, personalisiert und zeitlich verteilt sein. Der Prozess soll einfach sein, weil der hohe Zeitdruck in Projekten dies notwendig macht. Der Prozess soll personalisiert sein, weil explizite Erfahrungen mit den im Projekt erstellten Berichten, Präsentationen und Dokumentationen ohnehin schon festgehalten werden. Gleichzeitig lässt sich der implizite Teil der Projekterfahrungen nicht in Form von Dokumenten und sonstigen Artefakten festhalten, sodass tendenziell ein Übergewicht zugunsten der Sicherung von expliziten Inhalten besteht. Der Prozess soll zeitlich verteilt ablaufen, weil bei längeren Projekten Erfahrungen vergessen werden und die Bereitschaft und die Fähigkeit, die Gesamtaufgabe in einem Zug am Ende des Projekts zu erledigen, gering einzuschätzen sind [13, S. 165]. Ähnlich ist die Situation, wenn während des Projekts Personen ungeplant ausscheiden. Aus diesen Gründen ist zwischen einer Sicherung während der Projektlaufzeit und einer Sicherung zum Projektende zu unterscheiden. Beide Male lassen sich sowohl Fakten- oder explizites Wissen als auch Prozesserfahrungen sichern. 6. Sicherung von Faktenwissen zur Projektlaufzeit Zur Sicherung von Faktenwissen während der Projektlaufzeit wird vorgeschlagen, nach dem Abschluss jeder 25 projekt M A N A G E M E NT 2/ 20 07 aktuell Projektphase die Tätigkeiten der Abb. 2 durchzuführen [10, S. 277]: Mit diesen Tätigkeiten werden zum einen die Leistungsdaten, also die harten Fakten aus dem Projekt, dokumentiert. Zum anderen werden durch die Strukturierung und Aufbereitung der übrigen Dokumente verschiedene Bruchstücke des Projekts in einem Gesamtbild zusammengefasst [11, S. 66 f.]. Diese beiden Teile der Erfahrungssicherung können später in einer Teamsitzung als Stütze bei der Rekonstruktion des Projektverlaufs verwendet werden. Die Ergebnisse dieser phasenweisen Erfahrungssicherung sind nicht an bestimmte Personen gebunden und enthalten keine sensiblen Daten mehr, die nicht veröffentlicht werden sollen. Deshalb ist eine Verteilung dieses dokumentierten Wissens auch über größere Bereiche oder das gesamte Unternehmen möglich. Welche Rollen/ Personen, Daten und Systeme dazu verwendet werden, ist im Einzelfall zu entscheiden. 6.2 Sicherung von Prozesserfahrungen zur Projektlaufzeit Neben der Sicherung von Faktenwissen ist während der Projektlaufzeit auch die Sicherung von Prozesserfahrungen, die im Laufe des Projekts gemacht wurden, sinnvoll. Die Wahrnehmung der Projektsituation ist zunächst auf einzelne Personen beschränkt. Für das Projektteam als Einheit müssen deshalb die Eindrücke der einzelnen Projektmitglieder in einer gemeinsamen Teamsitzung zur Erfahrungssicherung zusammengeführt werden [11, S. 136]. Durch die Kommunikation/ Interaktion im Team werden Sachverhalte aus mehreren Perspektiven wahrgenommen und in ihrer gesamten Tragweite erkannt. Dabei wird durch eine große Teilnehmergruppe der Gefahr vorgebeugt, dass die bisherigen persönlichen Überzeugungen die Wahrnehmung des Sachverhalts einseitig beeinflussen. Der Einzelne lernt im Zuge dieser Kommunikation/ Interaktion, weil er die Möglichkeit erhält, sein persönliches Wissen um die explizit geäußerten Wissensbestandteile der übrigen Projektmitglieder zu vergrößern. Je intensiver die Kommunikation des Projektteams, desto größer ist die Chance, auch implizites Wissen auf diesem Wege auf andere Projektmitglieder zu übertragen und damit die Wissensspirale nach Nonaka/ Takeuchi in Gang zu setzen [14, S. 90]. In diesem Sinne erfolgt eine Erweiterung der personalen Wissensbasis im Unternehmen durch die Verteilung von individuellem Wissen auf mehrere Personen. Gleichzeitig findet organisationales Lernen statt, denn die einzelnen Teammitglieder stellen der Organisation bisher noch nicht geteiltes Wissen zur Verfügung. Aus der Abstimmung der einzelnen Sichtweisen entstehen im Idealfall neue Routinen, Geschäftsprozesse oder Regeln, die die organisationale Wissensbasis des Unternehmens erweitern. Beispiele dafür wären neue Standards im Berichtswesen oder Regeln für eine effizientere Besetzung der Projektgremien. Bedeutungsvolle Dialoge und Metaphern, die das implizite Wissen zu IT-Projekten in nachvollziehbare Sinnbilder fassen, können sich im Laufe dieser Teamsitzungen entwickeln. Deshalb entspricht eine solche Teamsitzung zur Erfahrungssicherung, wenn sie regelmäßig erfolgt, einem betrieblichen Standardprozess zur Konversion von implizitem und explizitem Wissen [14, S. 71]. Der externalisierbare Teil der Erfahrungen, die im Zuge dieser Kommunikation ausgetauscht wurden, lässt sich schriftlich fixieren und so der Betriebsorganisation zur Verfügung stellen. Der implizite Teil des Wissens aus dem Projekt kann dagegen nur gesichert werden, wenn er aus dem Projektteam heraus durch Kommunikation und Interaktion auf andere, unbeteiligte Organisationsmitglieder verteilt wird. Dazu ist die Vorstellung der Prozesserfahrungen vor einem größeren Gremium notwendig. Leitfragen: - Sind die wesentlichen Ergebnisse berücksichtigt? - Sind die Dokumente notwendig für das Projektverständnis? Leitfragen: - Sind die Dokumente kurz und selbsterklärend? - Sind sie übersichtlich gegliedert? - Sind sie ansprechend gestaltet? Leitfragen: - Ist der zeitliche Zusammenhang erkennbar? - Ist der logische Zusammenhang erkennbar? Relevante Dokumente auswählen Ausgewählte Dokumente aufbereiten Aufbereitete Dokumente strukturieren Abb. 2: Funktionen zur Sicherung von Faktenwissen Le Bihan Consulting GmbH . Heinrich-Hertz-Straße 2 . D-65232 Taunusstein . Tel. +49 6128 9665-0 . Fax -11 . lebihan.de . leb@lebihan.de Ich interessiere mich für Ihre Projektmanagement-Lösungen und möchte gerne Informationen über folgende Themen: OPX2 PSNext Projektmanagement-Software Service/ Dienstleistung Bitte kontaktieren Sie mich telefonisch unter: ______________________ Bitte schicken Sie mir Unterlagen zu oben genannten Themen. Name: ____________________ Firma: ______________________ St Straße: ____________________ PLZ, Ort: ______________________ eMail: ____________________ GPM 02/ 2007 I nfofax an: 06128-9665-11 Transparente Projekte und Portfolios. Souveräne Entscheidungen. Erfolg ist planbar. Über 20 Jahre Erfahrung bei Beratung und Implementierung von zukunftssicheren und praxisnahen Softwarelösungen. Anzeige 26 WISSEN aktuell projekt M A N A G E M E NT 2/ 20 07 Insgesamt ergeben sich die Tätigkeiten der Abb. 3 für die Sicherung von Prozesserfahrungen. Prinzipiell kommen als Thema einer Phasenretrospektive alle Aspekte der Projektarbeit infrage. Darunter fallen die allgemein anerkannten Erfolgsfaktoren für Projekte, wie beispielsweise die Partizipation und die Zusammensetzung des Projektteams oder die Rolle des Topmanagements bzw. die des Projektleiters. Außerdem gehören die Entscheidungs- und Arbeitsprozesse, die Kommunikationsprozesse und das Produktwissen als potenzielle Lernfelder mit auf die Agenda. Um den Teilprozess einfach zu halten und damit das Projekt zur Laufzeit nicht zusätzlich zu belasten, ist jedoch eine Beschränkung der Teilnehmerzahl und des organisatorischen Aufwands notwendig. Deshalb stehen zwar grundsätzlich alle genannten Themen auf der Agenda einer solchen Phasenretrospektive, um aber den verfügbaren Rahmen nicht zu sprengen, muss eine Auswahl der für das Projekt wichtigsten Punkte erfolgen. Die Ergebnisse dieses Teils der Erfahrungssicherung zielen darauf ab, kollektives Wissen zu sammeln und im gleichen oder in zukünftigen Projekten zur Verfügung zu stellen. Schwerpunktmäßig wird mit einer Retrospektive dieser Art das Ziel verfolgt, die Projektprozesse und die Vorgehensweisen zu verbessern. Durch den Prozess der Sitzung erfolgt eine Verteilung einzelner Erfahrungen auf mehrere Personen, wobei sich Teile davon auch schriftlich fixieren und speichern lassen. 6.3 Sicherung von Erfahrungen am Projektende Für eine projektabschließende Erfahrungssicherung gilt im Prinzip der Prozess, der für die Phasenretrospektiven dargestellt wurde. Da jedoch am Projektende umfassende Erfahrungen aus allen Lernfeldern der Projektarbeit vorliegen und die Zusammenhänge des Projektumfelds in ihrer vollen Komplexität erkennbar sind, muss an dieser Stelle eine besonders gründliche Sicherung stattfinden. Diese Gründlichkeit zeigt sich sowohl in der Wahl der Themen als auch in der Besetzung der abschließenden Projektretrospektive. In einer solchen Retrospektive müssen alle Aspekte, die den Projektverlauf maßgeblich beeinflussen, behandelt werden. Das bedeutet, dass bei Abschluss des Projekts sowohl die harten Fakten als auch die weichen Aspekte der Projektarbeit zur Sprache kommen. Die Ergebnisse dieses Teils der Erfahrungssicherung zielen darauf ab, Wissen abschließend zu sammeln und für zukünftige Projekte zur Verfügung zu stellen. Daneben können mit dieser abschließenden Sitzung auch die Ergebnisse der Phasenretrospektiven überprüft werden. Gleichzeitig besteht die Möglichkeit, die Zusammenarbeit mit den Kunden und den Auftraggebern zu thematisieren. Zusammen mit den Dokumenten, die am Ende der Projektphasen ausgewählt und aufbereitet wurden, entsteht damit ein vollständiges Bild der Projektgeschichte [11, S. 66 f.]. In diesem Sinne unterscheidet sich eine abschließende Projektretrospektive, obwohl die Funktionen denen der Phasenretrospektive entsprechen, in ihrem Umfang und damit auch in der Organisation von Letzterer. 7 Verteilung und Aktualisierung von Erfahrungen 7. Verteilung von Erfahrungen Neben der eigentlichen Sicherung der Erfahrungen im Projektkernteam und mit weiteren Stakeholdern muss gewährleistet werden, dass die gesicherten Erfahrungen auch in der Betriebsorganisation verfügbar werden und so bei Bedarf in neue Projekte zurückgespielt werden können. Dieser Punkt entspricht der Verteilung von Wissen nach Probst et al. und lässt sich prinzipiell auch wiederum nach der Pullbzw. Push-Philosophie umsetzen. Weil das passive Bereithalten von Inhalten in Form von Faktenwissen bzw. Prozesserfahrungen auf einem Server der Umsetzung einer reinen Pull-Philosophie entspricht, wird hier eine Ergänzung durch Maßnahmen zur aktiven Multiplikation der Erfahrungen vorgeschlagen. Diese Ergänzung kann durch Workshops und Vorträge erfolgen, in denen einem Publikum aus der Betriebsorganisation die Inhalte des Projekts und vor allem die Prozesserfahrungen präsentiert werden. Die dazu notwendigen Unterlagen liegen in Form des aufbereiteten Faktenwissens, zum Beispiel als Mikroartikel, bereits vor. Die Vorgehensweise hat einige Vorteile: o Potenzielle Teilnehmer an den Workshops können selbst entscheiden, ob das Thema für sie von Interesse ist. Das Problem einer Informationsüberflutung besteht demnach nicht. o Der Austausch der Erfahrungen basiert auf persönlicher Interaktion, wodurch die Möglichkeit besteht, Folgerungen zu hinterfragen und persönliche Kontakte zu anderen Interessierten zu knüpfen. o Die Motivation der Projektbeteiligten, Erfahrungen zu sichern, steigt, wenn sie wissen, dass sie diese nach Abschluss vor einem Publikum präsentieren sollen. 7.2 Aktualisierung von Erfahrungen Im Laufe der Zeit steigt die Anzahl der auf dem Projektlaufwerk gespeicherten Erfahrungen und es kann nicht Eigene Sichtweise kommunizieren Einzelne Sichtweisen abstimmen Erfahrungen schriftlich fixieren Organisationales Wissen erweitern Personales Wissen erweitern Organisatorischer Rahmen: Teamsitzung am Phasenende Abb. 3: Funktionen einer Phasenretrospektive 27 projekt M A N A G E M E NT 2/ 20 07 aktuell davon ausgegangen werden, dass die dort gespeicherten Inhalte widerspruchsfrei sind. Auf der anderen Seite unterscheiden sich auch die Projekte, die zur Speicherung von Erfahrungen auf dem Laufwerk geführt haben, durch die Einmaligkeit ihrer Bedingungen voneinander. Aus diesem Grund sind vermeintliche Widersprüche jeweils im Projektkontext zu sehen und es ist zu prüfen, ob sie auch vor diesem Hintergrund noch bestehen. Ohnehin erfordert der Abgleich von verschiedenen Erfahrungsdokumenten und deren Verdichtung zu einem Masterdokument eine entsprechende Organisationseinheit, deren Einrichtung nur für besonders know-how-abhängige Organisationen gerechtfertigt erscheint. Unabhängig davon, ob die entsprechenden Inhalte konsistent sind oder nicht, muss für die Bereitstellung auf dem Laufwerk, die Vergabe der Zugriffsrechte und das Löschen von Inhalten eine Zuständigkeit vergeben werden. Diese Tätigkeiten beinhalten jedoch nicht den angesprochenen Abgleich, der beispielsweise darin bestünde, die Mikroartikel verschiedener Projekte unter Beachtung des Projektkontexts miteinander zu vergleichen und eventuell bestehende Widersprüche zu korrigieren. Aus diesen Gründen wird vorgeschlagen, keinen Abgleich von Erfahrungsinhalten durchzuführen, sondern die Aktualisierung der Inhalte im Rahmen der angesprochenen Workshops über das personengebundene Wissen der Teilnehmer vorzunehmen. Ob die gesicherten Inhalte eines IT-Projektes dagegen tendenziell veraltet sind, lässt sich bereits am Namen der Datei erkennen. Trotzdem sollten Erfahrungen nur nach gründlicher Prüfung aus dem Erfahrungsverzeichnis gelöscht werden. Zum einen lässt sich das mit der Tatsache begründen, dass Speicherplatz immer günstiger wird. Zum anderen sind Teile auch nach längerer Zeit noch verwendbar. So kam beispielsweise bei einem untersuchten Projekt gespeichertes Faktenwissen in Form von Testfällen zum Einsatz, das älter als acht Jahre war. 8 Rahmenbedingungen des Prozesses Die drei Teilprozesse, die die Sicherung von Faktenwissen und die Sicherung von Prozesserfahrungen am Phasenbzw. Projektende beschreiben, erfordern in mehrfacher Hinsicht unterstützende Maßnahmen. 8. Aufwerten der Erfahrungssicherung Wenn die Erfahrungssicherung den Rang eines Kann- Ziels hat, besteht grundsätzlich die Gefahr, dass sie aus Zeit- oder Ressourcengründen nicht durchgeführt wird. Deshalb ist eine wesentliche Rahmenbedingung, dass sie eine Aufwertung vom Kannzum Muss-Ziel erfährt. Eine Grundvoraussetzung für einen systematischen Sicherungsprozess, wie er beispielsweise in der DIN 69 904 sinngemäß oder bei Project Excellence explizit gefordert wird, ist deshalb die verbindliche Festschreibung dieses Prozesses. Das kann entweder im Rahmen eines umfassenden Projektmanagementsystems generell oder durch Starten Sie noch heute auf Projectplace.de oder rufen Sie +49 (0)89 970 07 429 für weitere Informationen an. Übernehmen Sie die Kontrolle in Ihrem Projekt! Jederzeit. Überall. 30.000 Projektleiter können sich nicht irren Anzeige 28 WISSEN aktuell projekt M A N A G E M E NT 2/ 20 07 die Aufnahme in den Projektauftrag eines einzelnen Projektes speziell erfolgen. Die Nichtdurchführung der Erfahrungssicherung muss dementsprechend in die Beurteilung des Projektes durch das Management eingehen und umgekehrt sollte die Durchführung entsprechend honoriert werden. Das Projekt insgesamt wird also nicht nur bezüglich seines Erfolgs nach den klassischen Maßstäben beurteilt, sondern auch, inwieweit das Unternehmen aus dem Projekt etwas lernen kann: „Für ein Projekt [ist] der Grad des Erfolgs kein relevantes Maß, wenn Mitarbeiter versuchen, aus ihren Erfahrungen zu lernen.“ [11, S. 152]. 8.2 Bereitstellen von Mitteln Die Verantwortung für das Erreichen des Muss-Ziels Erfahrungssicherung liegt wie bei den anderen Projektzielen auch beim Projektleiter. Aus der Kongruenz von Verantwortung und Kompetenz folgt damit aber auch, dass er die Möglichkeit haben muss, Zeiten für die Erfahrungssicherung einzuplanen und Ressourcen dafür zu binden. Erfahrungssicherung kann in diesem Sinne keine Zusatzaufgabe ohne Zeit und Budget sein. Insbesondere gehören dazu auch Zeiten, die einem Moderator zur Vorbereitung einer Projektretrospektive eingeräumt werden müssen. Darunter fällt beispielsweise eine Abstimmung mit dem Management zu den Erwartungen, die aus dessen Sicht an die Veranstaltung gestellt werden, oder Gespräche mit Teammitgliedern, um Vertrauen bei ihnen aufzubauen und um einen Gesamteindruck von der Projektsituation zu bekommen [11, S. 101 f.]. Wenn man ausgehend von einem fiktiven Modellprojekt mit einer Laufdauer von 180 Tagen den zeitlichen Aufwand für eine Erfahrungssicherung mit zwei Prozent des Budgets ansetzt, dann stehen pro Mitarbeiter ca. 30 Stunden für die Sicherung von Erfahrungen zur Verfügung. Diese Zeit lässt sich beispielsweise mit 16 Stunden (zwei Arbeitstage) für eine Projektretrospektive und zehn Stunden für insgesamt fünf Phasenretrospektiven verwenden. Damit bleiben vier Stunden pro Mitarbeiter für die Sicherung von Faktenwissen. Wenn man unterstellt, dass durch diese Maßnahmen zur künftigen Fehlervermeidung die Mittel zur nachträglichen Fehlerbeseitigung von 36 Prozent auf 30 Prozent des Budgets gesenkt werden können, dann hat sich die Investition bereits im nächsten Projekt amortisiert. 8.3 Erhöhen der Motivation Voraussetzung für die intrinsische Motivation aller Beteiligten ist, dass die Mitarbeiter den Sinn und Zweck der Maßnahmen zur Erfahrungssicherung nachvollziehen können [15, S. 157]. Deshalb müssen die Ziele, die damit verbunden sind, erklärt werden. Aufgaben, wie zum Beispiel die Dokumente aufzubereiten, erscheinen sonst als reine „Fleißaufgabe“. Außerdem ist es erforderlich, von vornherein darauf hinzuweisen, dass eine Erfahrungssicherung im Projekt gemacht wird, wie sie ablaufen soll und wer daran teilnehmen wird [16, S. 23]. Das trägt dazu bei, eventuell vorhandene Ängste und Vorbehalte abzubauen bzw. sie gar nicht entstehen zu lassen: „Schlecht durchgeführte Projektauswertungen können sehr schnell zu Magenbeschwerden führen und dann geht der Lerneffekt gegen null.“ [11, S. 28]. In engem Zusammenhang mit der intrinsischen Motivation stehen die mit Projekten verbundenen, beruflichen Möglichkeiten der Mitarbeiter [17, S. 229]. In einem projektorientierten Unternehmen, in dem ein Karrierepfad als Projektleiter vorhanden ist, lohnt sich für den Einzelnen schon aus Eigennutz eine Erfahrungssicherung. In Unternehmen, die zwar viele IT-Projekte abwickeln, in denen aber die Projekttätigkeit keine Auswirkungen auf das Fortkommen in der Organisation hat, ist dagegen eine deutlich geringere Motivation anzunehmen. 8.4 Schaffen einer Vertrauenskultur Die Unternehmenskultur überträgt sich auf die Projekte und ist nur sehr schwierig und langfristig zu beeinflussen. Das Vertrauensklima, das für eine Projektretrospektive notwendig ist, kann also nur bedingt dadurch geschaffen werden, dass man im ganzen Unternehmen solch ein Klima schafft. Vielmehr muss die herrschende Kultur als faktisch gegeben angenommen werden: „Jedes Unternehmen muss die geerbten Strukturen und die aktuell gelebte Kultur zum Ausgangspunkt seiner Bemühungen nehmen. Die Auseinandersetzung mit den Lösungen erfolgreicher Wissensunternehmen kann hierbei allerdings helfen.“ [18, S. 361] Um also eine Projektretrospektive zum Erfolg zu führen, ist es notwendig, während der Retrospektive Maßnahmen zu ergreifen, die temporär das nötige Vertrauen bei den Mitarbeitern schaffen. Dazu gehören zum einen alle Maßnahmen, die einer Anonymisierung der Ergebnisse dienen, und zum anderen alle Maßnahmen, die den eigentlichen Prozess der Retrospektive bei den Teilnehmern in Gang halten. Ersteres ist notwendig, wenn es um das Festhalten von Fehlern geht, Letzteres, wenn es sich um die Ermittlung und das Festhalten von individuellen Wissensvorsprüngen einzelner Mitarbeiter handelt. Es lassen sich hierzu beispielsweise folgende Regeln vereinbaren [11, S. 43]: o Alle Redebeiträge sind freiwillig, das heißt niemand muss zu einem Sachverhalt Stellung nehmen. o Die Meinung der anderen ist kritiklos zu akzeptieren. o Jeder spricht nur für sich selbst und nicht für einen anderen. o Scherze auf Kosten anderer Personen sind tabu. o Bei Bedarf kann der Teilnehmerkreis so geteilt werden, dass sich die Beteiligten sicherer fühlen. Die Einhaltung dieser Regeln ist bei einer Retrospektive im Projektkernteam leichter zu vereinbaren und einzuhalten als bei einer abschließenden Retrospektive mit erweitertem Teilnehmerkreis. Deshalb sprechen diese Punkte für die Einschaltung eines neutralen Moderators. n Literatur [1] BITKOM (Hrsg.): Kennzahlen zur ITK Branchenentwicklung. Im Internet: www.bitkom.org/ index.cfm? gbAction=gb CategoryDetail&CategoryNodeID=D18DCADC-F6D0-44CC- A7AD19294475CF63, Stand 16. 7. 2003 [2] Stiehler, A.: Massiver Umbruch am IT-Services-Markt bleibt aus. Im Internet: www.iconomy.de/ de/ news/ archiv/ einzelansicht/ news/ 2006/ 12/ 15/ select/ 2007-massiver-umbrucham-it-services-markt-bleibt-aus/ index.html, Stand 9. 1. 2007 [3] Milliardenschäden durch Softwarefehler. Im Internet: www.iconomy.de/ de/ newsletter/ archiv/ archiv_2006/ ausgabe_03_2006/ index.html, Stand 9. 1. 2007 [4] Softwarefehler kosten deutsche Wirtschaft jährlich 165 Milliarden Mark. Im Internet: www.iconomy-online.de/ news/ marktanalysen/ it02_presseinformationen.htm, Stand 16. 7. 2003 29 projekt M A N A G E M E NT 2/ 20 07 aktuell [5] Bannert, V., u. a.: Die vergessene Technologie bei Übernahmen: „Technology Due Dilligence“ als vernachlässigter Aspekt der Unternehmensakquisition. In: New management, Nr. 12/ 2002, Seite 34-45 [6] Faisst, W.: Wissensmanagement. In: Mertens, P. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. vollständig neu bearbeitete und erweiterte Auflage, Berlin u. a. 2001, Seite 510 [7] Hoffmann, K.: IT-Projektmanagement in der modernen Softwareentwicklung. In: Projektmanagement, 1/ 2003, Seite 18-28 [8] Schulz von Thun, F.: Miteinander reden: Störungen und Klärungen. Sonderausgabe, Rowohlt Taschenbuch Verlag, Reinbek bei Hamburg, 2001 [9] Lullies, V./ Bullinger, H.-J./ Weltz, F.: Über den betrieblichen Umgang mit Wissen bei Entwicklungsvorhaben. Frankfurt a. M., New York 1993 [10] Patzak, G./ Rattay, G.: Projektmanagement: Leitfaden zum Management von Projekten, Projektportfolios und projektorientierten Unternehmen. 3. Auflage, Wien 1998 [11] Kerth, N. L.: Post mortem: Projekte erfolgreich auswerten. Project retrospectives: A handbook for team reviews. Übersetzt von Martina Hesse-Hujber, Bonn 2003 [12] Kellner, H.: Ganz nach oben durch Projektmanagement. München, Wien 2000 [13] Schindler, M.: Wissensmanagement in der Projektabwicklung: Grundlagen, Determinanten und Gestaltungskonzepte eines ganzheitlichen Projektwissensmanagements. 2. durchgesehene Auflage, Lohmar, Köln 2001 [14] Nonaka I./ Takeuchi, H.: The knowledge creating company: How japanese companies create the dynamics of innovation. New York, Oxford 1995 [15] Frei, F.: Die kompetente Organisation: Qualifizierende Arbeitsgestaltung - die europäische Alternative. Stuttgart 1993 [16] Reel, J. S.: Critical success factors in software projects. In: IEEE Software, May/ June 1999, Seite 18-23 [17] North, K.: Wissensorientierte Unternehmensführung: Wertschöpfung durch Wissen. 3. Auflage, Wiesbaden 2002 [18] Probst, G./ Raub, St./ Romhardt, K.: Wissen managen: Wie Unternehmen ihre wertvollste Ressource optimal nutzen. 3. Auflage, Frankfurt a. M., Wiesbaden 1999 Schlagwörter Erfahrungssicherung, IT-Projekte, Lernen, Organisationales Wissen Autor Dr. Marko Hunger arbeitete nach seinem Studium der Mathematik und der Wirtschaftswissenschaften einige Jahre für eine international tätige Unternehmensberatung. Anschließend wechselte er als Referent an das Institut für Schulqualität und Bildungsforschung. Zurzeit ist er als Projektleiter bei der Stiftung Bildungspakt verantwortlich für ein Organisationsprojekt im Bereich der beruflichen Schulen in Bayern. Anschrift Bayerisches Staatsministerium für Unterricht und Kultus Stiftung Bildungspakt Jungfernturmstraße 1 D-80333 München Tel.: 0 89/ 21 86 20 87 E-Mail: marko.hunger@stmuk.bayern.de INCOVIS ist eine mittelständische Managementberatung mit dem Branchenschwerpunkt Automotive. Unsere Business Acceleration Systematik integriert die drei wesentlichen Erfolgsmethoden Strategie-, Prozess- und Projektmanagement zu einem ganzheitlichen Managementsystem. Die INCOVIS Akademie sichert darüber hinaus langfristig den Unternehmenserfolg unserer Kunden durch Qualifizierung und internationale Zertifizierung in den Erfolgsmethoden. Von unseren Mitarbeitern erwarten wir überdurchschnittliche Leistung und unternehmerischen Einsatz für unsere global agierenden Kunden aus Mittelstand und Konzernen. Wir expandieren weiter und suchen ab sofort Trainer (w/ m) für Zertifizierungen im Projekt- und Prozessmanagement (optimal mit internationaler Zertifizierung Level B bzw. PM-Trainer-Zertifizierung GPM) Als Trainer und Berater im Projekt- und Prozessmanagement überzeugen Sie uns mit Berufserfahrung und nachhaltigen Erfolgen, dafür finden Sie bei uns die nächste attraktive Herausforderung: Sie arbeiten selbständig und eigenverantwortlich mit unseren Best Class Trainern (GPM), beteiligen sich aktiv am konzeptionellen und strategischen Ausbau der Akademie. Ihr Einsatz und Ihre Ideen sind gefragt, wenn es um Methoden, Kunden und Standorte geht. Dabei zählt zunächst die Kombination aus Training und Beratung zu Ihren Kernaufgaben. Berater (w/ m) im technischen Projekt- und Prozessmanagement (Schwerpunkt Fahrzeugentwicklung) Als Spezialist im Bereich Fahrzeugentwicklung überzeugen Sie uns mit ersten nachhaltigen Berufserfolgen und zünden bei uns die nächste Stufe Ihrer Karriere. Sie beraten und unterstützen unsere Kunden überwiegend vor Ort bei der Gestaltung, Planung und Durchführung von Entwicklungsprojekten. Bei Ihrem Einsatz überzeugen Sie uns und unsere Kunden durch methodisches Arbeiten, Persönlichkeit, Integrität und unternehmerisches Handeln. Haben wir Ihr Interesse geweckt? Diese und weitere Stellenbeschreibungen finden Sie auch unter www.incovis.com Senden Sie uns Ihre aussagekräftige Bewerbung per Post oder digital. Wir freuen uns auf Sie! INCOVIS AG Ressort Personal Herr Jürgen Litke Karl-Benz-Straße 19 70794 Filderstadt Tel. 0711 79 73 326-0 www.incovis.com bewerbung@incovis.com Anzeige