560 Millionen Dollar. So viel hat der Flughafen Denver in den Neunzigern für ein vollautomatisiertes Gepäckband verbrannt – zwei Jahre Verspätung, doppeltes Budget, am Ende wurde das System nie richtig fertig. Der Grund war nicht die Technik. Es waren über 2.000 Änderungsanfragen von Stakeholdern, die niemand strukturiert gemanagt hat. Klingt absurd – bis man sich die Slack-Kanäle der eigenen Agentur ansieht, in denen der Kunde um 16:47 Uhr noch schnell "eine Kleinigkeit" nachschiebt.

IT-Projektmanagement ist eines dieser Themen, bei denen die meisten denken, sie machen es schon ganz ordentlich. Die Zahlen erzählen eine andere Geschichte.

IT-Projektmanagement – mehr als Gantt-Charts und Statusmeetings

Die Standish Group veröffentlicht seit 1994 den CHAOS Report, eine der größten Langzeitstudien zu IT-Projekten weltweit. Die Ergebnisse von 2020: 31 % aller IT-Projekte sind erfolgreich. 50 % werden als "challenged" eingestuft – sie kommen irgendwie ins Ziel, aber zu spät, zu teuer oder mit abgespecktem Scope. 19 % scheitern komplett.

31 % Erfolg. 50 % irgendwie. 19 % Totalausfall. Und das nach dreißig Jahren Verbesserung – 1994 lag die Erfolgsquote bei 16 %.

Für IT-Dienstleister und Agenturen verschärft sich das Problem. Anders als interne IT-Abteilungen arbeiten Dienstleister parallel an 5, 10, manchmal 20 Projekten gleichzeitig. Jedes mit einem anderen Kunden, anderen Erwartungen, anderen Kommunikationswegen. IT-Projektmanagement in diesem Kontext bedeutet nicht, ein einzelnes Vorhaben durch ein Phasenmodell zu schieben. Es bedeutet, ein Portfolio aus laufenden Projekten so zu steuern, dass am Monatsende noch Marge übrig ist.

Das unterscheidet den Dienstleister-Kontext fundamental vom Lehrbuch. Im Lehrbuch hat ein Projekt einen Sponsor, ein Team und ein Budget. In der Agentur teilen sich drei Projekte denselben Entwickler, der Sponsor ist gleichzeitig der Praktikant beim Kunden, und das Budget wurde im Vertrieb "ein bisschen optimistisch" kalkuliert.

Worum es wirklich geht

IT-Projektmanagement für Dienstleister ist im Kern die Fähigkeit, drei Dinge gleichzeitig im Griff zu haben: die Erwartungen des Kunden, die Auslastung des Teams und die wirtschaftliche Gesundheit des Projekts. Wer nur zwei davon managed, bekommt früher oder später ein Problem mit dem dritten. Kundenglück bei negativer Marge? Kurzfristig möglich, mittelfristig Insolvenz. Gute Marge bei überlasteten Teams? Funktioniert ein Quartal, dann kündigen die Besten. Das Dreieck muss stehen.

Agile, Scrum, Wasserfall – welche Methode passt zu wem?

Die Methodendebatte füllt seit zwanzig Jahren Konferenzsäle und LinkedIn-Feeds. Die Kurzfassung: Agile Projekte haben laut CHAOS Report 2020 eine Erfolgsquote von 42 %, Wasserfall-Projekte liegen bei 13 %. Klingt eindeutig – ist es aber nicht.

Die ehrliche Antwort für die meisten IT-Dienstleister: Ihr arbeitet bereits hybrid – ohne es so zu nennen. Kaum jemand macht reines Scrum mit allem Drum und Dran. Der Scrum Master heißt in der Realität "Projektleiter" und führt nebenbei doch ein Gantt-Chart, weil der Kunde es sehen will. Und kaum jemand macht noch reines Wasserfall, weil die Anforderungen sich ändern, bevor die Spezifikation fertig geschrieben ist.

Die Methode ist selten das Problem

Der entscheidende Punkt ist nicht die Methode. Es ist die Frage, ob dein Team überhaupt ein gemeinsames Verständnis davon hat, wie ihr Projekte abwickelt. Wenn jeder Projektleiter sein eigenes System fährt – in Excel, Notion, Jira oder im Kopf –, ist die Methode egal. Dann hast du kein IT-Projektmanagement. Du hast organisiertes Chaos mit individuellen Workarounds.

Wer sich für die Schnittstelle zwischen agilen Methoden und harter Zeiterfassung interessiert, findet in unserem Artikel über agile Zeiterfassung ein paar unbequeme Wahrheiten dazu.

Die 7 teuersten Fehler im IT-Projektmanagement

Ich könnte jetzt behaupten, dass wir bei Leadtime nie einen dieser Fehler gemacht haben. Wäre gelogen. Hier sind die sieben, die ich in 15 Jahren am häufigsten gesehen habe – bei uns selbst und bei hunderten Agenturen, mit denen wir gesprochen haben.

1. Scope Creep ohne Kontrollmechanismus. PMI hat 2018 gemessen: 52 % aller Projekte erleben unkontrollierte Scope-Änderungen. Bei Organisationen mit strukturiertem Change Management sinkt die Zahl auf 33 %. Der Unterschied sind keine komplizierten Prozesse – es reicht oft, wenn jemand die Frage stellt: "Ist das im Scope? Wenn nein, was kostet die Änderung und wer gibt sie frei?" Ein Satz, der tausende Euro spart.

2. Zeiterfassung als Buchhaltungs-Pflicht statt Steuerungsinstrument. Die meisten Agenturen tracken Zeit, damit die Rechnung stimmt. Die wenigsten nutzen die Daten in Echtzeit, um zu erkennen, dass Projekt X seit drei Wochen die Marge frisst. Freitag um 17 Uhr merken, dass das Budget aufgebraucht ist – das ist kein Controlling, das ist Archäologie.

3. Ressourcenplanung nach Bauchgefühl. "Der Tobias hat nächste Woche bestimmt noch Kapazität." Hat er nicht. Aber das merkt man erst am Montag, wenn drei Projekte gleichzeitig nach ihm fragen.

4. Kein einheitliches Projekttool. Jeder Projektleiter nutzt sein Lieblingswerkzeug. Ergebnis: Niemand hat einen Gesamtüberblick über alle laufenden Projekte. Wer mehr als fünf Projekte gleichzeitig steuert, kommt um das Thema Multiprojektmanagement nicht herum.

5. Festpreis ohne Puffer. Festpreisprojekte funktionieren – wenn man 20–30 % Puffer einkalkuliert. Die meisten Agenturen kalkulieren mit 5 % und wundern sich dann, warum jedes dritte Projekt rot wird.

6. Statusmeetings ohne Substanz. Wöchentliches "Was hast du letzte Woche gemacht?"-Meeting kostet je nach Teamgröße 10–20 Personenstunden pro Monat. Ein gutes Dashboard ersetzt 80 % dieser Meetings.

7. Projekte werden nie offiziell beendet. Kein Retro, kein Lessons Learned, kein sauberer Abschluss. Und sechs Monate später macht man denselben Fehler im nächsten Projekt.

IT-Projektmanagement-Software im Praxisvergleich

Die Tool-Landschaft für IT-Projektmanagement-Software ist unübersichtlich. Statt eines Feature-Shootouts hier die vier Kategorien und ihre jeweiligen blinden Flecken: Klassische PM-Tools (MS Project, Smartsheet) sind stark bei Gantt-Charts und Meilensteinen, haben aber keine integrierte Zeiterfassung. Agile Boards (Jira, Linear) sind gut für Sprint-Planung, bieten aber keinen Blick auf Budget oder Marge. Collaboration-Suiten (Notion, Asana, Monday) sind flexibel, aber zu generisch für Dienstleister. PSA/ERP-Lösungen (Leadtime, Productive, Scoro) verbinden PM, Finance und Ressourcen in einem System.

Die eigentliche Frage ist nicht: Welches Tool hat die meisten Features? Sondern: Welches Tool zeigt mir am Freitagabend, ob meine Projekte noch profitabel sind?

Der Frankenstein-Stack

Die meisten IT-Dienstleister landen irgendwann bei einem gewachsenen Stack: Jira für Entwicklung, Harvest oder Toggl für Zeiterfassung, Excel für Budgets, Slack für Kommunikation. Jedes Tool für sich ist brauchbar. Zusammen erzeugen sie Datensilos – und niemand hat das Gesamtbild.

Was IT-Dienstleister wirklich brauchen

Ein Werkzeug für IT-Projektmanagement in Agenturen muss vier Dinge können: Erstens Zeiterfassung und Projektbudget in Echtzeit verknüpfen. Zweitens Auslastung über alle Projekte hinweg sichtbar machen. Drittens Kundenkommunikation und Support-Tickets am Projekt aufhängen. Viertens Finanzen als natürlichen Teil des Projektmanagements behandeln.

Warum klassische PM-Tools für IT-Dienstleister nicht reichen

Die meisten PM-Tools wurden für interne Projektteams gebaut: ein Projekt, ein Team, ein Budget. IT-Dienstleister leben in einer anderen Realität – viele Projekte parallel, geteilte Ressourcen, externe Kunden mit Erwartungen, die sich wöchentlich ändern.

Klassische IT-Projektmanagement-Software denkt in Aufgaben und Meilensteinen. Dienstleister denken in Stunden und Margen. Wenn dein PM-Tool dir nicht sagen kann, ob Projekt X bei aktuellem Stundenverbrauch noch profitabel sein wird – dann ist es ein Aufgaben-Manager mit hübscher Oberfläche. Kein Steuerungsinstrument.

Wir haben Leadtime genau für diesen Zwischenraum gebaut – Projektmanagement, Ticketing und Finanzen in einem System. Nicht, weil wir schlauer waren als alle anderen, sondern weil wir bei eins+null jahrelang genau diesen Frankenstein-Stack betrieben haben und irgendwann keine Lust mehr hatten, Zahlen zwischen fünf Tools hin- und herzukopieren.

IT-Projektmanagement wird nicht durch die richtige Methode besser. Auch nicht durch das richtige Tool. Es wird besser, wenn man aufhört, Methode, Werkzeug und Realität als drei getrennte Welten zu behandeln – und anfängt, sie als ein System zu denken.