18 WISSEN 19 D eutsche Ingenieure genießen weltweit einen exzellenten Ruf. Man schätzt ihre fachliche Qualifikation, das außergewöhnliche Qualitätsbewusstsein und den Ideenreichtum, mit dem sie Neues kreieren und sich dabei offenbar permanent selbst übertreffen wollen. International wird allerdings nicht ohne Schadenfreude registriert, dass bei deutschen Unternehmen die hohen technologischen Ansprüche und allzu ehrgeizige Entwicklungszeiten über ein drastisches Ansteigen von Produktmängeln erkauft werden. Was zutiefst beunruhigen muss, ist, dass es für die hohen Nacharbeits- und Gewährleistungskosten scheinbar keine Vorwarnsysteme gibt. Anfänglich attraktive Vorhaben geraten so binnen kurzer Zeit in ein wirtschaftliches Desaster. Planungen werden zu einem Zeitpunkt erstellt, zu dem niemand wissen kann, wie viel Zeit die einzelnen Planungseinheiten benötigen Uns geht es darum aufzuzeigen, welche gravierenden Fehler Unternehmen in Produktentwicklungsprojekten immer wieder begehen und was man tun kann, um die Floprate zu senken und um die gesetzten Ziele zuverlässiger zu erreichen. Vor Beginn eines Projektes geht das Unternehmen davon aus, dass es das Vorhaben „in time“ und zum festgelegten Budget - inklusive der Gewährleistungsansprüche und -kosten, die später eventuell anfallen - bewältigen kann. Man ist überzeugt, das im Rahmen der vereinbarten Planungseckdaten profitabel zu realisieren. Ihre Zuversicht zieht die Führungsmannschaft häufig aus der Akribie, mit der das Entwicklungsteam das Projekt aufgesetzt hat. Nichts scheint vergessen worden zu sein. Die zahlreichen Projektaktivitäten wurden bis ins letzte Detail durchgeplant, synchronisiert und dann auf die verschiedenen beteiligten Unternehmensbereiche bzw. Mitarbeiter und Teilprojektteams verteilt. Um eine kurze „time to market“ zu realisieren, sollen möglichst viele Aufgaben parallel abgearbeitet werden. Den Teilprojektteams, die auf Basis der Detailplanungen häufig recht autonom agieren, wird dann im Allgemeinen ein relativ enges Zeit-Korsett angelegt - schließlich sollen die Entwickler ja nicht „l’art pour l’art“ betreiben, sondern mit größtmöglicher Effizienz ein neues Produkt zur Reife bringen. Wenngleich das eine oder andere Team-Mitglied bereits zu diesem Zeitpunkt Bauchschmerzen wegen des engen Zeitrahmens bekommen mag - letztlich bleibt nichts anderes übrig, als sich dem Commitment der anderen anzuschließen. Die Einschätzung, dass die Wahrscheinlichkeit eines Projekterfolges umso größer ist, je detaillierter man das Projekt von Beginn an durchgeplant hat, ist durchaus nachvollziehbar. Logisch auch, dass dieser Projekt- Plan dann gnadenlos durchgezogen wird, sobald das Commitment aller am Projekt beteiligten Bereiche oder Teams erst einmal vorliegt. Leider beweist uns die Pra- Wie Entwicklungsprojekte vor dem Scheitern bewahrt werden Die Floprate bei Innovationen könnte niedriger sein Reinhard Meinders, Thomas Gutberlet Nicht erst durch aktuelle - öffentlichkeitswirksame - Beispiele wird deutlich, dass Entwicklungsprojekte ihre eigenen Gesetze haben. Kürzere Entwicklungszeiten erfordern eine zunehmende Prozessparallelisierung mit steigenden Anforderungen an die Projektkommunikation. Produkte, aber auch die Anbieterkonstellationen, haben an Komplexität zugelegt. Dazu kommt, dass die Dynamik der Absatzmärkte bzw. Kundenanforderungen gestiegen ist, und dies alles unter einem erheblichen Kostendruck. Kein Wunder also, dass derartige Projekte Unwägbarkeiten enthalten, die man nicht ignorieren darf und die auch nicht vorab planbar sind. Umso wichtiger wird es, während der Projektlaufzeit Frühwarnsysteme nutzen zu können, die nach Möglichkeit automatisiert auf „Schräglagen“ aufmerksam machen. Einige Prinzipien können dabei helfen, geeignete Frühwarnsysteme zu konzipieren und zu installieren. Unsere Prinzipien leiten sich ab aus natürlichen Systemen („Sandkornprinzip“, „Waldbrandrisiko“), aber auch aus anderen Bereichen der Technik („Pull“-Prinzip für projektbezogene Information). Die Umsetzung dieser Prinzipien in ein geeignetes Projektcontrolling, aber auch eine Veränderung der Kultur zum Thema „Fehler und Mängel“ sowie konsequente Dezentralisierung der Verantwortlichkeiten und Kompetenzen leisten Beiträge, Risiken komplexer Projekte zu reduzieren. aktuell projekt M A N A G E M E NT 1/ 20 0 4 projekt M A N A G E M E NT 1/ 20 0 4 aktuell 18 WISSEN 19 xis immer wieder, dass auch scheinbar noch so brillant geplante Projekte öfter scheitern, als man gemeinhin vermuten würde. Der Grund hierfür liegt darin, dass die Planungen zu einem Zeitpunkt erstellt werden, zu dem eigentlich noch niemand mit der erforderlichen Sicherheit wissen kann, wie viel Zeit die einzelnen Planungseinheiten tatsächlich benötigen werden und welche Aufwendungen sie verursachen werden. Häufig wird eine Planbarkeit unterstellt, die wegen der vielfältigen Unwägbarkeiten, die solchen Projekten immanent sind, realiter zu diesem Zeitpunkt einfach nicht gegeben ist. Dies alles wäre nicht so schlimm, wenn die Verantwortlichen im Verlauf des Projektes, bei verbessertem Erkenntnisstand, Planungen adjustieren würden, worauf leider häufig verzichtet wird. Zum einen scheut man den damit verbundenen Aufwand (auch aus mangelnder Flexibilität der Planungstools). Zum anderen möchte man natürlich auch dem Top-Management bzw. dem Auftraggeber gegenüber nicht auffallen. Hat man sich zum Beispiel auf einen Zeithorizont von elf Monaten verpflichtet, dann bleibt es auch dabei. Basta! Obwohl erfahrene Projektmanager wissen, dass die unterstellte Planbarkeit letztlich eine Illusion ist, tut man so, als sei das Ergebnis der Planung eine stabile Zahl. Folgerichtig nötigt man die Projektmitarbeiter, sich im geplanten Rahmen zu bewegen. Sobald diese merken, dass die Vorgaben nicht einzuhalten sein werden, gehen sie dazu über, bestimmte Aufwände, die ins bereitgestellte Manntage- oder Zeitbudget nicht mehr hineingepasst haben, zu „verstecken“. Ursprünglich vorgesehene - weniger bedeutende - Funktionalitäten werden etwas einfacher ausgestaltet, Tests und Dokumentationen vernachlässigt oder Aufwände in Folgephasen verschoben, in denen sie noch nicht auffallen. Nach außen hin wird so getan, als sei alles im Lot. Realiter summieren sich die einzelnen Vertuschungen aber zu einem nicht mehr beherrschbaren Ausmaß. Der „Dreck“, der monatelang unter den Teppich gekehrt wurde, kommt spätestens bei der Inbetriebnahme zum Vorschein. Dann werden die Verantwortlichen in vielen Fällen mit der bitteren Wahrheit konfrontiert, dass der Teppich längst die Bodenhaftung verloren hatte: Die Projektrealität hatte sich im Laufe der Zeit meilenweit von der Planung entfernt, Ziele im Hinblick auf Termine und Kosten sind nun nicht mehr zu erreichen. Manchmal sind die Verfehlungen so groß, dass das Ganze in einem Desaster endet - wie zum Beispiel bei unserer deutschen LKW-Maut. Trotz eines durch Gerichtsverfahren um acht Monate verkürzten Zeitplans ließen sich DaimlerChrysler und die Telekom auf die Vorgabe des damaligen Bundesverkehrsministers Bodewig ein, das erste satellitengestützte Mautsystem der Welt zum 1. September 2003 starten zu können. Die Telekom erhoffte sich von dem Projekt ein Ansteigen der Aktienkurse, die Stuttgarter konnten davon ausgehen, mit dem Renommierprojekt eine Vorreiterrolle im weltweiten Geschäft mit Verkehrsleitsystemen und dem Inkasso von Straßenbenutzungsgebühren einzunehmen. Gründe genug, um auch unter verschärften Rahmenbedingungen den Projektauftrag unbedingt gewinnen zu wollen. Und auch der Verkehrsminister konnte zufrieden sein: Immerhin hatte er zwei deutsche Industriegiganten mit hohem Renommee bzw. deren gemeinsame Tochter „Toll Collect“ als Betreiberfirma verpflichtet - und diese hatten sich ihm gegenüber verpflichtet und die Inbetriebnahme „in time“ und gemäß dem vereinbarten Budget zugesichert. Die Präsentationen der Projektmanager waren beruhigend, maßgebliche Lieferanten hatten die Termine fest zugesagt. Folgerichtig demonstrierte Toll-Collect-Firmenchef Michael Rummel noch im April öffentlich Zuversicht: „Wir starten pünktlich am 30. August, 0.00 Uhr, mit der LKW-Mauterhebung. Wir sind genau im Zeitplan.“[1] Der „Dreck“, der monatelang unter den Teppich gekehrt wurde, kommt spätestens bei der Inbetriebnahme zum Vorschein Dass dieser Zeitplan dann doch nicht eingehalten werden konnte, hatte - wie ein Insider aus dem Kreis der Konsorten in der April- und der Juni-Ausgabe der angesehenen IT-Zeitschrift „CIO“ zu berichten wusste - insbesondere folgende Ursachen:  getrennte Entwicklungsmannschaften, zu viele Entwickler, keine einheitlichen Entwicklungsstandards. Statt von einer Kernsoftware aus die Pro- ��������������������������� web based Project Management Sie führen multilokale Projekte? Sie wollen keine Investitionen in Tools tätigen? Sie sind unter Zeitdruck? Sie erwarten umfassenden Support? HISC AG Projektmanagement, CH-8733 Eschenbach Tel. +41 (0)55 286 46 66 Fax -60 www.hisc.ch www.pmportal.biz Breite Projektmanagement Abdeckung (gemäss IPMA / PMI) Meetings, Test - und Change Management, Planung, Kosten Controlling, Offene Punkte / Pendenzen, Arbeitsaufträge, Referenzmodelle, Dokumente, Effizientes und bewährtes Projektverfahren ������������������� ������������������������� ������� ������� �������� ����� �������� �������� Anzeige aktuell projekt M A N A G E M E NT 1/ 20 0 4 projekt M A N A G E M E NT 1/ 20 0 4 aktuell 20 WISSEN 21 grammteile etwa für LKW-Daten zu erstellen, habe T-Systems verschiedene Module der Mautsoftware an unterschiedlichen Standorten entwickeln lassen.  Risikoreicher Entwicklungsansatz von dezentral zu zentral sowie unterschiedliche, nicht integrierbare Teilsysteme - eine „Todsünde“ in der Softwareentwicklung. Wie auch immer die Geschichte ausgehen mag, teuer wird sie in jedem Fall - für den Auftraggeber ebenso wie für den Betreiber. Jeder Monat Verzögerung führt zu Einnahmeausfällen im dreistelligen Millionenbereich. Die ursprünglichen Rentabilitätsberechnungen dürften wohl schon jetzt Makulatur sein. Geld werden die Konzerne mit diesem Projekt voraussichtlich keines verdienen. Zu befürchten ist vielmehr das Gegenteil - insbesondere, wenn die Prognose des Bundesamtes für Güterverkehr (BAG) Realität werden sollte. Die Experten dort rechnen nach Informationen der „Welt“ mit einem Start „nicht vor Ostern 2004“. So weit, so schlecht. Wir haben dieses Beispiel deshalb geschildert, weil sich daran festmachen lässt, worauf die Schieflage so vieler Produktentwicklungsprojekte maßgeblich beruht: auf dem irrigen Glauben, dass man komplexe Entwicklungsprojekte über detailliertes Planen und mit den gleichen Verfahren angehen kann wie Standardprojekte. Der sich daran anschließende, nicht minder gravierende Fehler besteht darin, dass die mit hohem Aufwand erstellten Projektpläne quasi als Dogma angesehen und - über eine Art Gruppenzwang - abgearbeitet werden, weil man sich dem Management bzw. den Auftraggebern gegenüber dazu verpflichtet hat. Entwicklungsprojekte enthalten aber Unwägbarkeiten, die man nicht durch starre Planungsraster in den Griff bekommen kann. Dies gilt insbesondere für komplexe Projekte. Durch die unterstellte Planbarkeit zwängt man das Projekt in ein Korsett, das in vielen Fällen schon nach kürzester Zeit zwackt und das sich mit fortschreitender Zeit immer weiter von der Realität entfernt. Angebotene Planungstools sind im Hinblick auf ihre Anpassungsfähigkeit an die Projektrealität im „Handling“ z. T. so schwerfällig, dass die Projektteams gar nicht erst den Versuch einer Adjustierung unternehmen. Die Planung ist über kurz oder lang dann gerade noch das Papier wert, auf dem sie die Wände schmückt. Wir hegen keinerlei Zweifel daran, dass alle Beteiligten im Maut-Projekt nach bestem Wissen und mit enormem Engagement versucht haben, gesetzte Ziele und Terminvorgaben einzuhalten. Fraglich ist, ob es nicht Indikatoren gegeben hat, die die sich anbahnende Fehlentwicklung dem Management hätten anzeigen können. Wir vermuten, dass es sie gegeben hat. Aus Erfahrung wissen wir aber auch, dass keiner der Erste sein möchte, wenn es darum geht, Probleme zuzugeben. Genau in einer solchen Haltung liegt indes die Gefahr der Risikounterschätzung. Je komplexer ein Entwicklungsprojekt ist und je dezentralisierter man die Produktentwicklung organisiert und die Aufgabenverteilung parallelisiert hat, umso gravierender werden die Konsequenzen, wenn man sich anbahnende kritische Zustände nicht rechtzeitig erkennt und konsequent gegen sie vorgeht. Die folgenden Ansätze können einen signifikanten Beitrag leisten, die geschilderten Probleme in den Griff zu bekommen. Prozess-Controlling - Automatische Meldung von Mängel-Indikatoren an Schlüsselpersonen Nach unseren Erfahrungen ist es irrelevant, sich en detail mit dem Terminverzug eines einzelnen Vorgangs zu beschäftigen. Kritisch zu analysieren ist vielmehr die Summe der Verzugstage aus allen Vorgängen in einem Projekt. Ein verspäteter Start ist dabei genauso ein Verzug wie eine zu späte Beendigung. Diese Erkenntnis lässt sich recht anschaulich an dem so genannten Sandkorn-Beispiel erläutern: Wenn man ständig auf eine Stelle Sandkörner fallen lässt, beginnt sich ein Sandhaufen aufzutürmen, der in unregelmäßigen Abständen wieder zusammenrutscht. Im Rahmen der Erforschung von Indikatoren sich anbahnender Erdbeben hat man diesen Vorgang tausend Mal wiederholt. Man hatte versucht herauszubekommen, nach welcher Gesetzmäßigkeit dieses „Sandrutschen“ entsteht und warum es manchmal nur sehr gering und manchmal heftiger ausfällt, obwohl doch immer ein gleich großes Sandkorn aus gleicher Höhe herunterfällt. Im Endergebnis mussten die Wissenschaftler erkennen, dass es keinerlei Gesetzmäßigkeit für diesen Zeitpunkt gibt. Man konnte lediglich eine Potenzkurve für die Verteilung der Größe und Häufigkeit eines Sandrutsches von einem einzelnen Sandkorn bis zum Rutschen des gesamten Haufens ermitteln. Nicht Zeitpunkt und Anzahl der gefallenen Sandkörner bis zum Eintreten des „Erdrutsches“ waren damit für die Wissenschaft interessant, sondern das Erkennen des „Kritischen Zustandes“, ab dem es schon bei einem einzelnen Sandkorn zu wahrscheinlichem Rutschen kommt. Ähnlich verhält es sich mit den Wirkungen von Terminverzügen einzelner Arbeitspakete auf die Endtermin-Zuverlässigkeit in einem Projekt. Man sollte sich daher nicht zu sehr auf den Verzug eines einzelnen Vorganges stürzen. Viel wichtiger ist es zu erkennen, ob das Projekt sich insgesamt in einen kritischen Zustand hinein entwickelt (Abb. 1). Um kritische Zustände zu erkennen, genügen im Allgemeinen wenige Indikatoren: � �� �� � � � � � � � � ���� Man sollte sich nicht zu sehr auf den Verzug eines einzelnen Vorganges stürzen. Viel wichtiger ist es zu erkennen, ob das Projekt sich insgesamt in einen kritischen Zustand hinein entwickelt. Abb. 1: Weniger die Erkennung der großen Probleme, sondern die Häufung vieler kleiner ist zu lösen. aktuell projekt M A N A G E M E NT 1/ 20 0 4 projekt M A N A G E M E NT 1/ 20 0 4 aktuell 20 WISSEN 21  kumulierte Verzugstage aller aktiven Vorgänge,  Budgetüberschreitungen auf Modulebene,  Anzahl Wiederholschleifen bei Versuch und Test bzw. Fehlerentwicklung,  Fehlerumfang der Komponenten. Projekte sind nach unseren Erfahrungen häufig in ein so enges Raster gezwängt, dass die Summierung kleinster Planabweichungen bereits ausreicht, um Kettenreaktionen hervorzurufen, die zu ernsten Projekt-Krisen führen. Jede einzelne Planabweichung würde für sich betrachtet selbst bei äußerst akribischem Controlling kaum zur Besorgnis Anlass geben. Der kritische Zustand wird jeweils erst bei einer Summierung der Einzelabweichungen sichtbar. Bildlich kann man sich dieses Phänomen recht gut an einer Reihe zu eng aufgestellter Domino-Steine vorstellen. Fällt ein Stein um, kommt es zu einer Kettenreaktion, die die meisten anderen Steine ebenfalls zu Fall bringt. Wissenschaftliche Untersuchungen haben auf anderen Feldern vergleichbare Effekte gezeigt: So steigt beispielsweise die Wahrscheinlichkeit großer Waldbrände, je dichter die Bäume in einem Wald stehen. Die Projektleitung konzentriert sich in aller Regel auf große Ausreißer - zum Beispiel, wenn bei einem bestimmten Teilprojekt ein Verzug von 30 Manntagen diagnostiziert wird. Dies hat dann nur noch wenig mit professionellem Projektmanagement zu tun, sondern ähnelt eher den Feuerwehr-Einsätzen, wie sie von Krisensituationen bekannt sind. Wie es zu den Verzügen gekommen ist, ob eventuell mehrere vorgelagerte Teilprojekte kleinere Überschreitungen von vier, fünf oder sechs Manntagen vor sich hergeschoben haben, wird selten untersucht: Diese Überschreitungen haben den selbst gesetzten Schwellenwert, ab dem die Alarmglocken zu klingeln beginnen, ja nicht erreicht. Für jeden einzelnen „Zeitüberzieher“ gibt die Situation denn auch kaum Anlass zur Besorgnis: Man ist ja nur vier Tage in Verzug. Wenn es bei vierzig oder fünfzig Teilprojekten allerdings zu ähnlichen Überziehungen gekommen ist, könnte das Kind schon in den Brunnen gefallen sein, bevor auch nur irgendein Warnsignal auf signifikante Abweichungen hingewiesen hätte. Alles scheint im Lot zu sein. Dass sich das Projekt längst in einer gefährlichen „Schieflage“ befindet, wird nicht erkannt - weil sich die Projektleitung nur auf die Spitzen konzentriert und keine Kumulierung der Einzelüberziehungen vornimmt. Ein ähnliches Verhalten ist bei Budgetüberschreitungen festzustellen. Auch hier meinen die Verantwortlichen, leichte Überziehungen hinnehmen zu können - auch weil man überzeugt ist, dieses Manko im Verlauf des Projektes an anderer Stelle durch Einsparungen wieder ausbügeln zu können. Organisierter Erkenntnisaustausch - Kommunikation funktioniert nicht von alleine, man muss sich darum kümmern Die unter dem Diktat permanenten Termindrucks bei komplexen Projekten inzwischen allseits üblichen Aufgaben-Dezentralisierungen und -Parallelisierungen zwingen zu einem geänderten Kommunikationsverhalten. Entwicklungsprojekte leben vom „Erkenntnisaustausch“ der Projektbeteiligten. In kleineren Projekten funktioniert dies häufig über informelle Gespräche in der Kantine oder auf dem Flur und man bespricht, was einem Sorgen bereitet. In komplexen, auf verschiedene Organisationseinheiten oder gar Unternehmen verteilten Produktentwicklungen stellt sich dieses Problem in einer ganz anderen Dimension dar. In der Disposition eines Produktionsprozesses plant man im Grunde das „Fließen“ einzelner Teilemengen. Man produziert etwas, transportiert es zum nächsten Arbeitsplatz und so fort und so fort. Die Aufgabe für die Produktionsverantwortlichen besteht darin, möglichst optimale Fertigungs- und Transportlose zu planen und deren effizienten Durchlauf zu organisieren. Bei einem Produktentwicklungsprojekt sind die Transportlose die Erkenntnisse bzw. die jeweiligen Erkenntniszuwächse - Spezifikationen, Stücklisten, Zeichnungen u. Ä. Letzten Endes geht es also darum, den Wissenstransfer zwischen den Beteiligten zu optimieren. Je schlechter ein Projekt dasteht, um so mehr wird diesem Projekt noch Energie entzogen Genau darum kümmern sich nach unseren Erfahrungen die meisten Projektverantwortlichen aber nur unzureichend. Jeder meint, dass die Dokumentation des Wissens in der Projektdatenbank bereits ausreicht. Dies ist leider nicht der Fall, wie die Praxis immer wieder zeigt. Ein Erkenntniszuwachs in einem Entwicklungsprozess ist nicht schon dadurch „Realität“, dass man ihn dokumentiert. Damit arbeiten und darauf aufbauen kann man erst, wenn dieses Wissen bei demjenigen angekommen ist, der damit weiterarbeiten soll, und dieser auch mit der Qualität der gelieferten Erkenntnisse so zufrieden ist, dass er damit auch weiterarbeiten kann. Die Crux besteht nun darin, dass der „Workflow“ erforderlicher Kommunikation wegen der hohen Komplexität, die Entwicklungsprojekten immanent ist, nicht vordefiniert werden kann - obwohl jeder Beteiligte sehr wohl weiß, von welchen Ergebnissen er bei seiner Aufgabe abhängig ist. Viele Unternehmen versuchen das Kommunikationsproblem zu beheben, indem sie eine zentral organisierte Informationsverteilung etablieren. Dies führt dazu, dass man die nunmehr überbordende Vielzahl eingehender Mails nur noch quer lesen kann, wenn man sie denn überhaupt noch registriert. Tauchen die ersten Probleme auf, nimmt die Zahl der Projektmeetings zu, wobei die Relevanz für den Einzelnen oft in gleichem Maße abnimmt. Zeit und Energie, die eigentlich in die Projektarbeit fließen sollen, werden für Blindleistungen, etwa ein verschärftes Controlling, verbraucht. Und wie wir in unseren Beratungsprojekten immer wieder feststellen mussten, steigt das Ausmaß der Blindleistungen mit dem Zustand des Projektes: Je schlechter ein Projekt dasteht, umso mehr wird diesem Projekt noch Energie entzogen, die eigentlich für konstruktive Problemlösungsansätze hätte verwendet werden können. Wie man den erforderlichen Erkenntnisaustausch in einem Projekt bei einer ausgeprägten Dezentralisierung der Aufgabenabwicklung effizienter gewährleisten kann, zeigt das Beispiel einer internationalen Polizeiaktuell projekt M A N A G E M E NT 1/ 20 0 4 projekt M A N A G E M E NT 1/ 20 0 4 aktuell 22 WISSEN 23 behörde, deren raffinierten Lösungsansatz wir im Rahmen eines Beratungsprojektes kennen lernten. Dort kommt niemand auf die Idee, bei Vorgängen internationaler Kriminalität und bei bis zu tausend relevanten Vorgängen und Dokumenten sowie diversen beteiligten Länderpolizeien einen zentral organisierten Informationsaustausch aufzubauen. Vielmehr gibt es eine so genannte „Notice of Interest“ (NOI), die ein Interessent an ein für ihn relevantes Objekt (z. B. das Kennzeichen eines Fluchtfahrzeugs) hängen kann. Von diesem Zeitpunkt an erhält der Betreffende dann alle neuen Erkenntnisse zu dem „markierten“ Objekt sowie Hinweise über die Informationsquelle. Wesentlich dabei ist, dass das Informationsaufkommen zu den interessanten Objekten dezentral gesteuert ist. Jeder Interessent bestimmt selbst, zu welchen Objekten er Neuigkeiten erfahren will. Damit hat es jeder selbst in der Hand, das Informationsaufkommen zu bestimmen, das auf ihn einstürmt. Im Gegensatz zu der zentral organisierten Informationsverteilung haben wir es hier also mit einem „Pull“- Prinzip in der Erkenntnisverbreitung zu tun. Jeder erfahrene Entwickler weiß, welche Informationen, Vorarbeiten etc. er benötigt, um seine Aufgabe angehen zu können. Unsicherheit besteht aber darüber, wann er diese Informationen erhält. Meist versuchen die Unternehmen, über die Einberufung regelmäßiger Projekt- Meetings den aktuellen Erkenntnisstand auszuloten. Über ein „Pull“-Prinzip und die Automatisierung der Weitergabe von Erkenntniszuwächsen könnte die Effektivität deutlich gesteigert werden. Dezentralisierung von Steuerungskompetenzen - Fraktalitätsprinzip in der Unterorganisation großer Projekte Eine zielführende Erkenntniszuwachsverteilung ist nur die eine Seite der Medaille. Wenn die dezentral arbeitenden Teammitglieder nicht die Kompetenz erhalten, bei unerwartet auftretenden Ereignissen selbstständig korrigierend eingreifen zu können, wird es schwerlich gelingen, das Spannungsfeld von hinreichender Ergebnisqualität, Termintreue und Ressourceneinsatz in den Griff zu bekommen. Effizient und effektiv ist eine Projektabwicklung, wenn die gewünschte Ergebnisqualität bei jeder einzelnen (Teil-)Aufgabe bis zum geplanten Endtermin mit den bereitgestellten Ressourcen realisiert wird. Ein erwartetes Ergebnis zu spät zu erreichen oder das gesteckte Ziel durch einen zu hohen Ressourcenverbrauch zu verfehlen ist dabei genauso als Manko zu beanstanden wie ein Projekt, das zwar „in time“ und bei Einhaltung des Budgets zu Ende gebracht wird, im Endergebnis aber eine Qualität liefert, die den Erwartungen nicht genügt. Da Termine und Budgets leicht zu kontrollieren sind und ein Überschreiten sofort auffällt, geht so mancher Projektmitarbeiter in seiner Not dazu über, ein wenig zu mogeln. Leicht reduzierte Qualität im Ergebnis ist meist nur von Experten zu erkennen und wird oft erst in späteren Projektphasen sichtbar. Überzählige Arbeitszeiten lassen sich auf anderen Zeitkonten „verstecken“. Und bei der Erledigung von Teilaufgaben ist es üblich, termingerecht Vollzug zu melden, auch wenn man noch nicht wirklich fertig ist. All dies müsste - wie oben erwähnt - nicht sein, wenn die Projekt-Mitarbeiter mehr Kompetenzen im Hinblick auf eigenverantwortliches Handeln eingeräumt bekämen. Der Verantwortliche einer Teilaufgabe müsste also über die gleichen Möglichkeiten zur Steuerung der wesentlichen Parameter Qualität, Zeit und Budget verfügen wie derjenige, der das Gesamtprojekt verantwortet. Komplexität in Projekten nimmt zu. Störungen, häufige Änderungen der Anforderungen, Budgetkürzungen, während das Projekt schon läuft, sind eher Regel als Ausnahme. Ein jedes solcher Projekte besteht aus Teilprojekten, Modulen usw. Diese sind häufig noch auf verschiedene Organisationseinheiten bzw. unterschiedliche Unternehmen verteilt. Mit ausschließlich zentraler Planung, Steuerung und Kontrolle lassen sich komplexe Entwicklungsprojekte kaum noch erfolgreich gestalten. Projektmitarbeitern sollte man die Kompetenz übertragen, ihre Teilleistungen selbständig zu planen und deren Leistungs-, Qualitäts-, Termin- und Budgeteinhaltung zu steuern. Hat man die Steuerung dieser entscheidenden Parameter nicht in der Hand, ist es fast unmöglich, Verantwortung für die Einhaltung der Vorgaben zu übernehmen. Genau dies aber passiert in hiesigen Unternehmen. Wenn man Entwicklungsprojekte unter die Lupe nimmt - so wie wir es in unseren Beratungsprojekten tun -, dann stellt man immer wieder fest, dass Teilprojektleiter selten eigenverantwortlich handeln können. Dass Kompetenzen und Verantwortung übereinstimmen sollten, wird seit Jahren gefordert. In der betrieblichen Praxis wird dieses Organisationsprinzip aber nach wie vor viel zu selten gelebt. Versäumnis- und Fehlermanagement - Es ist weniger von Bedeutung, woraus ein festgestellter Mangel resultiert, interessant ist vielmehr, ob es notwendig und wirtschaftlich ist, ihn zu beheben In frühen Entwicklungsphasen wird unzureichende Qualität nicht hinreichend verfolgt. Man bemängelt die Qualität eines fertigen Produktes, selten aber die Unzulänglichkeit einer Spezifikation. Getestet wird immer erst am Ende, wenn es häufig schon zu spät ist. Wären Beteiligte in der Lage, mit einer entsprechenden Tool-Unterstützung Mängel frühzeitiger zu erkennen und Planungen flexibel und ohne größeren Aufwand anzupassen, würden sie dies ohne Zweifel tun. Management und Controlling gehen oftmals praktisch bis zum Schluss davon aus, dass ein Projekt „im grünen Bereich“ ist. Und plötzlich passt nichts mehr zusammen, müssen ungeplante Zusatzressourcen in einem Ausmaß investiert werden, das die ursprünglichen Rentabilitätsberechnungen zur Makulatur werden lässt. Im Rahmen von Projekt-Audits konnten wir feststellen, dass z. T. fast 50 Prozent der gesamten Projektkosten erst nach dem für eine Serien- oder Betriebsfreigabe relevanten Test entstanden. Für diese Phase der Mängelbeseitigung jedoch gibt es weder Planungen noch Kostentransparenz. Eine der teuersten Phasen des Gesamtprojektes wird also fast steuerungslos „erlitten“. aktuell projekt M A N A G E M E NT 1/ 20 0 4 projekt M A N A G E M E NT 1/ 20 0 4 aktuell 22 WISSEN 23 IT-Einsatz - Funktionsumfang und Benutzerfreundlichkeit gängiger Projektmanagement- Tools reichen meist nicht aus Damit Teilprojektleiter ihre Aufgaben bei weitgehender Selbstverantwortung mit der gebotenen Effektivität und Effizienz abarbeiten können, müssen sie auf die gleiche technische Unterstützung zurückgreifen können wie der Gesamtprojektleiter. Ein Projektmanagement- Tool müsste daher auf allen Detaillierungsebenen in einer Art „Selbstähnlichkeit“ die gleichen Anforderungen befriedigen. Zurzeit werden vorrangig Workflow-basierte Planungs-Tools angeboten, die diese Anforderungen sowie die unerlässliche Änderungsflexibilität leider nicht abdecken. Außerdem sind sie schon deshalb nicht geeignet, weil der Erkenntnis-Flow in einem Entwicklungsprojekt nicht im Vorhinein festgelegt werden kann und das Abarbeiten eines immer gleichen Workflows daher nicht zielführend ist. Da wir für unsere eigene Projektarbeit gerne auf ein Tool zurückgreifen wollten, das unsere Anforderungen im Hinblick auf bestmögliche Unterstützung befriedigt, blieb uns nur eine Alternative - wir mussten uns ein solches Tool selbst „backen“. Unser Wunsch war, über ein Instrument zu verfügen, das dabei unterstützt, frühzeitig kritische Projektzustände zu erkennen, um dann geeignete Anpassungsmaßnahmen aufsetzen zu können (Abb. 2). Ein wichtiger Punkt in unseren Überlegungen war, dass wir eine Holschuld des jeweiligen Projektbeteiligten auf der Grundlage einer internen Kunden-Lieferanten-Beziehung voraussetzen. Die Anforderungen oder Spezifikationen werden bei unserem Ansatz also nicht von einer zentralen Stelle vorgegeben. Vielmehr definiert jeder für sich in den für ihn relevanten Kunden-Lieferanten-Beziehungen, was er benötigt, um seine Aufgabe erfolgreich bewältigen zu können. Wir unterstellen also - wie bei dem Polizei-Beispiel - einen „Pull“-Ansatz. Im Verlauf eines Projektes entsteht auf diese Weise ein sich dynamisch - und unabhängig von festen Hierarchien - entwickelndes Netzwerk, in dem die einzelnen Informationsbeziehungen von den jeweils Beteiligten selbst definiert werden (Abb. 3). Im Grunde haben wir es hier im übertragenen Sinn mit einem dynamischen Kanban-System zu tun, in dem man nur abfordert, was man braucht. Bislang dominiert hierzulande leider noch immer die „100 %-Kultur“. In Checklisten werden Maximalumfänge aufgeführt. Anforderungen, die so umfassend sind, dass sich der Betreffende für alle Eventualitäten bereits im Vorfeld wappnet. Erst wenn alle Checklisten-Punkte erfüllt sind, meint der Entwickler, die Erwartungen, die an seine Arbeit gestellt werden, auch befriedigen zu können. Bei unserem Ansatz verlangen wir demgegenüber von diesem Entwickler zunächst, Mindestanforderungen zu definieren, die erfüllt sein müssen, damit er anfangen kann. Alle weiteren Anforderungen und Beziehungen werden anschließend über das sich dynamisch entwickelnde Netzwerk im Verlauf des Projektes festgelegt - dann aber auf Basis eines wesentlich besseren Erkenntnisstandes als vor Beginn. Ingenieure im Allgemeinen und Produktentwickler im Besonderen neigen dazu, Ergebnisse ihrer Arbeit erst dann an den Nächsten in der Kette weiterzugeben, wenn alles perfekt ist. Da bekanntermaßen die letzten 20 Prozent der Zielerreichung 80 Prozent der Zeit verschlingen, kann man sich leicht ausmalen, welche Zeiteinsparungen in Projekten möglich wären, wenn dem Nächsten in der Kette bereits die 80-Prozent-Lösung zur Verfügung gestellt würde, damit dieser schon einmal anfangen kann. Fehlerbehandlung - Mängel sind etwas ganz Normales. Welche zu beseitigen sind, ist eine Frage der Prioritätensetzung Mängel sind etwas ganz Normales und sie treten häufig so unerwartet zu Tage wie Waldbrände. Entscheidend ist nun, dass Mängel nicht verleugnet, sondern als unvermeidbare Gegebenheit akzeptiert werden. Dem einzelnen Mitarbeiter wird es in einer Unternehmenskultur, � Im Verlauf eines Projektes entsteht auf diese Weise ein sich dynamisch - und unabhängig von festen Hierarchien - entwickelndes Netzwerk, in dem die Informationsbeziehungen von den Beteiligten selbst definiert werden. Abb. 3: Fehlerindikatoren an der Basis sind verzugslos und direkt an den zu melden, der sie richtig bewerten und entsprechende Maßnahmen einleiten kann. ������� ���������� �� �� � ������������������������������� � ��������� ��� ��������������������� � ������������������������������������ � ���������������������� � ���������������������� � ��������� ��� ������� ������������� ��� ������������ ������ ���������� ������������� ���������� ���� ������ Unser Wunsch war, über ein Instrument zu verfügen, das dabei unterstützt, frühzeitig kritische Projektzustände zu erkennen, um dann geeignete Anpassungsmaßnahmen aufsetzen zu können. Abb. 2: Prinzip des Projekt-Ereignis-Managements aktuell projekt M A N A G E M E NT 1/ 20 0 4 projekt M A N A G E M E NT 1/ 20 0 4 aktuell 24 WISSEN 25 die das Zu-Tage-Treten von Mängeln akzeptiert, wesentlich weniger Probleme bereiten, Fehler zuzugeben und öffentlich zu machen. Genau dies aber wäre Grundvoraussetzung, um noch rechtzeitig geeignete Maßnahmen zur Mängelbeseitigung in Angriff nehmen zu können. Die meisten Unternehmen haben diese Art der Mängel- Behandlung noch nicht kultiviert. Folglich versucht jeder Einzelne, nicht unangenehm aufzufallen. Zusatzaufwand oder -kosten werden auf andere Projekte transferiert oder im großen Gemeinkostentopf „versenkt“. Unternehmen sollten grundsätzlich davon ausgehen, dass es keine mängelfreien Produkte gibt. Mängel können darin bestehen, dass Entwickler formulierte Anforderungen nicht berücksichtigt haben. Ein Mangel liegt auch vor, wenn marktseitig bestehende Anforderungen nicht formuliert wurden. Andere Mängel bestehen in unerwünschten Stör- oder Nebenwirkungen, wie etwa Blendung oder Klappern einer Armaturentafel. So unterschiedlich Mängeltypen sind, allen gemein ist, dass die Einschätzung des Mangels auf unterschiedliche Erwartungshaltungen zwischen Kunde/ Auftraggeber und Lieferant zurückzuführen ist. Wesentliche Aufgabe eines Entwicklungsprojektleiters ist es, bei gegebenem Zeit- und Kostenbudget Prioritäten zu setzen, welche noch bestehenden Mängel beseitigt werden müssen und mit welchen man unter der Bedingung vielleicht doch leben kann, dass die Beseitigung die gegebenen Budgets sprengen würde. Durch Prioritätensetzung unter Beachtung von Markt- und Kostenwirkung eines Mangels ließen sich deutliche Verbesserungen erzielen. Tauchen im Verlauf eines Projektes neue Mängel auf, muss der Projektleiter die Fähigkeit besitzen, diesen Mangel zu bewerten, und - sofern er zu der Einschätzung kommt, dass dieser Mangel gravierend ist - die Kompetenz besitzen, diesen auch zu beseitigen, wozu aber in aller Regel Anpassungen im Projektplan vorzunehmen sind. Tool-Eigenschaften Bei einem Tool ist aus den genannten Gründen sehr großer Wert auf einfaches Handling zu legen. Mit wenigen Maus-Klicks muss sich zum Beispiel die gesamte Projektstruktur einschließlich der zu den einzelnen Teilprojekten gehörenden Dokumente, Budgets, Personalkapazitäten etc. umbauen lassen. Tools müssen bei der Komplexität der Entwicklungsprojekte in der Lage sein, Erkenntniszuwächse im Verlaufe eines Projektes flexibel und einfach zu erfassen und in geänderte Plandaten zu überführen. Wo dieses nicht gewährleistet ist, wird die Kluft zwischen Planung und Projektrealität im Verlauf der Zeit immer größer und das Unternehmen bewegt sich auf zunehmend dünnerem Eis. Ein weiterer wichtiger Ansatz zur Bewältigung hoher Komplexität liegt in der Personalisierung. Jedem Projektmitarbeiter sollten gemäß dem „NOI (Notice of Interest)“-Prinzip nur die Informationen zur Verfügung gestellt werden, die er für seine Arbeit benötigt. Jeder muss davon ausgehen können, dass er möglichst nur relevante Informationen erhält. Von einem Pilot-Kunden haben wir die Rückmeldung erhalten, dass auch ein integriertes Dokumentenmanagement sehr hilfreich ist - insbesondere, wenn dieses Feature mit dem Alarmierungssystem verknüpft ist. Zumeist wird das Dokumentenmanagement außerhalb des Projektmanagementsystems zur Verfügung gestellt. Hilfreich ist, wenn ein Projektmitarbeiter automatisch von einem für ihn relevanten Erkenntniszuwachs informiert wird, sobald dieser ins Dokumentenmanagementsystem eingestellt ist. Weitere wichtige Anforderungen sind:  Überwachung kritischer Zustände („Projektschräglagen“) mit automatischer Alarmierung,  integrierte Fehlerverfolgung und Prioritätenmanagement,  Änderungsflexibilität der Planungs- und Problemlösungsstrukturen,  zeitlich und inhaltlich differenzierte Strukturierung von Vorgängen. Resümee Aus unserer langjährigen Erfahrung können wir den Verantwortlichen daher nur den Rat geben: Auch wenn ein Produktentwicklungsprojekt noch so gut durchgeplant erscheint und allem Anschein nach in der Planung nichts Wesentliches vergessen wurde - seien Sie sich darüber im Klaren, dass diese Planung zu einem Zeitpunkt erstellt wurde, als die Unwägbarkeiten, die in komplexen Entwicklungsprojekten mit an Sicherheit grenzender Wahrscheinlichkeit auftauchen werden, noch nicht absehbar waren. Wer Effizienz und Effektivität seiner Entwicklungsprojekte verbessern will, darf sich nicht an starre Planungen halten, sondern muss Sorge dafür tragen, dass Erkenntniszuwachs aller Art flexibel, einfach und zeitnah in die Planung einfließt. Nur wenn dies gewährleistet ist, macht Arbeiten nach Plan Sinn. Die Verfügbarkeit von Tools, die diese Flexibilität ermöglichen, ist dabei nur eine - wenn auch wichtige - Voraussetzung. Ohne parallel dazu einen kulturellen Wandel einzuleiten, der den Teilprojektleitern mehr Kompetenzen und Verantwortung zubilligt, werden die Verbesserungspotenziale nicht so ausgeschöpft, wie es ansonsten möglich wäre. Unseren Beratungen liegt die Philosophie zu Grunde, die Stärken von Mensch und IT gezielt zu nutzen und miteinander zu verbinden. Anspruchsvolle, komplexe Projekte lassen sich nicht vollständig standardisieren oder ex ante durchplanen. Verlangt wird vielmehr ein hohes Maß an Flexibilität und einfacher Steuerbarkeit auf der Grundlage ausgeprägter Improvisationsfähigkeiten der Projekt-Mitarbeiter. Die Beherrschung der Komplexität, das frühzeitige Erkennen von Anpassungserfordernissen aufgrund neuer Erkenntnisse oder Ergebnisse und deren zeitgerechte Umsetzung sowie das Sicherstellen von Transparenz zu jedem Zeitpunkt sind Voraussetzungen, um Entwicklungsprojekte zum Erfolg zu führen.  Literatur [1] Wirtschaftswoche Nr. 40, 25. 9. 2003 Schlagwörter Fehlerbehandlung, Frühwarnsysteme, Kommunikation im Projekt, Produktentwicklung, Projektcontrolling, Projekt- Ereignis-Management, Projektmanagementtool aktuell projekt M A N A G E M E NT 1/ 20 0 4 projekt M A N A G E M E NT 1/ 20 0 4 aktuell 24 WISSEN 25 Autor Reinhard Meinders, Dipl.-Informatiker (FH), Organisations- und IT-Berater für das Management. Seit 1978 tätig - bis 1986 im Bereich Softwareentwicklung für Logistik-Anwendungen verantwortlich. Ab 1981 Projektleitung für komplexe Entwicklungsprojekte. Von 1986 bis 1991: Organisationsoptimierung für Logistik-Prozesse, später Chefberater Logistik der Diebold-Gruppe, maßgebliche Beteiligung bei der Entwicklung der Prozessanalysemethodik. Von 1991 bis 1993: Einsatz bei Projekten zur Wertanalysetechnik und der Kienbaum Unternehmensberatung Düsseldorf. 1993 bis 1999: Geschäftsbereichsleitung bei Gora, Hecken & Partner, Management und Technologieberatung GmbH, für die Beratung von Sicherheitsbehörden. 2000: Gründer und Unternehmensberater bei Business Network Solutions mit Schwerpunkt Projektmanagement, Prozess- und IT-Beratung, Hofheim am Taunus. Anschrift Rosenstr. 25 D-65719 Hofheim E-Mail: rmeinders@bns-consult.de Autor Dr.-Ing. Thomas Gutberlet, Strategie- und Organisationsberater. Nach Maschinenbaustudium zunächst wissenschaftliche Tätigkeit zum Thema „Optimierung von Produktentwicklungsprozessen durch IT-Einsatz“. Seit 1990 im Beratungsgeschäft: Zwischen 1990 und 1993 Organisationsberater für die Fertigungsindustrie bei Price Waterhouse. 1993 Einstieg bei Diebold Deutschland, einem Pionierunternehmen der Geschäftsprozessoptimierung. Verschiedene Strategie- und Organisationsprojekte im Maschinen- und Anlagenbau sowie der Fahrzeugzuliefererindustrie. Seit 1995 Managementverantwortung für die mittelständische Fertigungsindustrie (Maschinen-/ Anlagenbau und Fahrzeugzuliefererindustrie). Ab 2001 Mitarbeit und seit Anfang 2002 auch Gesellschafter bei Business Network Solutions mit Schwerpunkt Prozess- und Projektmanagement. Anschrift Mainau 1 D-65719 Hofheim E-Mail: tgutberlet@bns-consult.de Den Umgang mit anderen Kulturen „am eigenen Leib“ erfahren: Nur so lässt sich nach Meinung der Projektgruppe Atlanticon vom Institut für Kooperationsmanagement der Universität Regensburg interkulturelles Verhalten wirklich lernen. Doch die allerwenigsten Projektmanager haben die Zeit, bei Auslandseinsätzen sich vor Ort durch „learning by doing“ Geschäftssitten, Arbeitsmentalität und die Regeln des täglichen Miteinanders anzueignen. Ihnen erleichtert das süddeutsche Atlanticon-Team mit einem Verhaltensplanspiel die Vorbereitung. „Aus unserer Sicht genügt es nicht, wenn interkulturelle Trainingseinheiten nur kognitiv erarbeitet werden“, betont Prof. Siegfried Stumpf, der Leiter der Projektgruppe. Das Verhaltensplanspiel, das er mit fünf jungen Kollegen entwickelt hat, sensibilisiere für fremde Kulturen und vermittle die dringend benötigte Kompetenz durch erfahrungsbasiertes Lernen. In der Praxis sieht dies so aus: Atlanticon simuliert ein internationales Unternehmen. Es umfasst verschiedene Rollen von der Geschäftsleitung über Vertrieb und internes Management bis zur Personalentwicklung. Szenariobeschreibungen helfen den Seminarteilnehmern, in diese Rollen zu schlüpfen. Gemeinsam verhandeln sie, planen und diskutieren; auch kommen weitere „Instanzen“ wie Kunden und ein Vorstandsvorsitzender ins Spiel. Voraussetzung dabei: Die Teilnehmer sind international gemischt und entstammen tatsächlich unterschiedlichen Kulturen. „In den Spielphasen entsteht nach einer gewissen Zeit ein dynamischer und realitätsnaher Handlungsfluss“, berichtet Stumpf. Reflexionsphasen unterbrechen diesen Fluss, damit die Teilnehmer das Spielgeschehen analysieren können. Diese Reflexionen zeigen, wie wichtig der richtige Umgang mit fremden Kulturen ist. Zugleich vermitteln sie praktische Kompetenz und helfen Ängste, Hemmungen und Unsicherheiten gegenüber dem „Fremden“ abzubauen. Ursprünglich hatte das Regensburger Team das Spiel für die psychologische Forschung entwickelt. Verbessert kann es nun für interkulturelles Training eingesetzt werden. Dafür wurde das Spiel mehrfach wissenschaftlich unter die Lupe genommen, bis hin zu detaillierten Videoanalysen der Gruppenarbeitsprozesse im Planspiel. Befragungen der Teilnehmer zeigten, dass knapp 47 Prozent nach dem Seminar ihr interkulturelles Verhalten „eher besser“, weitere 30 Prozent völlig neu einordnen konnten. Zudem beobachtete das Team, dass das Planspiel bei seinen Teilnehmern insgesamt eine hohe Akzeptanz genießt. Auch gewöhnen sich ausländische Teilnehmer schneller in die deutsche Kultur ein. Im Vergleich zum herkömmlichen Rollenspiel, mit dem interkulturelle Kompetenz trainiert wird, zeichnet sich ein Verhaltensplanspiel nach Meinung der Augsburger Psychologen durch komplexere Situationsbeschreibungen, vielfältigere Anforderungen an die Teilnehmer sowie dynamischere Situationen aus. Ähnliche Vorteile habe das Verhaltensplanspiel gegenüber computersimulierten Planspielen. Die Teilnehmer greifen nicht von außen in das Spiel ein, sondern sind Teil des Spiels. „Die gesamte Aktivität der Teilnehmenden wirkt auf das Szenario-Geschehen“, betont Stumpf. Weitere Informationen: Universität Regensburg, Alexander Wenzl, Tel.: 01 71/ 5 82 87 39, www.atlanticon.de. Mit Atlanticon zur interkulturellen Kompetenz aktuell projekt M A N A G E M E NT 1/ 20 0 4 projekt M A N A G E M E NT 1/ 20 0 4 aktuell