Die Umfeldbedingungen des Skalierens

"Funktioniert Scrum auch mit großen Projekten?", fragen mich die Teilnehmerinnen und Teilnehmer in Seminaren, unsere Kunden und so gut wie jeder Manager, den ich treffe. Sie alle wollen ihre großen, aus dem Ruder gelaufenen Projekte retten. Immer wieder muss ich dabei an den Chaos Report der Standish Group denken [1]: Mehr als 50 Prozent aller großen Projekte liefern nicht die geforderten Ergebnisse. Die Diagnose ist eindeutig: Je größer ein Projekt ist, desto wahrscheinlicher wird es – gemessen an den ursprünglichen Vorgaben – scheitern. Übrig bleibt das Fazit: Obwohl alle Beteiligten bestens im Projektmanagement ausgebildet sind, obwohl versucht wird, am Beginn eines Projekts an möglichst viel zu denken, steckt das traditionelle Management großer Projekte in einer Sackgasse. Doch es gibt einen Ausweg: Wie gelingen große Projekte in der Soft- und Hardwareentwicklung? Als großes Projekt bezeichne ich eines, das folgende Bedingungen erfüllt: Ein Budget von mehr als einer Million Euro, eine Dauer von mehr als sechs Monaten und mehr als sechs durchführende Beteiligte, die auch an verschiedenen Orten angesiedelt sein können. Wie solche Projekte gemanagt werden können, ist eine brennende Frage, denn es ist noch immer die größte Herausforderung für die meisten Unternehmen. Großkonzerne und der deutsche Mittelstand führen Projekte in gigantischen Ausmaßen durch – zehn Millionen Euro sind schnell ausgegeben und Dutzende Personen leisten ihren Beitrag. Aber da gibt es noch einige Besonderheiten: Diese Projekte werden im Rahmen des normalen Tagesgeschäfts durchgeführt, sie stören den normalen Ablauf. Arbeiten mehrere Standorte am Projekt mit, ist die Projektsprache Englisch. Und als wäre das allein nicht schwierig genug, sind diese Unternehmen noch dazu in einem gigantischen Beschleunigungsrennen gefangen. "Digitalisierung" lautet das Stichwort, täglich entstehen neue Technologien. Neue Optionen, neue Geschäftsfelder entwickeln sich über Nacht. Unternehmen, die auf dem internationalen Parkett weiter bestehen wollen, müssen damit umgehen können. Fehlentscheidungen und Selbstzufriedenheit führen schnell zum Desaster. Mit der Flut an Möglichkeiten, die neue Technologien mit sich bringen, rast eine Welle von Gesetzesänderungen auf die Unternehmen zu. Kontinuierlich müssen sie ihre Prozesse und damit ihre IT-Infrastruktur anpassen, und natürlich müssen auch Projekte neu bewertet und ihr Kurs unter Umständen korrigiert werden. Vieles bleibt lange im Ungewissen, denn manchmal wissen nicht einmal die Behörden selbst, wie eine neue Vorschrift aussehen soll.
Man weiß, dass sie kommen wird, aber nicht, wann genau und in welcher Form. Werden die entwickelten Lösungen die richtigen sein? In diesem Spiel kann nur mitmischen, wer seine Methoden den Umständen anpasst. Traditionelles Projektmanagement muss zwangsläufig scheitern, denn dessen Spielwiese wurde für einen anderen Kontext und andere Zeithorizonte entwickelt. Es leistete gute Dienste, viele Unternehmen haben gute Erfahrungen damit gemacht. Aber immer wieder ist zu beobachten, dass extrem kritische Projekte außerhalb der traditionellen Unternehmensstrukturen durchgeführt werden. Die Labs und Taskforces sind anderen Bedingungen unterworfen: Dort dürfen die Kollegen alles anders machen und werden nur daran gemessen, ob sie eine Lösung finden. Klassische Unternehmensprozesse werden ignoriert oder so geschickt ausgenutzt, dass sonst Undenkbares plötzlich möglich wird.
Die Softwareentwicklung war der erste Bereich, in dem in den 1990er-Jahren sichtbar wurde: Der traditionelle Weg der Projektdurchführung funktioniert nicht mehr. Also machten sich einige Manager auf den Weg, suchten eine Lösung für die beschriebenen Probleme und fanden die agile Softwareentwicklung. Von den unterschiedlichen Modellen setzte sich weltweit eine Vorgehensweise durch: Scrum. Dieses Managementframework wurde entwickelt, um in einem komplexen Umfeld möglichst schnell etwas liefern zu können, von dem man oft nicht weiß, wie es aussehen soll und erreicht werden kann. Zunächst ging man davon aus, dass man gut ausgebildete Softwarespezialisten zusammenbringen müsse, um aus ihnen ein Team mit einer klar definierten Aufgabe zu formen. Das funktionierte sehr gut. Heute arbeiten viele Unternehmen in ihren IT-Abteilungen erfolgreich mit diesen kleinen, sich selbst organisierenden Teams. Scrum-Projekte wurden bald so erfolgreich, dass immer mehr Hardwareentwicklungsteams auf diese Arbeitsweise aufmerksam wurden. Die Softwareentwickler lieferten ihre Produkte immer schneller ab, nutzten andere Formen des Reportings und wirkten alles in allem zufriedener mit ihrer Arbeit. So hielt Scrum auch Einzug in das traditionelle Projektmanagement für Hardwareprodukte. Und die Verbreitung von Scrum ist noch nicht abgeschlossen: Inzwischen gibt es selbst verwaltungsnahe agile Teams, zum Beispiel in der Rechtsabteilung der Holtzbrinck Publishing Group [2].