Kommunikation als Erfolgsfaktor des Wissensmanagements: Ein Praxisbericht aus Software-Projekten

Transkript

1 Kommunikation als Erfolgsfaktor des Wissensmanagements Dr. Jürgen Schmied: Kommunikation als Erfolgsfaktor des Wissensmanagements: Ein Praxisbericht aus Software-Projekten Zusammenfassung Prozess- und Wissensmanagement haben eine hohe inhaltliche Abhängigkeit zueinander. Beide können sowohl als unternehmensweite Lösung als auch in Form von kleinen Verbesserungsschritten implementiert werden, und beide sind in ihrem Erfolg von dem Faktor Kommunikation mitbestimmt. Wissen entsteht in der Projektarbeit oftmals dort, wo kommuniziert wird, mindestens wird es aber darüber verteilt. Geeignete Projektportale können dies noch unterstützen. Dies wird in diesem Beitrag praxisbezogen anhand von Beispielen aus Software- Entwicklungsprojekten diskutiert und darüber das Verhältnis zwischen Projekt-, Qualitäts- und Wissensmanagement aufgezeigt. 1 Motivation und Einführung Schnellebige Produkte und die daraus resultierenden immer kürzer werdenden Entwicklungsprozesse zwingen Unternehmen zu einer möglichst effizienten Projektdurchführung. Es gilt nicht mehr zwangsläufig der Grundsatz der Größere ist dem Kleineren überlegen, stattdessen wächst das kleinere Unternehmen - da meist flexibler und schneller - stärker als der Großkonzern. Entscheidende Wettbewerbsvorteile sind dabei die Fähigkeit zur Kommunikation im Unternehmen und damit die Fähigkeit Erfahrungen und Wissen auszutauschen. Das Schlagwort Wissensmanagement geistert schon viele Jahre umher. Was ist aber tatsächlich passiert? Sicher, einige (sehr große) Unternehmen haben heute Wissensmanagementsysteme im Einsatz, es existiert die große Konzernlösung. Unser Land ist jedoch durch den Mittelstand geprägt und hier sind zumindest wenn es um die hier zu diskutierende Branche Software-Entwicklung geht die Firmen noch weit weg von der angepriesenen Wissensgesellschaft. Sicher, die Idee ist einfach toll, als Mitarbeiter Wissen mit anderen zu teilen, auf einfache Art und Weise Wissen im Unternehmen zu finden und wiederverwenden zu können. Doch nur wenige können etwas mit unternehmensübergreifenden Wissensmanagement, mit der großen Lösung anfangen. Hier fragen Geschäftsführer und Projektleiter sehr schnell: Was bringt mir das konkret in meinem aktuellen Projekt? Wird mein Projekt dadurch kostengünstiger und schneller fertig? Oder habe ich zumindest eine Verbesserung der Qualität meiner Produkte? Vielleicht haben mittelfristig andere einen Nutzen, aber welchen Nutzen habe ich hier und heute? Ist also Wissensmanagement in der Praxis nur ein Schlagwort? Nein, aber es muss der Fragestellung nachgegangen werden, wie Wissensmanagement nicht nur im Großen umgesetzt Seite: 1 von 11

2 werden kann. Oftmals sind es (zunächst) die kleinen einfachen Verbesserungen, um auch möglichst schnell einen Nutzen im aktuellen Projekt zu erhalten. Der weiße Spruch think big, act small hat also auch hier seine Gültigkeit. Der zweite Aspekt betrifft die Fähigkeit im Unternehmen zu kommunizieren. Um Wissensmanagement in einem Unternehmen erfolgreich ein- und fortzuführen, bedarf es vor allen Dingen einer offenen und fairen Kommunikation. Begangene Fehler dürfen nicht als Kritikpunkte verstanden werden, sondern als Chance diese zusammen mit den Lösungsansätzen weiterzugeben, so dass Kollegen aus den begangenen Fehlern lernen und diese nicht selbst begehen. Der Teamgeist und das kooperative Verhalten unter den Mitarbeitern muss deshalb besonders gefördert werden. Wissensmanagement muss als wichtiger Bestandteil der Unternehmenskultur verstanden werden, von dem alle einen Nutzen haben. Im konkreten Beispiel der Software-Branche ist Wissensmanagement inhaltlich sehr eng mit den Software-Entwicklungsprozessen verknüpft, wie dies auch an den Beispielen im folgenden Abschnitt Wissensmanagement durch Kommunikation erkennbar wird. Gerade das Aufsetzen eines unternehmensweiten Wissensmanagements ist, genauso wie das Thema Prozessdefinition, eine Ressourcenfrage, weshalb die Beteiligung des Managements eine unabdingbare Voraussetzung ist (z.b. wird in [5] regelmäßig auf das commitment of senior management verwiesen). Weitere Erfolgsfaktoren für Wissensmanagement sind daher: Die Einbeziehung, Motivation und Akzeptanz der beteiligten Mitarbeiter, sowie die Einsicht der Notwendigkeit und in Folge dessen die Genehmigung des Budgets bzw. zusätzlichen Personals durch das Management. Wie lässt sich nun Wissensmanagement in der Software-Branche erfolgreich umsetzen? Hierzu wird zunächst der Begriff Wissensmanagement in Anlehnung an Probst et al. [1] kurz erläutert. Die Beispiele im nächsten Abschnitt werden dann im Kontext dieser Begriffe erläutert. Im Mittelpunkt der Abbildung 1 stehen die Menschen, d.h. genauer die Kommunikation zwischen den Menschen. Die Abbildung zeigt weiterhin die einzelnen Aktivitäten, die unter dem Begriff Wissensmanagement zusammengefasst werden: Wissensziele Feedback Wissensbewertung Wissensidentifikation Wissensnutzung Wissenserwerb Wissensbewahrung Wissensentwicklung Wissens(ver)teilung Abbildung 1: Kreislauf des Wissensmanagements Wissensziele: Wissensmanagement muss durch klar definierte Ziele geleitet sein: Warum soll Wissensmanagement betrieben werden und welche Wissensthemen lassen sich daraus ableiten? (siehe auch [2]). Seite: 2 von 11

3 Wissensidentifikation: Aufgabe der Wissensidentifikation ist die Ortung von Wissensträgern innerhalb des Unternehmens sowie deren Wissen über die definierten Wissensziele. Wissenserwerb und Wissensentwicklung: Wissenserwerb und Wissensentwicklung sollen aufgedeckte Wissenslücken schließen. Beispiele für Wissenserwerb sind gezielte Unternehmensfusionen, Einbindung von Unterauftragnehmern in Projekte, gezielte Personalakquise, freie Mitarbeiter und externe Berater, also das Einkaufen von Wissen von außen. Dagegen geht es bei der Wissensentwicklung um die Fortentwicklung des vorhandenen Personals. Wissens(ver)teilung: Wissens(ver)teilung beschäftigt sich mit der Technik wie das Wissen, d.h. im Wesentlichen mit welchen Werkzeugen, verteilt wird. Wissensbewahrung: Unter Wissensbewahrung wird die Ablage des Wissens mit bestimmten Techniken/ Tools (z.b. Datenbank, XML- oder HTML-Dateien, etc.) verstanden. Wissensnutzung und bewertung: Wissensmanagement ist ein kontinuierlicher Prozess, in dem die Inhalte einem steten Wandel unterliegen. Gegebenenfalls ist aber auch die Art der Durchführung des Wissensmanagements zu verbessern. Ist das Wissen von schlechter Qualität, so wird das Vertrauen in das dargestellte Wissen abnehmen und damit auch über kurz oder lang die Nutzung des Systems. Mit einer geringen Nutzung des Systems wird wiederum die Bereitschaft des Managements abnehmen Investitionen für dieses Wissensmanagementsystem bereitzustellen, wodurch die Wissensqualität (aufgrund der fehlenden Ressourcen) noch schlechter wird. Diesen Teufelskreis gilt es von Anfang an durch genau definierte Wissensziele, Einbindung und Motivation der späteren Nutzer, regelmäßiges Feedback durch eine Wissensbewertung und ausreichende Unterstützung durch das Management zu vermeiden. 2 Wissensmanagement durch Kommunikation Die nachfolgenden Beispiele greifen einzelne Aktivitäten aus dem eben definierten Wissensmanagementzyklus heraus und diskutieren die projektorientierte Umsetzung anhand der Software-Industrie. In allen Beispielen tritt Kommunikation als ausschlaggebender Faktor hervor! 2.1 Prozesse und Wissen Allgemein gilt: Um Anwendungssysteme zu entwickeln wird Anwendungs-Know-How (linke Hälfte der Abbildung 2) sowie Entwicklungs-Know-How (rechte Hälfte der Abbildung 2) benötigt. Entwicklungs-Know-How lässt sich in mehrere Teilbereiche gliedern: An oberster Stelle steht das Prozesswissen. In welcher Reihenfolge habe ich prinzipiell welche Aktivitäten durchzuführen, um ein Anwendungssystem erfolgreich zu entwickeln. D.h. in Entwicklungsprozessen wird beschrieben, was wann und von wem durchzuführen ist. Es werden Verantwortlichkeiten, zeitliche Abhängigkeiten von Aktivitäten und Seite: 3 von 11

4 wesentliche Ergebnisse definiert (Beispiel: In der Projektphase Konzepterstellung wird die Architektur des zu entwickelnden Anwendungssystems vom Systemarchitekten erstellt. Voraussetzung hierfür ist, dass zuvor das Pflichtenheft, welches die Anforderungen an das zu entwickelnde System enthält, erstellt und freigegeben wurde). Diesem Prozesswissen untergeordnet steht das Methodenwissen. Die Aktivitäten im Prozess beschreiben nur, was zu tun ist, nicht aber wie es zu tun ist. Das wie wird durch Methoden beschrieben. In der Regel gibt es mehrere verschiedene Methoden, um zum selben Ziel zu kommen (Beispiel: Im Prozess wird beschrieben, dass eine Software- Architektur zu erstellen ist. Hierfür gibt es mehrere verschiedene Methoden. In den 70er und 80er Jahren hätte man die SA/SD Methodik (Strukturierte Analyse und Design) eingesetzt, heutige Software-Systeme werden oft mit Hilfe der UML (Unified Modeling Language) entworfen [6]). Das Methodenwissen beschreibt also konkret, wie etwas umzusetzen ist. Im Prinzip können Methodiken auch per Hand (am Beispiel des Architekturkonzepts also mit Bleistift und Papier) angewendet werden. Oftmals ist es jedoch deutlich effizienter, unterstützende Werkzeuge einzusetzen (am Beispiel des Architekturkonzeptes etwa ein kommerzielles UML-CASE-Werkzeug, das aus dem Architekturentwurf anschließend zumindest teilweise automatisch Source-Code für das Anwendungssystem generiert und so den Software-Entwickler deutlich entlastet). Hierzu ist ergänzend zum Methodenwissen Werkzeugwissen notwendig. Geschäftsprozesse Entwicklungsprozesse Fach-Know-How Methoden Anwendungssysteme Werkzeuge Abbildung 2: Anwendungsdomäne und Entwicklung Die Abhängigkeiten gelten in genau der geschilderten Reihenfolge, umgekehrt ist beispielsweise Werkzeugwissen ohne das zugrunde liegende methodische Wissen wertlos. Methodisches Wissen ohne Prozesswissen, d.h. wann diese Methodik und von wem sinnvoll eingesetzt werden kann, ist ebenfalls nicht sinnvoll! Um Anwendungssysteme erfolgreich zu entwickeln, ist aber nicht nur Entwicklungs-Know-How notwendig, sondern natürlich auch Wissen über die Anwendungsdomäne selbst. In der Anwendungsdomäne ist dieselbe Abhängigkeit von Prozessen-Methoden-Werkzeugen wie in der Entwicklungsdomäne erkennbar. Betrachten wir zum Beispiel ein Krankenhaus: Ein typischer Geschäftsprozess ist dort sicherlich die Behandlung von Patienten, die sich in verschiedene Aktivitäten des Klinikpersonals zergliedert. Für die konkrete Aktivität Erstellung einer Diagnose ist der Arzt verantwortlich, der hierfür nicht nur Wissen über die Abläufe im Krankenhaus haben muss, sondern auch medizinisches Know-How. Um sein fachliches Know-How effizient anwenden zu können, benötigt er je nach vorliegendem Krankheitsbild unterstützende Werkzeuge, z.b. ein Röntgengerät, um die richtige Diagnose zu finden. Beispiele dieser Art lassen sich praktisch überall finden. Es muss sich dabei nicht nur um Geschäftsprozesse im klassischen Sinne handeln, sondern allgemein um Prozesse jeder Art aus der Anwendungsdomäne. D.h. insbesondere fallen beispielsweise auch technische Prozesse darunter. In den folgenden Abschnitten werden nun konkret Software-Entwicklungsprozesse, sowie zugeordnetes Methoden- und Werkzeugwissen betrachtet! Seite: 4 von 11

5 2.1.1 Wissensziele Zur Beantwortung der Frage nach dem Was sollte mit Hilfe des Wissensmanagements auf Projektebene verwaltet werden? liefern Qualitäts- und Reifegradmodelle gute Hinweise. So beschreibt beispielsweise das Capability Maturity Model Integration (CMMI) [5] im Umfeld der Software-Entwicklung und des System Engineerings, welche Schlüsselprozesse (siehe Abbildung 3) in einem Unternehmen etabliert werden sollten und welche Aktivitäten dabei auszuführen sind. Auch wenn Modelle wie das genannte CMMI typischerweise nicht das Wie der Umsetzung beschreiben, so werden doch bestimmte Prozesse und Arbeitsergebnisse gefordert und Hinweise gegeben, welche Rollen an der Erreichung der Arbeitsergebnisse beteiligt sein sollten. Abbildung 3: Capability Maturity Model Integration (CMMI) Auf Projektebene liegt der Schwerpunkt der Prozessdarstellung aber nicht auf dem Was, sondern Wie der Prozess möglichst gut im Unternehmen umgesetzt wird. Also im Sinne der Abbildung 2 auf dem methodischen Wissen sowie auf dem Wissen über unterstützende Werkzeuge. Hierzu ist es notwendig, die Wissensakquise in den Entwicklungsablauf einzubetten und die Erkenntnisse mit einem möglichst flexiblen Medium zu dokumentieren. Aus dem normalen Projektalltag ergeben sich so schnell die Elemente, die mit Hilfe des Wissensmanagements verwaltet werden sollten: Am Beispiel von Software- Entwicklungsprozessen wären dies Methoden wie etwa das Change Management, Review Verfahren oder die Projektverfolgung mit Hilfe von Meilensteindefinitionen, aber auch Designtechniken wie z.b. die Strukturierte Analyse und Design oder die Unified Modeling Language, die zu erzielenden Arbeitsergebnisse (d.h. die Dokumente), die innerhalb des Projektes zu erstellen sind, ergänzt durch Checklisten zur Erstellung der Dokumente, die Definition von Rollen, die im Projektablauf die Verantwortung für einzelne Arbeitsergebnisse zu übernehmen haben, und Seite: 5 von 11

6 eine inhaltliche sowie zeitliche Gliederung der Entwicklungsprojekte im Sinne eines Phasenmodells. Die anvisierten Wissensziele im Umfeld der Software-Entwicklung sind also recht klar: Es geht um das Wissen wie Software entwickelt wird, also um all die sogenannten Software Engineering Methodiken wie Anforderungsmanagement, Design, Codegenerierung, Projekt- und Konfigurationsmanagement, Qualitätssicherung, u.a. Wissen über Werkzeuge, wie mit ihnen die Anwendungen leichter, schneller, besser entwickelt werden können, ergänzt um das Anwendungswissen, mit dem Software-Anwendungen entwickelt werden Prozesse definieren Der Aufbau von Prozessdefinitionen, sowie die Adaption und Beschreibung von Methodiken auf das eigene Unternehmen (siehe einleitende Abschnitte 2.1 und 2.1.1) werden typischerweise fast ausschließlich durch die Kommunikation im Unternehmen vorangetrieben. Wie ist die Vorgehensweise beim Aufbau von Prozessdefinitionen nach zum Beispiel dem Reifegradmodell CMMI? 1. Standortbestimmung: Zunächst wird ein sogenanntes Assessment eines oder mehrerer Entwicklungsprojekte durchgeführt. Hierbei werden die einzelnen Schlüsselprozesse des CMMI Modells abgefragt, d.h. es wird überprüft inwieweit die Anforderungen des Modells in den Projekten (d.h. letztlich in den gelebten Prozessen) auch tatsächlich erfüllt wurden (Beispiel: Zum Schlüsselprozess Requirements Engineering wird gefordert, dass die Systemanforderungen von den Anforderungen des Kunden abgeleitet sind und dokumentiert werden. Der Nachweis kann etwa über die Existenz eines Pflichtenheftes geführt werden). Das Ergebnis der Standortbestimmung ist ein differenziertes Stärken- Schwächen-Profil, wobei als Grundlage das CMMI Modell dient. Im Sinne von Wissensmanagement dient die Standortbestimmung vorrangig der Wissensidentifikation (denn im Rahmen der Standortbestimmung wird offensichtlich, wer in den Projekten spezielles Know-How auf welchen Gebieten besitzt). Die Wissensziele, die natürlich vor der Wissensidentifikation zu definieren sind, sind im Rahmen eines CMMI basierten Assessments durch die im Modell festgelegten Schlüsselprozesse automatisch vorgegeben. Die Standortbestimmung selbst ist im wesentlichen ein Frage-Antwort-Spiel zwischen Assessor und Projektteam, d.h. durch Kommunikation getrieben. 2. Planung des Prozessverbesserungsprojektes Aufgrund des Stärken-Schwächenprofils wird ein Prozessverbesserungsprojekt geplant. Im Sinne von Projektplanung werden hierzu Teilteams zu verschiedenen Themen zusammengestellt, Meilensteine geplant, usw. Im Sinne von Wissensmanagement ist jedoch wichtig festzuhalten, dass das Stärken- Schwächenprofil für die Priorisierung von Wissenszielen sowie des anschließenden Wissenserwerbs im Rahmen des Verbesserungsprojektes dient. 3. Durchführung von Workshops und Dokumentation Das eigentliche Prozessverbesserungsprojekt wird üblicherweise durch mehrere aufeinanderfolgende Workshops durchgeführt. Die einzelnen Workshops beschäftigen sich mit den Schlüsselprozessen des CMMI Modells bzw. deren konkreten Umsetzung im eigenen Unternehmen. Teilnehmer des Workshops sind typischerweise neben einem klassischen Prozessberater vor allem die Know-How-Träger bezüglich des Seite: 6 von 11

7 durchgesprochenen Schlüsselprozesses im Unternehmen. Im Sinne von Wissensmanagement dienen diese Workshops dem Wissenserwerb und Wissensentwicklung durch Kommunikation in der Workshopgruppe. Die Ergebnisse des Workshops werden in geeigneter Form dokumentiert (Wissensbewahrung zum Beispiel durch ein Projektportal, siehe Abschnitt 3). 4. Review der Ergebnisse Die Ergebnisse der Prozessdefinition werden am Ende der Workshops (oder auch zuvor zu wichtigen Meilensteinen) von der Prozessdefinitionsgruppe sowie einem weiteren Kreis von Interessierten im Unternehmen einem Review unterzogen. Im Sinne von Wissensmanagement geht es hier um die Wissensbewertung und um das entsprechende Feedback. Wie im Abschnitt 2.2 noch beschrieben wird, dienen Reviews nicht nur der Qualitätssicherung sondern u.a. auch der Wissensverbreitung durch Kommunikation innerhalb des Reviewteams! 5. Pilotierung der Prozesse und Methoden Nach Abschluss der eigentlichen Prozessdefinition, sind die Prozesse und Methoden in einem Pilotierungsprojekt auf praktische Anwendbarkeit im Projektalltag zu validieren. Quasi erst nach erfolgreichem Testlauf sollen die Prozesse unternehmensweit eingeführt werden. In der Pilotierung wird dem Pilotprojekt üblicherweise ein Projektcoach an die Seite gestellt, der für das Projektteam geeignete individuelle Schulungen durchführt sowie bei der Anwendung der definierten Prozesse und Methoden unterstützt. Ggfs. gehört hierzu auch die Auswahl eines geeigneten unterstützenden Werkzeuges. Das Haupthilfsmittel des Projektcoaches ist aber auch hier die Kommunikation! Im Sinne von Wissensmanagement geht es bei der Pilotierung um Wissensverteilung (zunächst nur im Pilotprojekt), Wissensnutzung und bewertung. Der Projektcoach stellt die Kommunikationsschnittstelle zwischen Projektteam und Definitionsteam dar, d.h. über ihn fliesst das Feedback über das dokumentierte Wissen (in Form von Prozessen und Methoden) direkt zurück zu dessen Erstellern. 6. Roll-Out der Prozesse und Methoden im gesamten Unternehmen Nach erfolgreicher Pilotierung werden die Prozesse und Methoden offiziell zur Nutzung freigegeben und die unternehmensweite Einführung kann erfolgen. Im Sinne von Wissensmanagement geht es jetzt wie bei der Pilotierung um Wissensverteilung, Wissensnutzung und bewertung. Das Thema Prozessdefinition ist in der Software-Branche typischerweise ein Beispiel für unternehmensweites Wissensmanagement, mindestens dann, wenn nach CMMI Level 3 gearbeitet werden soll (CMMI ist u.a. in Stufen von 1 bis 5 gegliedert. Auf Stufe 3 stehen erstmals unternehmensweit einheitliche Prozesse im Vordergrund). Neben dem Wissensmanagement im Großen kann im Projektalltag aber auch sehr viel Nutzen durch Wissensmanagement im Kleinen erreicht werden. In beiden Fällen gilt: Erfolgsfaktor ist die gelungene Kommunikation. Im folgenden werden solche Beispiele behandelt. 2.2 Reviews In der Software-Entwicklung haben Reviews ihren festen Platz und gehören in ihren verschiedenen Ausprägungen ebenso wie die verschiedenen dynamischen Testverfahren zu den analytischen Methoden. Allen Reviews ist gemeinsam, dass Dokumente einer anderen Person als dem Autor zur Prüfung vorgelegt werden. Jeder Fehler, der in einer frühen Entwicklungsphase durch ein Review gefunden und anschließend korrigiert wird, verursacht um Größenordnungen geringere Kosten verglichen mit seiner Entdeckung im Test. D.h. Reviews Seite: 7 von 11

8 können z.b. im Gegensatz zu dynamischen Software-Tests bereits in sehr frühen Phasen der Entwicklung angewendet werden und verursachen dabei im Vergleich zu anderen Software- Qualitätssicherungsmaßnahmen nur geringe Kosten. Sofort einsichtig ist, dass Reviews der Analyse von Arbeitsergebnissen dienen. Aber wieso soll denn in Reviews auch neues Wissen entstehen? Um Fehler in einem Entwicklungsdokument zu finden, kommen mehrere Experten zusammen um diese zu identifizieren und zu bewerten. Am konkreten Beispiel eines Pflichtenheftes könnten dies etwa der Autor des Pflichtenheftes (der Systemanalytiker), Vertreter des Kunden (bei einer Produktentwicklung kann dies auch das eigene Produktmanagement sein), aber auch Vertreter derjenigen sein, die nach Freigabe des Pflichtenheftes dieses in irgendeinem Sinne weiterverwenden müssen. Zum Kreis dieser Personen werden mit Sicherheit System-/ Software- Designer gehören, aber auch Systemtester, denn diese müssen auf der Basis der definierten Anforderungen in der Lage sein, hieraus Testfälle für das zu entwickelnde System abzuleiten. In diesem konkreten Fall entsteht in der Gruppe der Reviewteilnehmer auch konkretes Wissen, denn jeder der Teilnehmer hatte bis zum Zeitpunkt des Reviews eine nämlich seine eigene ganz konkrete Sichtweise auf die Anforderungen bzw. das zu entwickelnde System. Typischerweise ist gerade die Anforderungsanalyse eine der schwersten Tätigkeiten überhaupt: Zu Beginn kennt der Kunde seine eigenen Anforderungen oftmals noch gar nicht im Detail. Anforderungen und damit Wissen über das zu entwickelnde System entstehen erst im Laufe des Projektes, und gerade in Reviews über Anforderungen werden, u.a. durch die Betrachtung aus verschiedenen Sichten (Kunde, Designer, Tester, etc.), mögliche Probleme oder einfach nur offene Anforderungen offensichtlich. Durch das Hinterfragen der Anforderungen werden Wissenslücken geschlossen und (Anforderungs-)Wissen im Reviewteam verteilt. Reviews sind Beispiele dafür, dass Wissen durch Kommunikation entsteht. 2.3 Kreativitätstechniken Kreativitätstechniken sind von Hause aus dafür vorgesehen durch Kommunikation Neues zu schaffen. Gerade das Brainstorming bietet sich in zahlreichen Projektsituationen an. Das Prinzip ist einfach: Zunächst werden zu einem bestimmten vorgegebenen Thema durch einen Moderator (in Projekten oftmals der Projektleiter selbst) Ideen der Beteiligten abgefragt und protokolliert. In dieser Phase des Brainstormings ist es nicht erlaubt, die Ideen zu diskutieren oder zu bewerten. Es ist gerade das Prinzip des Brainstormings im ersten Augenblick abwegige Ideen zuzulassen und so die Beteiligten aus gedanklichen Einbahnstrassen zu befreien. Eine sofortige Diskussion und Bewertung würde den positiven Effekt des Brainstormings zunichte machen. Einige sinnvolle Projektsituationen für den Einsatz von Kreativitätstechniken sind etwa bei der Anforderungsanalyse, beispielsweise das Sammeln von Use Cases und den verschiedenen zugehörigen Szenarien, bei der Projektplanung, und hier speziell bei der ersten Erstellung des Projektstrukturplanes, bei der es darum geht, die Aufgaben möglichst vollständig zu erfassen und zu strukturieren, bei der Risikoanalyse, insbesondere bei der Risikoidentifikation, denn diese ist keine Aufgabe vom Projektleiter alleine. Viele Risiken kann er nicht alleine überblicken und ist daher auf die Hilfe seines Teams angewiesen. 2.4 Projektberichte Als letztes Beispiel für Kommunikation im Projektteam und wie hierbei Wissen entstehen kann, soll das Thema Projektabschluss [3] dienen. In länger andauernden Projekten wird dieses Grundprinzip nicht nur zum Abschluss von Projekten angewendet, sondern auch zum Abschluss Seite: 8 von 11

9 von einzelnen Projektphasen. Welchen Zielen dient nun der Projektabschluss? Zum einen dient der Projektabschluss typischen Aufräumarbeiten wie dem Abschluss der Planungsdokumente, Durchführung der Nachkalkulation (um diese mit der ursprünglichen Kalkulation zu vergleichen) oder die technische Dokumentation zu aktualisieren (sofern dies nicht schon idealerweise während des Projektes geschah!). Das in diesem Zusammenhang wichtigere Ziel ist jedoch, aus den vom Projektteam gemachten Erfahrungen für die Zukunft zu lernen. D.h. konkret, im Projektabschluss wird betrachtet, ob die für das Projekt gesteckten Ziele erreicht wurden. Zudem wird die Art und Weise der Projektabwicklung hinterfragt und bewertet: Was ist gut gelaufen und was ist verbesserungswürdig? Der Projektabschluss wird in der Regel als Projektreviewsitzung oder in größeren Projekten auch als Workshop durchgeführt. Als Ergebnis entsteht ein Projektabschlussbericht, aber die Ergebnisse dieser Analysearbeit sollten nicht nur innerhalb des Projektteams, sondern innerhalb des gesamten Unternehmens veröffentlicht werden! Dabei kann es nicht Sinn und Zweck sein, den erstellten Erfahrungsbericht nur im Intranet zu veröffentlichen, die Ergebnisse müssen aktiv kommuniziert werden! Eine sinnvolle Vorgehensweise ist zum Beispiel, den Erfahrungsbericht innerhalb eines unternehmensinternen Forums zu präsentieren und zu diskutieren. Auch aus Fehlern kann gelernt werden, d.h. die richtige Unternehmens- Kommunikationskultur ist hierbei wichtig! 3 Wissensverteilung durch Projektportale Die Wissensverteilung lässt sich aber nicht nur durch die aktive Kommunikation sondern auch durch geeignete Werkzeuge unterstützen. Gerade am Beispiel der besprochenen unternehmensweit einheitlichen Prozessdefinitionen bieten sich Projektportale an, um Wissen zu verteilen. Abbildung 4: Projektportal zur Prozessdefinition / 1 Seite: 9 von 11

10 Abbildung 5: Projektportal zur Prozessdefinition / 2 Abbildung 4 und Abbildung 5 zeigen ein Projektportal, mit dem Software-Entwicklungsprozesse, und damit Wissen über das Thema Software Engineering, komfortabel definiert, aber auch für Projekte angepasst (Prozess-Tailoring) und umgesetzt werden können (konkret zeigt die Abbildung 4 ein Phasenmodell und Abbildung 5 einen Auszug aus einem Problemkatalog zum Thema Risikomanagement). In einem Entwicklungsprojekt sind aber nicht nur die Ablauf- und Aufbau-organisatorischen Aspekte wie sie in der Prozessdefinition betrachtet werden von Bedeutung, sondern weitere, spontan anfallende Informationen. Beispiel: Während die ersten Aspekte eher unter die Kategorie gefestigte Arbeitsregeln fallen, sind unter letzterer Kategorie Informationen wie Besprechungs- und Review-Protokolle, Change Requests und sonstige Vereinbarungen mit dem Kunden, Absprachen und -verkehr, etc. zu verstehen. Für diese Art von Informationen hat sich im Projektmanagement das Projektlogbuch bewährt. Beide Informationskategorien (Arbeitsregeln wie auch das Projektlogbuch) sind für das Projektteam von essentieller Bedeutung und sollten in einem Projektportal vereint werden. Projektteams müssen durch den Prozess geleitet werden und brauchen einen zentralen Zugang zu allen wichtigen Informationen. Zudem werden Projekte heute häufig über mehrere Standorte verteilt durchgeführt. Ein Web-basiertes Projektportal schafft den direkten Zugang zu den Prozesselementen und damit zum Projekt inklusive der im Projektlogbuch verwalteten Informationen. Durch die personalisierte Präsentation, die der spezifischen Rolle des Mitarbeiters im aktuellen Projekt angepasst ist, hat jeder Anwender schnellen Zugriff auf die für ihn relevanten Informationen. Da der Prozess quasi selbst als Benutzeroberfläche erscheint, wird vom Projektteam nichts vergessen, und das Unternehmen erhält eine hohe Transparenz über seine Projekte. Dies wiederum erleichtert die Bewertung und Priorisierung der Projekte und trägt somit zur Verbesserung des übergeordneten Projektmanagements bei. Schließlich ist der einfache Zugang Seite: 10 von 11

11 zu allen Informationen eines Software-Projekts entscheidend für die Akzeptanz eines Entwicklungsprozesses innerhalb des Projektteams. 4 Literatur [1] Probst, G./ Romhardt, K.: "Bausteine des Wissensmanagements - ein praxisorientierter Ansatz", in: Dr. Wieselhuber & Partner Unternehmensberatung (Hrsg.): "Lernende Organisation", Gabler-Verlag, 1997 [2] Schmied, J.: Wissensmanagement in der Software-Entwicklung in: Projektmanagement 1/2001, TÜV Verlag GmbH, Köln [3] Hindel, B., Hörmann, K., Müller, M., Schmied, J.: Basiswissen Software- Projektmanagement, dpunkt Verlag, 2004 [4] Embedded Quality: Methoden zur Unterstützung der entwicklungsbegleitenden Qualitätssicherung von eingebetteter Software (EQUAL), BMBF-Förderprojekt, [5] Software Engineering Institute: Capability Maturity Model Integration (CMMI), [6] Balzert: "Lehrbuch der Software-Technik: Software-Entwicklung", Spektrum Akademischer Verlag, Heidelberg, Kurz-Vita Dr. Jürgen Schmied studierte und promovierte an der Universität Würzburg im Fach Informatik. Seitdem ist er als Berater für Software Engineering-Themen tätig wurde er in den Vorstand der method park Software AG berufen. Er tritt als Referent bei internationalen Fachtagungen und Seminaren zu den Themen Software Process Improvement und Software-Projektmanagement auf und organisiert beim isqi (International Software Quality Institute) die für den Lehrplan und die Akkreditierungen des isqi Certified Professional for Project Management zuständige Arbeitsgruppe. An der Universität Würzburg hält er Vorlesungen zum Thema Management im Software Engineering. Weiterhin ist er Mitglied in verschiedenen Gremien, u.a. im Programmkomitee der InterPM (Konferenz zur Zukunft im Projektmanagement). Kontaktdaten: Dr. Jürgen Schmied method park Software AG Wetterkreuz 19a Erlangen Tel. +49 (9131) Mobil. +49 (172) juergen.schmied@methodpark.de Seite: 11 von 11