Warum IT-Projekte aus dem Ruder laufen

Bekannte Unsicherheiten lassen sich managen

Was kann man also tun? Der erste und wichtigste Schritt ist sich über die Projektunsicherheiten bewusst zu werden und auch die Zusammenhänge zwischen den Eckpunkten zu verstehen.

Hier ein sehr einfaches Beispiel aus der Praxis: In der Regel sind Webkampagnen von der Fachlichkeit recht überschaubar. Ein Gewinnspiel, oder eine Mitmachplattform für Fotos und oder Videos, Promiblog usw. Also nichts was sich von der technischen Seite nicht gut planen lässt.

Die Deadline ist meist durch äußere Ereignisse vorgegeben. Sei es ein Großereignis oder andere begleitende Werbekampagnen.

Der unbekannte Faktor ist die Menge. Kein Mensch weiß vorher, wie erfolgreich die Kampagne sein wird und wie viele User auf die zugrunde liegende Applikation zugreifen werden.
Also muss man sich über diesen Unsicherheitsfaktor im klaren sein, dies mit einplanen und sich die Frage stellen, wo diese Unsicherheit relevant wird.

Natürlich schlussendlich beim Budget. "All-You-Can-Eat Angebote" gibt es in diesem Umfeld nicht, oder sie wären nicht bezahlbar.

Wenn die Anzahl der Nutzer unbekannt ist, muss in der Planung ein Skalierungskonzept her, um auf positive Überraschungen nach oben vorbereitet zu sein. Das bedeutet allerdings, dass das Budget nicht von Anfang an feststehen kann, sondern vom Erfolg der Kampagne abhängt.
Das hört sich ja erst einmal sehr einfach, sinnvoll und nachvollziehbar an, wenn die Kosten vom Erfolg abhängen.

Das Ziel: Agile Projektmanagement-Methoden statt jubelnder Controller

Wenig Erfolg, wenig Kosten. Viel Erfolg, höhere Kosten. Man könnte meinen, die Controllingabteilung jubelt. Aber meistens weit gefehlt. Dies entspricht nicht den Prozessen von großen Unternehmen. Da muss ein festes Budget für ein Projekt gemacht werden.

Man könnte ja meinen, dann macht man eben ein etwas größeres Budget für den Erfolgsfall und freut sich, dass man Geld spart, wenn es nicht maximal gut läuft. Geht leider auch nicht. Wird das Budget nicht voll ausgeschöpft, steht im nächsten Jahr die Kürzung an. Und für die nächste Kampagne mit maximalem Erfolg ist dann nicht genug Geld da. Also werden häufig wegen unflexiblen Budgets Kompromisse in der Mitte gemacht, die häufig zu Geldverschwendung und manchmal zum Scheitern eines Projektes führen.

Flexibilisierung der Projektplanung und Budgetierung verhindert Misserfolge

An dieser Stelle ist auch bei kleineren Projekten ein Umdenken erforderlich. Unternehmen müssen hier ihre Budgetplanung flexibilisieren, um erfolgreiche Projekte umzusetzen.

Bei großen und komplexen Projekten muss man moderne agile Projektmanagementmethoden einsetzten, um die oben beschriebenen Probleme in den Griff zu bekommen. Bekannte Beispiele sind Scrum und Kanban. Beide sind in der IT aus der Softwareentwicklung heraus entstanden.
Bei der Softwareentwicklung ist es schon seit einigen Jahren von allen großen Playern im Markt erkannt und akzeptiert, dass man große Softwareprojekte nur mit agilen Managementmethoden zum Erfolg führen kann. In der gesamten Unternehmens-IT setzt sich diese Erkenntnis nur sehr langsam durch. Vor allem, weil dadurch etablierte Managementmethoden, z.B. der Umgang mit Budgets, massiv in Frage gestellt werden.

Iterativem Vorgehen wie im Kanban gehört die Zukunft des Projektmanagements

Allen agilen Methoden ist gemeinsam, dass sie iterativ sind. Das bedeutet: Man plant nur einen überschaubaren Zeitraum im Detail, setzt um, macht Erfahrungen, bewertet sie und bringt diese in die Planung des nächsten Zeitabschnitts ein.
Unsere Entwickler gehen bereits seit geraumer Zeit so vor.

Nur so entgeht man willkürlichen Schätzungen. Ganz platt gesagt: Klein Anfangen, laufend Erfahrungen sammeln und Schritt für Schritt weiterentwickeln und verbessern. Und das nicht nur in der Softwareentwicklung, sondern auch in der Infrastruktur, im Betrieb, im Compliance- und Securitymanagement usw.

Bei den meisten komplexen Projekten, mit denen wir zu tun haben, handelt es sich um Projekte, bei denen die fachlichen Anforderungen noch nicht feststehen und sich auch erst aus dem Projekt und den ersten Erfahrungen im Betrieb ergeben.

Hier hilft es auf jeden Fall, wenn man die fachlichen Anforderungen im Detail offen lässt und mit dem einfachsten möglichen Szenario in den Betrieb geht, um so schnell wie möglich echte Erfahrungen zu sammeln und die Architektur nicht auf Annahmen und Schätzungen aufzubauen, sondern auf Fakten.

Das kann dazu führen, dass Mehrkosten in geringem Maße entstehen oder gar noch die Basisarchitektur umgebaut werden muss. Im Gegenzug vermeidet man allerdings die Risiken, eine falsche Architektur aufzubauen oder eine weit überdimensionierte.

Beides würde immense Kosten verursachen. Auch ohne eine konsequente Umsetzung von Scrum oder Kanban lässt sich so mit Best-Practice-Ansätzen vieles an Projektrisiken minimieren.