Stolpersteine im Projektmanagement

Warum IT-Projekte aus dem Ruder laufen

04.06.2013
Größere komplexe Projekte - nicht nur in der IT Branche - haben die Tendenz sowohl terminlich, als auch vom Budget her aus dem Ruder zu laufen. Woran das liegt, und wie Unternehmen und IT-Dienstleister diese Schieflagen vermeiden können, erklärt Thomas Wittbecker, Geschäftsführer der Adacor Hosting GmbH.
Thomas Wittbecker, Geschäftsführender Gesellschafter der Adacor Hosting GmbH
Foto: Adacor

Größere komplexe Projekte - nicht nur in der IT Branche - haben die Tendenz sowohl terminlich, als auch vom Budget her aus dem Ruder zu laufen. Oft nimmt die Katastrophe schon bei der Ausschreibung ihren Lauf und setzt sich im Projektmanagement fort. Dabei könnten sich die größten Stolpersteine schon im Ansatz umgehen lassen.
von Thomas Wittbecker (Geschäftsführer der Adacor Hosting GmbH)
Je nachdem, welche aktuelle Studie man zugrunde legt sind bei größeren IT Projekten 70 bis 80 Prozent der Projekte "Out of Time” oder "Out of Budget”. Da drängt sich natürlich die Frage auf, ob da nur Laien am Werk sind, oder ob es andere Gründe für die Probleme gibt.

Die Beleuchtung der drei projektbestimmenden Eckpunkte Budget, Deadline und Fachlichkeit bringen dabei Licht ins Dunkel.

Aus der eigenen Erfahrung kann ich das nur für komplexe Hosting-Projekte beurteilen, allerdings dürften die Probleme eher grundsätzlicher Natur sein und in allen Branchen auftreten.

Schauen wir uns die Rahmenbedingungen von etwas größeren Projekten an: alle Projekte haben ein Budget, einen Zeitrahmen mit Deadlines und eine definierte Fachlichkeit, meist über ein Pflichten- oder Lastenheft beschrieben. Das sind die drei Eckpunkte, die ein Projekt festnageln.

Bei kleinen, einfach gelagerten Projekten funktioniert das auch hervorragend. Solange man sich ein wenig Mühe gibt, die Fachlichkeit genau definiert, das benötigte Budget zusammenrechnet und sich genau überlegt, wie lange man braucht.

Bei Projekten, die man immer wieder umsetzt, und bei denen man sich genau auskennt, funktioniert das: Auspuff reparieren, Wohnzimmer anstreichen, Standard Webserver aufsetzen und zur Verfügung stellen.

Die Grenzen des Schätzens in der Praxis

Problematischer wird es bei Projekten, die komplexer sind und bei denen die Projektverantwortlichen Neuland betreten. Hier fangen wir an Annahmen zu treffen und zu schätzen - und zwar viele Male.
Leider sind wir Menschen extrem schlecht im Schätzen.
Die Adacor betreibt im Kerngeschäft Individualprojekte. Software wird individuell entwickelt und dann von uns betrieben - und das teilweise mit Hunderten bis Millionen Nutzern, je nach Art des Projektes. Zu dem Zeitpunkt an dem der Betrieb der Infrastruktur ausgeschrieben wird, ist in der Regel die Software noch nicht einmal fertig entwickelt, man weiß nicht genau wie viele Leute zugreifen werden und wie diese die Software nutzen.
Aber es gibt schon eine klare Anforderung an die Infrastruktur und man möchte feste SLAs eine feste Architektur und eine definierte Verfügbarkeit zum Festpreis.

Wann läuft ein Projekt schief
Die Reißleine ziehen - wann und woran lässt sich erkennen, dass ein Projekt aus dem Ruder läuft?
Ist für das Projekt eine Zeitdauer von mehr als eineinhalb Jahren vorgesehen?
Dann ist es besser, das Projekt in kleinere Teilschritte zu gliedern und Geschäftsprozesse nacheinander umsetzen. Der Grund: Ein Unternehmen entwickelt sich in zwei Jahren weiter, Geschäftsprozesse verändern sich und die ursprünglich geplanten Projektumfänge sind nicht mehr dieselben. Selbst ein sauber aufgesetztes Change-Management greift immer in die laufende und noch nicht vollständige Implementierung ein.
Werden Meilensteintermine überschritten?
Spätestens wenn der erste Termin überschritten wird, muss die Projektleitung dem sofort Rechnung tragen und gemeinsam mit dem Lenkungsausschuss die geplanten Maßnahmen kritisch prüfen.
Gibt es viele Änderungen während des Projektes?
Tauchen während der Projektlaufzeit permanent Änderungen auf, war die Planung schlecht oder die Realität überholt die Einführung. In diesen Fällen sollten alle Beteiligten offen über die absehbaren Risiken sprechen und realistische Gegenmaßnahmen entwickeln, die den Projekterfolg sicherstellen. Oder gemeinsam entscheiden, Termin- und Budgetanpassungen vorzunehmen.
Stimmen die zwischenmenschlichen Beziehungen noch?
Kommt es zwischen Beratern, Projektleitung und Key Usern vermehrt zu Spannungen, funktioniert die Kommunikation nicht (mehr) richtig. Motivationsprobleme treten auf und es werden oft Schuldige gesucht statt Lösungen. In solchen Fällen sollte umgehend gehandelt werden - dies ist eine der Hauptursachen für scheiternde Projekte!
Ist die vereinbarte Dokumentation ...
... im Projekt aktuell und sind Änderungen sauber dokumentiert? Wenn nicht, ist dies ein sicherer Indikator dafür, dass das Projekt aus dem Ruder zu laufen droht.
Stimmt die Qualität ...
... der Implementierungspartner und wie lässt sich mangelndes Wissen der Consultants erkennen? Implementierungsziele, die gerissen werden und Teilschritte, die qualitativ nicht der Planung entsprechen, sind eindeutige Anzeichen der Schwäche. Prüft man Teilschritte in regelmäßigen Abnahmen per Testkatalog, sind Abweichungen leicht festzustellen.
Ein Implementierungspartner ...
... und Verantwortlicher ist immer einfacher zu steuern als mehrere. Vor allem dann, wenn diese in einer Wettbewerbssituation zueinander stehen.

Die Katastrophe beginnt bei der Ausschreibung: Ein Beispiel

Eine typische Situation aus der Praxis. Wir bekommen eine Ausschreibung auf den Tisch, ca. 100 Seiten, Infrastruktur für ein neues Projekt, Software wird noch entwickelt und alles genau spezifiziert. Für die Erstellung der Ausschreibung wurde sogar eine Consulting Firma beauftragt.

Bei solchen Projekten gibt es auch noch immer mehrere Parteien (mindestens Kunde, Software-Dienstleister und uns), die alle drei ihre Aufgaben erfüllen und Deadlines einhalten müssen.

Wenn jetzt alle drei Säulen - Fachkonzept, Budget und Deadline - fixiert werden und sich dann herausstellt, dass irgendwelche Annahmen und Schätzungen falsch waren, explodiert das Projekt.

Und mal ehrlich, wie wahrscheinlich ist es bei einem Projekt, in dem es um etwas Neues geht und man keinerlei Erfahrungswerte hat, dass man treffgenaue Schätzungen abgibt? Gleich Null!

Demgemäß ist auch die Wahrscheinlichkeit nicht sehr hoch, dass ein Projekt genauso läuft wie geplant und alle drei Eckpunkte eingehalten werden. Nur sind dann alle überrascht und entsetzt, dass die böse Realität sich einen Weg gebahnt hat.

Halten wir also fest

  1. Bei komplexen Projekten ist es unglaublich schwierig, die genauen fachlichen Anforderungen schon vor Beginn des Projektes zu definieren, da die Erfahrung fehlt. Deshalb werden Annahmen getroffen.

  2. Wir Menschen sind schlecht im Schätzen, vor allem wenn wir wenig Erfahrungswerte haben. Das wirkt sich besonders negativ auf die Frage der Dauer aus.

  3. Also können wir nicht davon ausgehen, dass wir ein Projekt exakt im Voraus planen können, ohne eine Menge Fehler zu begehen.

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.

Platz 1 bis 5
1. Business Process Outsourcing (6.266/2.945/+112,8 %)
2. Artikelentwurf (2.879/1.864/+54,5 %)
3. Technische Dokumente (4.406/3.490/+26,2 %)
4. 3D Modelling (1.776/1.463/+21,4 %)
5. E-Mail-Marketing (1.207/1.001/+20,6 %)
(Werte: Aufträge in Q1/13; Aufträge in Q4/12; Zuwachs)
Platz 46 bis 50
46. MySQL (14.410/14.017/+2,8 %)
47. Übersetzung (3.261/3.288/-0,6 %)
48. Facebook (6.284/6.569/-4,3 %)
49. YouTube (1.309/1.499/-12,7 %)
50. Data Mining (1.243/1.509/-17,6 %)
(Werte: Aufträge in Q1/13; Aufträge in Q4/12; Zuwachs)
Platz 41 bis 45
41. Vieo Services (1.911/1.816/+5,4 %)
42. iPhone (5.552/5.294/+4,9 %)
43. C Programmierung (3.179/3.049/+4,3 %)
44. Java (3.399/3,274/+3,8 %)
45. Marketing (8.773/8.490/+3,3 %)
(Werte: Aufträge in Q1/13; Aufträge in Q4/12; Zuwachs)
Platz 36 bis 40
36. Logo Design (7.598/7.134/+6,5 %)
37. 3D Animation (1.759/1.652/+6,5 %)
38. Datenbank-Administration (1.164/1.101/+5,7 %)
39. C++ Programmierung (2.331/2.210/+5,5 %)
40. Banner Design (2.132/2.022/+5,4 %)
(Werte: Aufträge in Q1/13; Aufträge in Q4/12; Zuwachs)
Platz 31 bis 35
31. Search Engine Optimization (10.922/10.147/+7,6 %)
32. Link Building (7.358/6.836/+7,6 %)
33. jQuery / Prototype (3.781/3.522/+7,4 %)
34. Word (4.887/4.559/+7,2 %)
35. Joomla (3.558/3.322/+7,1 %)
(Werte: Aufträge in Q1/13; Aufträge in Q4/12; Zuwachs)
Platz 26 bis 30
26. PHP (43.583/39.867/+9,3 %)
27. Website Design (30.276/27.860/+8,7 %)
28. Artikel (12.070/11.141/+8,3 %)
29. Reports (1.538/1.426/+7,9 %)
30. Werbung (5.600/5.193/+7,8 %)
(Werte: Aufträge in Q1/13; Aufträge in Q4/12; Zuwachs)
Platz 21 bis 25
21. Graphic Design (32.175/28.562/+12,6 %)
22. HTML (29.730/26.396/+12,6 %)
23. iPad (2.266/2.035/+11,4 %)
24. Leads (3.471/3.133/+10,8 %)
25. Telemarketing (1.120/1.018/+10,0 %)
(Werte: Aufträge in Q1/13; Aufträge in Q4/12; Zuwachs)
Platz 16 bis 20
16. Bulk Marketing (2.842/2.481/+14,6 %)
17. CSS (10.319/9.009/+14,5 %)
18. Magento (2.564/2.240/+14,5 %)
19. 3D Rendering (1.572/1.388/+13,3 %)
20. Web Search (6.963/6.173/+12,8 %)
(Werte: Aufträge in Q1/13; Aufträge in Q4/12; Zuwachs)
Platz 11 bis 15
11. E-Commerce (4.592/3.859/+19,0 %)
12. Twitter (2.630/2.232/+17,8 %)
13. Shopping Carts (3.458/2.942/+17,5 %)
14. PSD to HTML (2.367/2.021/+17,1 %)
15. Photoshop Design (1.246/1.085/+14,8 %)
(Werte: Aufträge in Q1/13; Aufträge in Q4/12; Zuwachs)
Platz 6 bis 10
6. Android (5.154/4.278/+20,5 %)
7. PowerPoint (1.502/1.247/+20,4 %)
8. Wordpress (10.601/8.820/+20,2 %)
9. HTML5 (4.592/2.823/+20,1 %)
10. Illustrator (2.400/1.999/+20,1 %)
(Werte: Aufträge in Q1/13; Aufträge in Q4/12; Zuwachs)

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.

So kann man das Problem natürlich auch lösen

Hier noch ein Beispiel, wie es auch geht: Wenn ich keine Planungssicherheit habe, nicht auf viele Erfahrungswerte zurückgreifen kann und auch noch keine agilen Managementmethoden implementiert habe, muss mindestens einer der drei Eckpunkte flexibel bleiben (wäre beim agilem Management natürlich sowieso gegeben), sonst kann es nicht ohne böse Überraschung funktionieren.

Mit Geld lässt sich natürlich eine Menge lösen. Wenn ich eine klar definierte, aber komplexe Anforderung habe, einen festen Abgabetermin und Geld keine Rolle spielt, habe ich gute Chancen auf Erfolg. Das konnte ich vor kurzem bei einer nicht näher genannten Bank beobachten, die von der Bafin für die Erhaltung der Banklizenz relevante Auflagen im Riskmanagement der IT bekommen hatte: Komplexe Anforderung, feste Deadline und so existenzbedrohlich, dass Geld keine Rolle spielte. Also wurden genug Ressourcen zur Verfügung gestellt. Natürlich wichen die Ressourcen deutlich von den ursprünglich geschätzten ab (so um die 100 Prozent nach oben). Aber es wurde ein voller Erfolg. (rb)

1. Strategische Ziele defnieren
Ausgangspunkt für erfolgreiche ECM-Projekte sollte immer eine klare Nutzenanalyse sein, die strategische Ziele festlegt und konkrete Mehrwerte für das Unternehmen definiert. Die Gesamtkosten sollten berechnet sowie mögliche Risiken und Hürden kalkuliert werden.
2. Spezifische Anforderungen berücksichtigen
Fachliche Anforderungen sowie die Ansprüche aller Anwender sollten eingangs differenziert beschrieben werden. Nur ein sorgfältig erstelltes Fachkonzept kann dabei helfen, die Ziele zu erreichen und den Rahmen für Aufwand und Ressourcen präzise zu stecken.
3. Einfachheit als Prinzip
Gleichzeitig fordert die d.velop AG Einfachheit zum Prinzip der konzeptionellen Planung und der entsprechenden Lösung zu erheben. Eine zu komplexe ECM-Lösung würde nur schwer von den Benutzern akzeptiert und zu Lasten der Produktivität gehen. Die geforderte Einfachheit würde sich aber nicht auf den Funktionsumfang beziehen. Vielmehr sollten Implementierung, Bedienung, Betrieb und Pflege des ECM-Systems leicht von der Hand gehen.
4. Lösungen vergleichen
Hat ein Unternehmen erstmal die Ziele und Anforderungen definiert, kann es sich auf dem Markt nach einer geeigneten ECM-Lösung umschauen. Hilfreich bei der Marktevaluierung ist laut d.velop AG ein differenziert ausgearbeitetes Fachkonzept. Neben dem Funktionsumfang sollten bei der Auswahl der Lösung vor allem auch die Benutzerfreundlichkeit berücksichtigt werden, aber auch Innovationsfähigkeit, Flexibilität und partnerschaftliche Kultur des Herstellers.
5. Projekte intelligent planen
Zu einem intelligenten Projektmanagement gehört laut der d.velop AG, dass genaue Vorgaben definiert und präzise Controlling-Prozesse implementiert werden sowie Mitarbeiter mit entsprechenden Fähigkeiten bereitgestellt respektive die Schulung von geeigneten Mitarbeitern geplant werden.
6. Marketing für ECM-Projekte
Im Rahmen des Projektmanagements empfiehlt die d.velop AG IT-Entscheidern, auch an das Projekt-Marketing für ihre ECM-Projekte zu denken. Da Akzeptanzprobleme zu vielen negativen Effekten führen könnten, sollten Mitarbeiter zunächst in die Technologie eingewiesen und so dafür gewonnen werden.
8. Phase der Optimierung
Ebenfalls nicht vergessen werden darf die Zeit nach dem Rollout. Denn mit der Implementierung sei das ECM-Vorhaben längst nicht ausgeschlossen. Vielmehr sollte laut der d.velop AG dann eine Phase für Optimierungsprozesse unter realen Praxisbedingungen eingeläutet werden.