Wie man IT-Projekte verpatzt – und wieder rettet

IT-Projekte

Software ist logisch. Menschen sind nicht logisch. Das kann, gelinde gesagt, zu Frustrationen bei der Ausführung eines technischen Projektes führen.

Das Ziel bei solchen Projekten ist einfach: etwas herzustellen, das funktioniert. Aber ob es nun um eine Hochrüstung der Infrastruktur, einen Wechsel zu einem neuen System oder eine Zusammenlegung von zwei Plattformen zu einer geht, die Wahrscheinlichkeit, dass irgendjemand das Projekt verpatzt, ist groß.

Die Zahlen bezüglich des Scheiterns von Projekten sind trüb. Die Standish Group aus Boston, eine Primärforschungsfirma, die sich auf Software-Performance-Werte konzentriert, fand heraus, dass zwischen 17 und 22 Prozent aller IT-Projekte scheiterten; weitere 49 bis 56 Prozent fielen in die Kategorie „schwierig.”

Wenn es ums Scheitern geht, ist auch die Größe wichtig. Die Standish Group fand, dass kleinere Projekte in 61 Prozent der Fälle erfolgreich waren. Im Gegensatz dazu erreichten nur zwei Prozent der größten Projekte die sprichwörtliche Ziellinie.

Und diese schlechten Zahlen beschränken sich nicht auf eine einzige Firma. McKinsey & Co. erhielt ebenso miese Statistiken und schätzte, dass große Software-Projekte in 66 Prozent der Fälle das Budget überschritten; rund 33 Prozent verzögerten sich. Und etwa 17 Prozent der Projekte bedeuteten aufgrund des schlechten Managements und der schlechten Ausführung eine regelrechte Gefahr für die Unternehmen.

Kein Wunder, dass drei von vier Führungskräften davon ausgehen, dass ihre Software-Projekte scheitern. Und denken Sie nicht, dass die Dinge außerhalb der USA besser aussehen: eine andere Studie von dem Chartered Institute in GB für IT ergab, dass fast ein Viertel aller technischen Projekte letztendlich abgebrochen wurden.

Es ist einfacher, ein Haus zu bauen

„Bei IT-Projekten ist die Wahrscheinlichkeit des Scheiterns größer als bei einem herkömmlichen Bauprojekt”, meint Jos Creese, digitaler Consultant und ehemaliger Präsident der British Computer Society.

Technische Projekte sind vom Konzept her komplex, und Abkürzungen können dazu führen, dass ein Manager oder Unternehmen mit einer Lösung endet, die sinnlos ist oder einfach nicht funktioniert. Dazu kommt noch die Geschwindigkeit, mit der sich die Technologie entwickelt: wenn man nicht schnell eine Lösung liefert, ist sie bereits veraltet, wenn der Kunde sie erhält, erklärt Creese.

Das gilt vor allem für Fusionen und Übernahmen, wenn zwei Firmen ihre jeweilige technische Infrastruktur zu einer gemeinsamen Plattform zusammenlegen müssen, die (hoffentlich) funktioniert. „Viel deutet darauf hin, dass Fusionen und Übernahmen stark von der Fähigkeit abhängen, Technologien zu integrieren”, sagte Creese. Wenn dies nicht erfolgreich durchgeführt werden kann, „verliert man den Nutzen der Übernahme.”

Es ist wichtig, dass alle Stakeholder von Anfang an die notwendigen Ziele und Rahmen kennen. Projekte scheitern, „weil die Leute sie nicht verstehen”, fügte Creese hinzu. Gleichzeitig kann es auch zu einer Katastrophe führen, wenn man sich strikt an einen Plan hält, falls dieser Plan sich nicht an veränderliche Umstände anpassen lässt.

Den richtigen Manager finden

Trotz der Risiken des Scheiterns meint Jim Johnson, „der leitende Träumer” der Standish Group, dass es bei technischen Projekten „mehr Erfolge als Misserfolge gibt“.

Je größer und komplexer das Projekt, desto größer die Wahrscheinlich, dass es scheitert, stellte er fest: „Es gibt zu viele Väter des Projektes, die meist in Konflikt zueinander stehen… so kommt es zu verzögerten Entscheidungen, rückgängig gemachten Entscheidungen und schlechten Entscheidungen.”

Daher ist ein „guter Sponsor” notwendig, den Johnson als „eine Führungskraft mit Inspiration, Kreativität und Knowhow im Umgang mit Menschen sowie das Wissen definiert, schnelle und bleibende Entscheidungen zu treffen.”

Das Konzept des „guten Sponsors” ergab sich aus den Tausenden von Projekten, die die Standish Group auf ihrer Suche nach gemeinsamen Faktoren für den Erfolg oder Misserfolg untersuchte. „Es gab eine direkte Korrelation zwischen einer Förderung durch eine Führungskraft und dem Erfolg großer Projekte”, sagte Johnson. „Eine wichtige Eigenschaft, über die sie [gute Sponsoren] verfügen müssen, ist, dass sie bestimmend sein müssen. Man braucht keine gute Person sein, um bestimmend zu sein. Man muss nur konkret sein.”

Ein guter Sponsor ist typischerweise kein Techniker, fügte er hinzu: „Diese haben keine Empathie für die Leute, die das System benutzen… Wenn der Benutzer nicht weiß, wie er das System benutzen muss, ist das System ein Misserfolg.”

Creese stimmte diesen Ansichten zu, auch wenn er leitende Digital Officer als die obersten Aufseher oder Sponsoren von technischen Projekten bevorzugte. Bei diesem Konzept arbeitet der leitende Digital Officer mit den geschäftlichen Führungspersonen zusammen, um die Plattform oder den Service anhand aktueller, von der Technologie präsentierter Gelegenheiten zu entwickeln. Danach leitet der leitende DO den Plan an den CIO weiter, der für die Umsetzung und Lieferung der Lösung zuständig ist.

Wahnsinn mit Methode

Unabhängig davon, welche Führungskraft das Projekt leitet, der Prozess ist wichtig: der Erfolg des Projekts hängt von der Methode ab.

Creese ist der Ansicht, dass ideale Methoden Disziplin mit Flexibilität kombinieren müssen. Disziplin hält den Manager davon ab, alles ändern zu wollen, während Flexibilität bedeutet, dass man weiß, wann eine Änderung notwendig ist.

„Vorsicht vor den Methoden”, warnte Creese. Geschäftsbücher sind voller Ratschläge, und es gibt „viele nützliche Details.” Nehmen Sie die Ideen auf, aber denken Sie daran, dass es keinen genauen Plan oder Rezept gibt, dem man folgen kann, damit ein Projekt Erfolg hat. „Setzen Sie Ihre Erfahrung, Ihren gesunden Menschenverstand und Ihre Intelligenz ein.”

IT-Projekte erfordern eine leichtere Hand als ein System des Befehlens und Kontrollierens oder ein Top-Down-Management. Für ein Höchstmaß an Reaktionsfähigkeit und Flexibilität muss das Team eine gewisse Autonomie haben. Das höhere Management muss eine klare Vision vorgeben und sich dann zurückziehen.

Als die Standish Group in einer umfassenden Fünfjahresstudie nach einer Korrelation zwischen Methode und Erfolg suchte, fand sie heraus, dass eine agile Methodik doppelt so gut funktionierte wie der von oben geleitete Top-Down-Wasserfall, bei dem jeder Schritt des Projekts kaskadiert werden muss.

Agile Methoden hatte eine Erfolgsquote von 18 Prozent bei großen Projekten, im Vergleich zu einer Erfolgsquote von 3 Prozent bei der Wasserfallmethode. Eine weitere wichtige Messgröße: Agile Methoden scheiterten nur bei 23 Prozent der großen Projekte, wogegen die Misserfolgsquote der Wasserfallmethode 42 Prozent betrug. (Beide Methoden führten in rund der Hälfte der Fälle zu „mit Schwierigkeiten verbundenen Ergebnissen“.)

Der große Unterschied zwischen der agilen und der Wasserfallmethode besteht darin, dass zur ersten Methode Feedback gehört, zur letzteren hingegen nicht, erklärte Johnson: „Man durchläuft die Schritte [bei dem Wasserfallmodell]. Wenn die Schritte nicht richtig sind, verpatzt man die Sache.”

Bei der agilen Methode werden Lösungen gebaut, getestet und ausprobiert, wobei häufig Änderungen auf der Grundlage von Benutzerfeedback übernommen werden. Das ist ein schnellerer Prozess, der sich auf kleinere Teams verlässt. “Bei der agilen Methode gibt es immer einen Projektverantwortlichen“, stellte Johnson fest.

Vorsicht vor Menschen

„Menschen treffen dumme Entscheidungen, vor allem Gruppen von Menschen“, sagte Johnson. „Zeit ist der Feind aller Projekte”, meinte er. Wenn die Teams klein sind und Entscheidungsgewalt haben, kann das Unternehmen schnellere Entscheidungen über ein Projekt treffen; Wartezeiten verringern die Erfolgschancen.

„Es ist immer ein menschliches Problem“, fügte Creese hinzu. Projekte scheitern, „weil die Leute sie nicht verstehen.”

Alle Projektmanager Jobs anschauen 

No comments yet.

Leave a Reply

WP-SpamFree by Pole Position Marketing