Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

18.09.1992 - 

Projekt-Management in der Praxis (Teil 18)

Übergreifender Wissenstransfer bleibt oft dem Zufall überlassen

Professor Friedrich Weltz ist Geschäftsführer der Sozialwissenschaftlichen Projektgruppe, München, und Honorarprofessor an der Universität Göttingen; Rolf Ortmann ist Mitarbeiter der Sozialwissenschaftlichen Projektgruppe, München

Der systematische, projektübergreifende Transfer von Wissen und Erfahrungen wird in der Software-Entwicklung wird vielfach vernachlässigt. Dabei kommt ihm für die erfolgreiche Abwicklung von Projekten große Bedeutung zu.

Die Entwicklung von Software, wie sie und in Untersuchung begegnete, fand überwiegend in Projekten statt, das heißt in organisatorischen Strukturen, die auf zeitliche Begrenzung angelegt waren. Entsprechend waren Planung und Gestaltung der Arbeitsorganisation, des Personaleinsatzes und der Arbeitsvorgaben auf diesen Zeitraum ausgerichtet das Ende des Projekts bedeutete jeweils eine Zäsur. Für die nachfolgenden Projekte galten neue vorgaben, neue personelle Konstellationen und neue Termine.

Aus diesem Zeittakt der Software-Entwicklung ergab sich für die Akkumulation und Mobilisierung von Fachwissen und Erfahrungen im jeweiligen Unternehmen ein Grundproblem. Projekte wurden meist als in sich abgeschlossene Einheiten behandelt, mit definiertem Anfang und Ende und - mehr oder weniger klar - definiertem Auftrag. Für Projektleiter und Entwickler bedeutete dies: War der Auftrag erfüllt beziehungsweise das Projekt zu Ende, wandten sie sich anderen, neuen Aufgaben zu, häufig in neuer personeller Konstellation und häufig auch mit deutlich anderem Inhalt.

Die hohe Diskontinuität des Personaleinsatzes bekamen wir auch bei unserer Untersuchung zu spüren: Bei Projekten, zu denen wir einige Monate nach Projektabschluß noch Nachrecherchen anstellen wollten, erwies sich dies als ausgesprochen schwierig, weil unsere Gesprächspartner inzwischen mit anderen Aufgaben betraut waren, zum Teil sogar an anderen Standorten. Meistens fanden es unsere Gesprächspartner eher mühsam, sich in die Problemstellungen des abgeschlossenen Projekts zurückzuversetzen, ganz

im Gegensatz zu dem Interesse und Engagement, mit dem

sie uns zuvor Auskunft gegeben hatten. Es war deutlich erkennbar, daß mit Projektende für sie das Projekt auch innerlich abgeschlossen war.

Zugleich waren jedoch die Projekte Teile von Entwicklungssträngen, hatten eine Vor- und Nachgeschichte, mit der sie eng verknüpft waren. Dies traf auch dort zu, wo neue Projekte nicht direkt auf vorangegangenen aufsetzten, also nicht explizit frühere Entwicklungsarbeiten weiter führten. Nur wenige Projekte waren völlig auf der grünen Wiese angesiedelt, die meisten hatten sich mit bereits installierter Hard- und Software auseinanderzusetzen.

Für die Entwicklungsaufgaben gab es somit einen Fundus an Wissen und Erfahrungen

- über die bereits eingesetzte Hard- und Software,

- über Einsatzanforderungen und -bedingungen in der Anwendung,

- über Besonderheiten sowie Vor- und Nachteile der verwandten Instrumente und Methoden.

Dieser Fundus erwies sich für die Aufgabenbewältigung zumeist als wertvoll und hilfreich. Er war innerhalb und außerhalb der Unternehmen an vielen Stellen abrufbar: bei Bearbeitern früherer Projekte, bei Anwendern, Beratern, Vertretern von Herstellern etc. Dies galt natürlich besonders für Eigenentwicklungen von Anwendern, aber im Prinzip auch für viele Auftragsentwicklungen in Softwarehäusern.

Wie zur Vor- bestand auch zur Nachgeschichte ein enger Bezug, der dem Wissenstransfer große Bedeutung zuwies. Nicht nur waren die Kenntnisse, die die Erstentwickler der Software gesammelt hatten, für die weitere Pflege des Systems wertvoll, sondern auch in umgekehrter Richtung spielte das Feedback ein große Rolle. Die Erfahrungen, Änderungswünsche und auch Fehler der Anwender, die Schwierigkeiten bei der Weiterentwicklung und Pflege der neuen Software sind ihr eigentlicher Qualitätstest und zeigen, wie anwendungsbezogen ihre Entwicklung erfolgte.

Bezüge gab es schließlich häufig auch zu zeitlich parallel laufenden Projekten, vor allem dort, wo unmittelbare Schnittstellen der zu entwickelnden Software gegeben waren.

Aufgabenstellung und Gegenstand von Projekten waren also zumeist Teil eines übergreifenden Zusammenhangs, aus dem ein Teilabschnitt herausdefiniert wurde. Diese zeitliche und organisatorische Isolierung der Arbeiten hat - wie wir gesehen haben -

gute Gründe, die im wesentlichen in der Steuerbarkeit und Kontrollierbarkeit des Entwicklungsprozesses liegen. Projekte können also im Grunde als ein organisatorisches Notkonstrukt angesehen werden, dessen Logik sich weniger aus der angestrebten Entwicklung als aus Anforderungen der Abwicklung ableitet.

Durch diese Verschränkung der Projekte mit ihrer Vor- und Nachgeschichte erhält der projektübergreifende Wissenstransfer bei der Software-Entwicklung große Bedeutung: Wie kann der vorhandene Bestand an Wissen und Erfahrungen für das jeweilige Projekt aktiviert werden? Wie können allgemein die in den verschiedenen Projekten gesammelten Erfahrungen im Unternehmen zusammengeführt und verfügbar gemacht werden? Die Frage der systematischen projektübergreifenden Erfahrungs- und Wissensakkumulation gewinnt in dem Maß an Gewicht, in dem integrierte Gestaltungsansätze angestrebt werden.

Dokumentation der "Konstruktion" der SW

Diesen Wissenstransfer zu verbessern, war in einem Teil der von uns untersuchten Unternehmen Ziel systematischer Maßnahmen. Diese galten vor allem der Dokumentation der "Konstruktion" der erstellten Software. Obwohl es sich um eine nach wie vor von den Entwicklern ungeliebte Aufgabe handelt, scheinen hier doch in den letzten Jahren in vielen Unternehmen Fortschritte erzielt worden zu sein.

Teilweise wurde auch personelle Mobilität gezielt als Instrument des Wissenstransfers eingesetzt. Durch die wechselnde Zusammensetzung von Projektteams sollte Wissen vermittelt und ausgetauscht werden.

Als Teil der projektübergreifenden Wissensweitergabe kann auch die Leistungserfassung angesehen werden, wo sie nicht - oder nicht nur - der Projektsteuerung und -kontrolle, sondern auch der systematischen Sammlung von Erfahrungswerten diente, an

denen man sich bei der Planung und Kalkulation nachfolgender Projekte mit ähnlich gearteter Aufgabenstruktur orientieren kann.

Nachvollziehbarer Entstehungsprozeß

Diese Versuche, den projektübergreifenden Wissensaustausch zu verbessern, waren vor allem auf die Vermittlung von unmittelbar projekt- und verfahrensbezogenem Wissen ausgerichtet: der Dokumentation des Aufbaus eines Softwareprodukts und der einzelnen Entwicklungsschritte, durch die der Prozeß seiner Entstehung für einen Unbeteiligten nachvollziehbar gestaltet werden konnte. Oder: die Dokumentation des Arbeitsaufwands, der für diesen Entwicklungsprozeß notwendig war.

Diese "offizielle" Dokumentation deckte aber nur einen Teil des verfügbaren Know-hows ab. Sie machte den nackten Prozeß der Konstruktion des Softwareprodukts nachvollziehbar. Weitgehend dem Zufall überlassen blieb in den meisten Projekten dagegen die Konservierung und Aktivierung des kontextuellen Wissens, also jener Erkenntnisse und Erfahrungen, die im Verlauf des Entwicklungsprozesses bei der Anwendung der Instrumente und Verfahren, im Umgang mit den Anwendern und in der Auseinandersetzung mit dem Anwendungsgebiet gemacht beziehungsweise erworben wurden. Dieses kontextuelle Wissen war höchstens indirekt und in Ansätzen aus der "offiziellen" Dokumentation ablesbar.

Ein eindrucksvolles Beispiel von fehlendem Transfer des kontextuellen Wissens lieferten zwei aufeinanderfolgende Projekte, die in derselben Abteilung eines Softwarehauses abgewickelt wurden. Während das erste sehr erfolgreich innerhalb des gesetzten, sehr knappen Zeit- und Budgetrahmens abgeschlossen werden konnte, ergaben sich beim zweiten Schwierigkeiten, die zu erheblichen Verzögerungen und Überziehungen führten. Diese waren zum Teil auf technische Probleme zurückzuführen, vor allem aber auf

eine Gestaltung des Personaleinsatzes, die zu einer recht ineffektiven Nutzung der Personalressourcen führte. Dabei blieben die sehr positiven Erfahrungen aus dem vorangegangenen Projekt weitgehend unberücksichtigt.

Ferner war bei vielen Software-Entwicklern die Bereitschaft, kontextuelles Wissen abzugeben, es allgemein und anonym zur Verfügung zu stellen, eher gering - verständlicherweise, denn hier gilt in besonderem Maß, daß Wissen Unentbehrlichkeit und damit Macht bedeutet.

Deshalb wurde auch die Wirksamkeit formalisierter oder computergestützter Formen des projektübergreifenden Wissenstransfers häufig skeptisch beurteilt. Dies gilt zum Beispiel für die Nutzung von Electronic Mail als Medium des Erfahrungs- und Wissensaustausches zwischen verschiedenen Entwicklerteams. So wurde in einem Großunternehmen der "Electronic Marketplace", der als eine Art Informationsbörse eingerichtet worden war, sehr negativ beurteilt. "Da haben die Leute ihre Hobbypartner gesucht oder

Fahrradtouren arrangiert, aber wenn jemand wirklich ein Entwicklungsproblem hatte, bekam er kaum Hilfe."

Dies wurde unter anderem aus dem Konkurrenzverhältnis zwischen den einzelnen Entwicklungsteams erklärt, das solch öffentlichen ungesteuerten Wissenstransfer behinderte, wenn die Verwertung der eingebrachten Informationen nicht absehbar war. Das anonyme elektronische Medium für sich allein erwies sich als wenig geeignet, die wechselseitige Abschottung der verschiedenen Teams aufzuheben. Dabei wären gerade systematische, institutionalisierte Maßnahmen erforderlich, um das informelle, kontextuelle

Know-how zu vermitteln und verfügbar zu machen.

Eine äußerst effektive Form solchen projektübergreifenden kontextuellen Wissenstransfers waren in einigen Projekten aber die Reviews, die Entwickler aus unterschiedlichen Teams zusammenführten und die nicht nur zu einer Abstimmung der

Entwicklungsarbeiten geführt zu haben scheinen, sondern darüber hinaus auch als Forum für allgemeinen Erfahrungsaustausch dienten.

Ebenfalls von Belang erscheint unter diesem Aspekt die Institution des "Paten", auf die wir in einem Unternehmen trafen. Er hatte nicht nur neueingestellte Mitarbeiter zu, betreuen, sondern stand diesen auch weiterhin zur Verfügung, wann immer das Bedürfnis nach Beratung bestand. Die Tatsache, daß diese Möglichkeit nicht nur für die Beratung bei rein technischen Problemen in Anspruch genommen wurde, zeigt, daß projektübergreifender Erfahrungsaustausch als nützlich und hilfreich begriffen wurde.

Bei diesen Maßnahmen war die Vermittlung kontextuellen Wissens nicht primäres Ziel, sondern eher ein Nebeneffekt. Die allgemein bestehenden Defizite im projektübergreifenden Wissenstransfer ließen sich damit keinesfalls ausgleichen.

Folge des fehlenden Transfers war die erstaunlich geringe institutionelle Lernfähigkeit, der wir in zahlreichen Unternehmen begegneten und die dafür sorgte, daß mit bemerkenswerter Beharrlichkeit Fehler wiederholt wurden oder Fehlentwicklungen unkorrigiert blieben. Solche Fehlentwicklungen, die angesichts der meist langjährigen Erfahrungen in der Gestaltung von Softwareprojekten schwer erklärbar erschienen, waren etwa:

- Entwicklungsprobleme versucht man, durch die rein numerische Verstärkung der personellen Kapazität zu lösen (mythischer Mann-Monat). Die Folgen dieser Strategie: Unerfahrene Entwickler wurden ohne ausreichende Anleitung und Betreuung an Aufgaben gesetzt, die sie überforderten; der Koordinierungs- und Abstimmungsaufwand stieg überproportional, die Produktivität der einzelnen Entwickler sank.

- Man setzte den notwendigen Entwicklungaufwand zu niedrig an und war dann gezwungen, nach oben zu korrigieren.

- Die Personaleinsatzplanung mit entsprechend negativen Auswirkungen auf die Produktivität der Entwicklungsteams wurde vernachlässigt.

- Man gab sich mit einem Scheinkonsens zufrieden, der sich dann später als wenig tragfähig erwies und zu zeitraubenden neuerlichen Klärungs- und Abstimmungsprozessen führte.

Konsens beruhte auf ungenauer Kenntnis

Diesen Fehlentwicklungen - so unterschiedlich sie sich im einzelnen äußerten - war eines gemein: Sie verwiesen letztlich auf mangelnden Realitätsbezug. Man begnügte sich mit der formalen Dokumentation des Konsenses etwa in einem Protokoll. Bei genauerer und unvoreingenommener Analyse wäre rasch deutlich geworden, daß wesentliche Divergenzen weiterbestanden oder aber der Konsens letztlich nur auf ungenauer Kenntnis beziehungsweise Untersuchung der Problemlage erfolgt war. Man nahm die numerische

Stärke des Entwicklungsteams sozusagen als Indikator für seine tatsächliche Entwicklungspotenz, obwohl doch vorangegangene Projekte die Fehlerhaftigkeit dieses Ansatzes gezeigt hatten.

Die fehlende Berücksichtigung von informellen, kontextuellen Erfahrungen führte bisweilen dazu, daß aus dem Ablauf und den Ergebnissen von Projekten falsche Schlüsse gezogen wurden.

So schränkte in einem Entwicklungsprojekt eines Softwarehauses ein formalisiertes Projekt-Management den Spielraum der einzelnen Entwickler bei der Bewältigung ihrer Auf gaben ein.

Nur durch Geschick und Engagement der Projektleitef in gelang es, die Wirkung dieses Korsetts abzufangen. Mit diesem Erfolg wurde absurderweise die weitere Perfektionierung des formalisierten Instrumentariums legitimiert.

In eklatanten Wiederspruch zu der mangelnden institutionellen Lernfähigkeit in vielen Unternehmen stand die individuelle Verarbeitung von Erkenntnissen. In fast allen Gesprächen, die wir mit Entwicklern, Projektleitern und -managern führten, bezogen diese sich immer wieder auf ihre Erfahrungen, die sie in früheren Projekten gemacht hatten. Sie schilderten die Lehren und Konsequenzen, die sie für ihr zukünftiges Verhalten daraus gezogen hätten. Selbstverständlich darf aus einer solchen verbalen Verarbeitung noch nicht auf Verhalten geschlossen werden. Es wurde sehr deutlich - und dies nicht nur bei Berufsanfängern daß die Projektarbeit in star kein Maß als ein Lernprozeß begriffen wurde.

Warum hatten diese individuellen Lernprozesse so geringe Auswirkungen auf die institutionelle Lernfähigkeit? Bei unseren Recherchen beeindruckte jedesmal aufs neue das Maß an Reflexion und Einsicht, das bei Projektleitern und -managern sowie bei

Entwicklern und Anwendern erkennbar war. In großem Gegensatz dazu stand die enorme Diskrepanz zu der "offiziellen" Praxis.

Nun begegnen wir dieser Vernachlässigung von kontextuellern Wissen, der Diskrepanz zwischen praktizierter und offizieller Wirklichkeit nicht nur in der Software-Entwicklung, sondern auch in anderen Entwicklungsprojekten.

Unsere Untersuchungen vermittelten allerdings den Eindruck, daß diese Diskrepanz in der Software-Entwicklung besonders ausgeprägt ist und sich auch besonders stark auswirkt.

Dafür gibt es plausible Erklärungen. Sie sind in dem beschriebenen Spannungsverhältnis zwischen Projektorganisation und übergreifenden Entwicklungszusammenhängen zu suchen, in der besonderen Organisationsform vieler Projekte, deren finanziellen Rahmenbedingungen und in der ausgeprägten Diskontinuität des Personaleinsatzes.

Wechselnde personelle Konsteltationen und wechselnde Aufgabenzuordnung erschwerten zweifelsohne die institutionelle Verarbeitung individueller Lernprozesse.

Neben der Gestaltung des Personaleinsatzes spielte auch die Konkurrenz zwischen verschiedenen Entwicklungsteams und der projektspezifische Erfolgsdruck eine Rolle. Je höher der Erfolgs- und Legitimationsdruck, unter dem ein Projekt stand, desto geringer die Chance, daß kontextuelles Wissen auch weitervermittelt und verfügbar gehalten wurde - und desto größer war auch die Gefahr, daß "offizielle" und praktizierte Wirklichkeit in den Projekten auseinanderklafften.

Ein primär technischer Entwicklungsprozeß

Zur mangelnden Berücksichtigung und Vermittlung kontextuellen Wissens trug sicher das vielfach dominierende Verständnis der Software-Entwicklung bei, sie sei ein ausschließlich oder primär technischer Entwicklungsprozeß.

Vernachlässigt wird dabei die Tatsache, daß Software-Entwicklung zumeist auch Arbeitsstrukturierung heißt, und daß sie damit immer zugleich auch ein sozialer und betriebspolitischer Prozeß ist.

All dies zeigt die besondere Bedeutung von Maßnahmen zur systematischen Sicherstellung des projektübergreifenden Erfahrungs- und Wissenstransfer. Zugleich wird deutlich, daß sich diese Aktionen nicht auf die Verbesserung "technischer" Dokumentation der einzelnen Entwicklungsschritte beschränken dürfen, sondern sich umfassend auf das kontextuelle Wissen beziehen müssen.

Literatur:Friedrich Weltz: Aus Fehlern lernen - ein Ansatz zur Qtialitätsförderung im Büro. In: Office Management, 6/1989, S. 20-22.

Friedrich Weltz: Die doppelte Wirklichkeit der Unternehmen und ihre Konsequenzen für die industriesoziologie. In: soziale Welt, 1/1988, S. 97-103.