Die Floprate bei Innovationen könnte niedriger sein

Von 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.

Deutsche 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.

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.

---

Zu diesem Artikel schrieb Dr. Thomas Schlereth, Vorstandsvorsitzender der cando AG, München:

Wie Hersteller von Projektmanagementsoftware auf dieses Problem reagieren können!

Die primäre Aussage des Beitrages von Meinders/Gutberlet kann zusammengefasst werden mit dem kurzen Satz:„Die gesamte Projektplanung entspricht weder der aktuellen noch der zu erwartenden Realität.“ Sie ist ein Wunschdenken, das von einem optimalen Ablauf der Zukunft ausgeht. Fehler oder Probleme können nur entstehen, wenn diverse Aktivitäten vergessen oder nicht ausreichend mit Kapazitäten versehen wurden. Durch diese tausenden von Arbeitsschritten, Unmengen von Berichten, Texten und endlosen Gesprächen soll nur eines vermittelt werden: Sicherheit (manchmal ist es auch nur Zuversicht). Hier wird eindeutig „Masse statt Klasse “ produziert, das Prinzip „Viel hilft viel “ angewandt und durch möglichst vollständige Berichte an Entscheider der eigene Sicherheitsgurt angelegt.

Das Management wird nicht mit der Möglichkeit „das wissen wir jetzt noch nicht “ oder „das lässt sich zum heutigen Zeitpunkt nicht oder nur sehr vage vorhersehen “ konfrontiert. So treffen während der wichtigsten Zeit eines Projektes, der Planungsphase, zwei Faktoren aufeinander. Zum einen der Planer, der durch eine möglichst detaillierte und umfassende Planung das Gefühl oder den Eindruck der absoluten Risikominimierung erweckt, und zum anderen der Manager, der genau das erwartet und fordert. Meinders und Gutberlet verweisen auf fehlende Flexibilität der Planungstools. Dies führt, kombiniert mit geringem Sachverstand bei Projektdesign und Projektstrukturierung, dazu, dass meistens keine Werkzeuge eingesetzt werden. Konfrontiert mit diesem Umstand hat cando vor vier Jahren begonnen, ein Verfahren zu entwickeln, das mit der Ungenauigkeit, die einer jeden Planung wie Pech anhaftet, umzugehen versteht. Dabei wird nicht von einer permanent gleich bleibenden Akkuratesse ausgegangen, vielmehr davon,d ass eine Aktivität in der Zukunft sowohl zeitlich wie finanziell unpräzise angegeben werden kann, eben weil sie es ist.

Das Programm informiert den Anwender über die Wahrscheinlichkeit, mit der die Planung eintritt. Eine solche Risiko-oder Wahrscheinlichkeitsberechnung ist näher an der Realität als scheinbar präzise Pläne. Auch das Problem der viel zu umfangreichen Planung wird etwas verringert. Bei dem im Beitrag geschilderten Maut-Projekt hätte cando sehr früh eine rote Lampe gezeigt. Das haben die in dem Projekt verwendeten Systeme sicher auch getan, nur sie wurden möglicherweise ignoriert oder zumindest falsch interpretiert.

... Weiterlesen in PDF-Ausgabe (Für registrierte GPM-Mitglieder)

---> Zum Inhaltsverzeichnis von PMaktuell - Heft 1/2004