Ein Unternehmen steht vor einem großen IT-Vorhaben. Migration, Rollout, Modernisierung. Die Frage nach der Leitung wird schnell beantwortet: der beste Techniker im Haus. Er kennt die Systeme, hat Vertrauen, denkt mit.
Die Entscheidung ist nachvollziehbar. Und sie geht in großen Vorhaben regelmäßig schief.
Warum wird aus dem besten Techniker selten ein guter Projektleiter?
Weil Fachtiefe und Steuerung nicht dieselbe Fähigkeit sind — und weil die Beförderung genau die Person aus der Rolle nimmt, in der sie gebraucht wird.
Der Mechanismus dahinter ist alt und hat einen Namen. Laurence J. Peter beschrieb 1969, dass Menschen in Organisationen so lange befördert werden, bis sie eine Stelle erreichen, der sie nicht gewachsen sind — und dort bleiben. Der bissige Teil daran ist, dass die Beförderung jedes Mal verdient war. Belohnt wird Leistung in der alten Rolle, gefordert ist Eignung für die neue.
Genau das passiert bei der Projektleitung. Ein erfahrener Entwickler oder Architekt denkt in Lösungen, in Abhängigkeiten, in Systemzusammenhängen. Das ist die Leistung, für die er da ist. Projektleitung verlangt etwas anderes: Kompromisse gegen Zeit und Budget, Kommunikation mit Menschen, die den technischen Gehalt nicht bewerten können, und das Aushalten von Entscheidungen, die technisch nicht die beste Lösung sind.
Ich habe das in einem globalen Carve-In-Programm erlebt. Mehrere Arbeitsstränge mit jeweils eigener technischer Leitung, ein enger Termin, mehrere Länder. Ein Strang wurde von einem exzellenten Architekten geführt. Nach vier Monaten war seine Teillösung die technisch sauberste im ganzen Programm — und die einzige, die den Termin gerissen hat.
Die Warnsignale sind dabei immer dieselben:
- Perfektion vor Umfang. Technische Details werden weiter optimiert, während Termin und Budget aus dem Blick geraten. Die Lösung wird besser. Fertig wird sie nicht.
- Selbstüberlastung. Der Projektleiter arbeitet an der Umsetzung mit, statt zu steuern und Hindernisse abzuräumen. Er ist der beste Mann im Team — und deshalb der Engpass.
- Risiko-Scheuklappen. Technische Risiken werden früh erkannt und sauber bewertet. Organisatorische, politische und finanzielle Risiken tauchen im Bericht gar nicht auf.
- Fehlende Übergabe. Weil der Experte oft der Erfahrenste im Raum ist, fällt Loslassen schwer. Jede Entscheidung läuft über ihn.
Der Interessenkonflikt, über den kaum jemand spricht
Es gibt ein Problem, das tiefer liegt als die Frage nach Erfahrung. Ein Technikexperte, der gleichzeitig Projektleiter ist, entscheidet nicht neutral.
Er bevorzugt die Lösung, die er selbst am besten beherrscht. Er unterschätzt Aufwände in seinem eigenen Fachgebiet — nicht aus Nachlässigkeit, sondern weil ihm die Aufgabe leicht fällt und er von sich auf andere schließt. Und er wählt bei einer Grundsatzentscheidung im Zweifel den technisch eleganteren Weg, auch wenn der pragmatische das Projektziel schneller erreicht hätte.
Das Ergebnis ist ein Vorhaben, das komplexer ist als nötig. Der Umfang wächst nicht durch Wünsche der Fachbereiche, sondern durch die Ansprüche der Projektleitung an sich selbst.
Woran Sie es merken
Wenn im Statusbericht technische Fortschritte stehen, aber keine Aussage darüber, ob der Termin noch hält — dann berichtet die Fachrolle, nicht die Projektleitung.
Dazu kommt die Übersetzungsleistung. Ein Projektleiter muss technische Sachverhalte in Entscheidungsvorlagen übersetzen: Was bedeutet das für Termin, Kosten und Risiko, und welche Optionen gibt es? Für viele Fachexperten ist genau das die unangenehmste Aufgabe — weil sie Vereinfachung verlangt, und Vereinfachung fühlt sich für einen Experten wie Ungenauigkeit an.
Was macht einen guten IT-Projektleiter dann aus?
Nicht technische Tiefe. Sondern Urteilsvermögen, Kommunikation und die Fähigkeit, ohne disziplinarische Macht zu führen.
Das Project Management Institute erhebt jährlich, welche Fähigkeiten in erfolgreichen Vorhaben den Unterschied machen. Über Regionen, Branchen und Erfahrungsstufen hinweg nennen die Befragten dieselben vier: Kommunikation, Problemlösung, gemeinschaftliche Führung, strategisches Denken.
Die zugehörigen Zahlen sind deutlich. In Organisationen, die diese Fähigkeiten hoch gewichten, erreichen zweiundsiebzig Prozent der Vorhaben ihre Geschäftsziele. Nur achtundzwanzig Prozent leiden unter wachsendem Umfang. Und wenn ein Vorhaben doch scheitert, gehen im Schnitt siebzehn Prozent des Budgets verloren statt eines deutlich höheren Anteils (PMI, Pulse of the Profession 2023).
Keine dieser vier Fähigkeiten hat mit technischer Tiefe zu tun.
So sieht der Unterschied in der Praxis aus:
| Dimension | Technikexperte in der Leitungsrolle | Professionelle Projektleitung |
|---|---|---|
| Erstes Ziel | technisch beste Lösung | Termin, Budget, vereinbarter Umfang |
| Sprache | Fachterminologie | Wirkung für Fachbereich und Geschäftsführung |
| Führung | selbst mitarbeiten, operativ steuern | delegieren, moderieren, Hindernisse räumen |
| Risikoblick | technisch | technisch, organisatorisch, finanziell |
| Bei Eskalation | technische Erklärung | Einordnung, Optionen, Empfehlung |
Die Überschneidung ist gering. Das ist der Punkt. Beide Rollen sind wertvoll, beide sind nötig — nur nicht in einer Person.
Ein technisches Grundverständnis ist bei der Projektleitung trotzdem hilfreich. Es hilft beim Einschätzen von Schätzungen und beim Erkennen von Seiteneffekten. Es ist ein Werkzeug für bessere Fragen, kein Anspruch auf eigene Antworten.
Nimmt KI der Projektleitung die Arbeit ab?
Einen Teil, und zwar genau den, der am wenigsten mit Führung zu tun hat.
Gartner sagte bereits 2019 voraus, dass bis 2030 rund achtzig Prozent der heutigen Aufgaben in Projektbüros wegfallen — Datenerfassung, Statusberichte, Nachverfolgung (SiliconANGLE über die Gartner-Prognose). Diese Prognose war für 2019 kühn und wirkt heute eher vorsichtig.
Was Werkzeuge heute übernehmen: Termine protokollieren und Aufgaben zuweisen. Pläne gegen historische Verläufe prüfen und unrealistische Schätzungen markieren. Aus Projektdaten früh auf Budget- oder Ressourcenengpässe hinweisen.
Was sie nicht übernehmen: einen aufgebrachten Auftraggeber in einer Eskalation beruhigen. Zwischen zwei Abteilungsleitern moderieren, die unterschiedliche Vorstellungen vom Umfang haben. Merken, dass ein Team am Anschlag läuft. Oder lesen, welche politische Konstellation darüber entscheidet, ob eine technisch richtige Entscheidung intern überhaupt akzeptiert wird.
Für den Mittelstand gilt dabei ein Satz besonders: KI verstärkt vorhandene Strukturen. Sie ersetzt keine fehlenden. Wer heute kein sauberes Risikomanagement führt, bekommt durch ein Werkzeug kein Risikomanagement. Er bekommt schnelleres Chaos.
Was heißt das für ein mittelständisches Unternehmen?
Die Ausgangslage ist fast immer dieselbe: Der laufende Betrieb bindet die Mannschaft vollständig, gleichzeitig stehen Modernisierung, Sicherheitsanforderungen und Cloud-Vorhaben an. Eine eigene Projektleitungsstelle rechnet sich für ein einzelnes Vorhaben selten.
Was ich in der Praxis häufig sehe: Mittelständler, die tatsächlich Projektleiter beschäftigen, haben sie im Produktbereich, im Bau oder in der Fertigung — nicht in der IT. Dort sitzt Fachtiefe, aber keine Steuerungsrolle.
Drei Wege funktionieren.
Trennen. Der Techniker bleibt fachlich verantwortlich, die Projektleitung liegt bei jemand anderem. Das ist keine Herabstufung, sondern eine Entlastung — und die meisten Fachexperten empfinden es nach kurzer Zeit auch so.
Bündeln. Drei bis fünf mittlere Vorhaben zusammen rechtfertigen eine Steuerungsfunktion, die für jedes einzelne zu groß wäre.
Auf Zeit holen. Externe Projektleitung für die Dauer des Vorhabens, mit einer Übergabe an den Betrieb am Ende. Der Nebeneffekt ist der eigentliche Gewinn: Methodik, die im Haus bleibt.
Fazit
Es gibt Vorhaben, die in Personalunion funktionieren. Kleiner Umfang, ein Fachbereich, wenige Beteiligte, ein Techniker mit ausgeprägtem Sinn für Termine — das geht gut.
Je größer das Vorhaben, je mehr Beteiligte und je mehr Interessen aufeinandertreffen, desto stärker kippt die Waage. Dann ist die Doppelrolle kein Sparmodell mehr, sondern ein Risiko.
Nicht weil Techniker das nicht könnten. Sondern weil es eine eigene Disziplin ist — und weil niemand zwei anspruchsvolle Aufgaben gleichzeitig gut macht.
Häufige Fragen
Ist es immer falsch, einen Techniker zum Projektleiter zu machen?
Nein. Bei kleinem Umfang, einem beteiligten Fachbereich und überschaubarer Laufzeit funktioniert es regelmäßig. Kritisch wird es, sobald mehrere Fachbereiche, mehrere Dienstleister und widersprüchliche Interessen im Spiel sind — dann verlangt die Rolle Entscheidungen gegen die technisch beste Lösung, und genau die fallen einem Experten am schwersten.
Woran erkenne ich, dass die Doppelrolle nicht funktioniert?
An drei Anzeichen: Der Statusbericht enthält technische Fortschritte, aber keine Aussage zum Termin. Der Projektleiter arbeitet an Umsetzungsaufgaben mit. Und Risiken werden ausschließlich technisch beschrieben, während organisatorische und finanzielle Risiken fehlen.
Verliert der Techniker durch die Trennung an Ansehen?
In der Praxis eher das Gegenteil. Die fachliche Verantwortung bleibt bei ihm, und er bekommt die Zeit zurück, die vorher in Abstimmung und Berichtswesen ging. Wichtig ist, die Trennung als Entlastung zu erklären und nicht als Korrektur — und die fachliche Entscheidungshoheit auch tatsächlich bei ihm zu lassen.
Braucht ein Projektleiter überhaupt technisches Wissen?
Genug, um Schätzungen einzuordnen, Seiteneffekte zu erkennen und die richtigen Fragen zu stellen. Nicht so viel, dass er die Antworten selbst geben will. Technisches Wissen ist ein Werkzeug für bessere Fragen — sobald es zum Anspruch auf eigene Lösungen wird, wird es zum Risiko.
Ersetzt KI die Projektleitung im Mittelstand?
Nein, aber sie verschiebt den Schwerpunkt. Berichte, Protokolle und Nachverfolgung fallen weitgehend weg. Was bleibt, ist der Teil, der schon vorher der schwierigere war: Entscheidungen vorbereiten, Interessen ausgleichen, Menschen führen. Werkzeuge verstärken vorhandene Strukturen — sie ersetzen keine fehlenden.
Passend dazu
- Warum IT-Projekte echte Projektleiter brauchen — Warum die Rolle überhaupt eigenständig besetzt gehört
- Wie viel technisches Know-how braucht ein IT-Projektmanager? — Wo technisches Wissen hilft – und wo es zum Risiko wird
- KI im IT-Projektmanagement: Werkzeug ja, Verantwortung nein — Was KI dem Projektmanagement abnimmt und was nicht