"Unser IT-Projekt? Läuft so nebenher"

7 Gründe, warum IT-Projektmanagement scheitert – 1/2

(Zu) viele IT-Projekte scheitern, laufen also aus dem Zeit- und Budgetrahmen oder werden irgendwann abgebrochen. Die Gründe dafür sind immer wieder die gleichen. Und sie haben oft nichts – wie gern vermutet – mit ungeeigneten Methoden zu tun.

Sie kennen das bestimmt: Ihr Unternehmen startet ein neues IT-Projekt und das Management erwartet, dass Sie reibungslos, fristgerecht und im Kostenrahmen abliefern. Am Anfang ist die Motivation groß und Sie machen schnell Fortschritte. Doch irgendwann hakt es und die Schwierigkeiten häufen sich. Es gibt Reibungen, Termine werden nicht eingehalten, die Beteiligten sind gestresst. Woran liegt das? Unserer Erfahrung nach gibt es einige typische Gründe, wegen denen IT-Projekte regelmäßig zu Problemfällen werden.

Grund 1: Sinn und Zweck des Projekts sind unklar.

Nehmen wir an, Sie sollen eine neue Software entwickeln und einführen. Ihnen und noch viel mehr den anderen Projektbeteiligten ist aber völlig schleierhaft, warum die bisherige Lösung plötzlich nicht mehr geeignet sein soll. Was will das Management mit der neuen Implementierung genau erreichen? Was hat das Unternehmen als Ganzes davon? Wie profitiert die Fach- oder die IT-Abteilung? Wie strikt sind die Zeitvorgaben und warum? Viel zu oft kennen weder Projektleitung noch -beteiligte die Antworten im Detail – und die Auftraggeber sind häufig gar nicht erst an umfänglicher Transparenz interessiert. Stimmt schon: Nicht jedes Detail ist für jeden Projektbeteiligten gleich relevant. Aber wer nicht versteht, warum eine Änderung notwendig ist, der kann auch nicht einschätzen, wie wichtig ein Projekt wirklich ist. Der weiß nicht, ob er etwas Sinnvolles tut und zum Wohl des Unternehmens beiträgt. Oder ob seine Arbeit bei Projektende nicht schon wieder überholt ist. Persönliches Engagement – und damit auch der Projekterfolg – hängen also stark davon ab, wie gut das Management die Beteiligten abholt. Dieser Punkt, der insbesondere das Management fordert und eher in den Bereich des Change Managements gehört, wird immer wieder sträflich vernachlässigt. Es klingt so einfach und selbstverständlich – aber genau deshalb fällt diese Aktivität immer wieder „hinten runter“.

Grund 2: Die Projektbeteiligten werden nicht (ausreichend) freigestellt.

Vom Projektleiter einmal abgesehen sind alle Projektbeteiligten meist voll ins Tagesgeschäft eingebunden. Sie müssen ihre gewohnte Leistung bringen – und das Projekt nebenher stemmen. Kurzzeitig mag das gutgehen, aber bei Laufzeiten von mehreren Wochen oder Monaten sind Interessenskonflikte vorprogrammiert. Wo muss denn nun der Fokus der Mitarbeiter liegen: auf dem operativen Geschäft oder auf der Projektumsetzung? Wenn das schon unklar ist, hat der Projektleiter keine Hebel, um seine Ziele durchzuboxen. Und er bekommt sofort das Gefühl, dass sein Projekt im Grunde unbedeutend ist. Ganz schlechte Voraussetzungen!

„Wie wichtig kann ein Projekt schon sein, für das sich die Beteiligten noch nicht einmal Zeit blocken können?“

– Chris Kohlsdorf, Member of the Management Board, SIRIUS

Grund 3: Das Vorgehensmodell wird falsch zugeschnitten.

Geht ein (IT-)Projekt schief, beginnt die Suche nach den Schuldigen. Und weil niemand die Kollegen bezichtigen will, verbündet man sich schnell gegen einen gemeinsamen Feind, der sich nicht wehren kann: Die Projektmethodik oder das Vorgehensmodell haben nichts getaugt! Wir merken in der Praxis allerdings immer wieder, dass nicht die eigentlichen, ja durchaus gängigen, Vorgehensmodelle das Problem sind, sondern ihr Zuschnitt. Wir haben bereits das Für und Wider von Wasserfallmethodik und agilen Projektmethoden erörtert – und empfohlen, den richtigen Mix aus beiden Varianten zu ermitteln. Genau dabei hakt es aber oft. Viele Teams machen sich vor Beginn eines IT-Projekts nicht ausreichend Gedanken darüber, wie der richtige Methodenmix für ihren Anwendungsfall aussieht. So braucht eine reine Implementierung einer Prozessänderung beispielsweise ein völlig anderes Vorgehen als ein entwicklungslastiges Software-Projekt. Das berüchtigte Schema F funktioniert selten.

Grund 4: Die Projektleitung ist inkonsequent.

Sie haben die passende Methode genutzt – und trotzdem war das Projekt ein Fehlschlag? Dann haben Sie die Methode vielleicht nicht bis zum Ende durchgezogen. Oft sind es vermeintliche Kleinigkeiten, die sich als Schlüsselfaktoren für einen erfolgreichen Projektverlauf herausstellen. Stichwort Protokolle: Zu Projektbeginn wird noch detailliert festgehalten, welche Themen im Jour fixe besprochen, welche Entscheidungen getroffen wurden – nachvollziehbar für jeden. Schon bald aber sinkt die Motivation und der Stress des Tagesgeschäfts setzt ein. Ungeliebte Pflichtübungen wie die regelmäßige Anpassung des Risk Charters oder eine aktualisierte Stakeholder-Analyse bei neu hinzukommenden Playern werden schließlich vernachlässigt. Das kann fatal sein, denn Projektrisiken und Schlüsselpersonen ändern sich in der Regel auch bei relativ kurzen Projektlaufzeiten immer wieder. Wenn Sie dann sinnvolle Gegenmaßnahmen neuer Risiken nicht gewissenhaft ausarbeiten und bewerten, oder die Interessen neu auf den Plan getretener VIPs nicht kennen, stehen Sie am Ende unvorbereitet da.

„Es gibt Aufgaben im Projektverlauf, die machen einfach keinen Spaß. Einige Projektleiter werden dabei schnell nachlässig – und das rächt sich.“

– Chris Kohlsdorf, Member of the Management Board, SIRIUS

Die richtige Balance ist entscheidend

Viele Fehler im IT-Projektmanagement haben also einen ganz ähnlichen Hintergrund: Das Projekt wird nicht so ernst genommen wie das Tagesgeschäft. Hinzu kommt fehlende Erfahrung. Es gibt aber noch weitere kritische Faktoren, die wir immer wieder beobachten – und die man leicht beseitigen kann. Im nächsten Beitrag lesen Sie mehr darüber.

Titelbild: © ra2studio/iStock