Die Frage ist alt. Die Antwort ist es nicht mehr.
Ob ein Projektmanager fachliches Verständnis für sein Themenfeld braucht, wird diskutiert, seit es Projektmanagement gibt. Die Antwort lautete meistens: hilfreich, aber nicht zwingend. Methodik schlägt Domäne.
Diese Antwort war lange richtig. Sie greift 2026 zu kurz.
Was ein Projektmanager immer leisten muss
Zuerst der Teil, der sich nicht verändert. Die Kernaufgaben sind unabhängig von Branche und Technologie:
- Anforderungen aufnehmen und den Umfang gegen Wildwuchs schützen
- Realistisch planen, obwohl niemand alle Größen kennt
- Auf mehreren Ebenen kommunizieren, vom Fachbereich bis zur Geschäftsführung
- Risiken und Veränderungen führen, statt sie zu verwalten
- Ohne disziplinarische Macht führen
Diese Liste lässt sich aus keinem Regelwerk streichen, weder aus PRINCE2 noch aus dem PMI-Standard noch aus einem agilen Vorgehen. Sie ist die eigentliche Disziplin.
Wer sie beherrscht, kann Projekte leiten. Ob er sie in einem IT-Vorhaben gut leitet, entscheidet sich woanders.
Wo technisches Verständnis den Unterschied macht
Aus der Leitung globaler Programme — Migrationen über hundert Standorte, Rollouts für bis zu dreißigtausend Anwender — ist meine Antwort deutlicher, als sie vor zehn Jahren gewesen wäre: es hilft erheblich.
Es hilft an vier Stellen.
Bei der Schätzung. Wer versteht, wie Systeme zusammenhängen, erkennt eine unrealistische Aufwandsangabe, bevor sie im Plan steht. Nicht, indem er selbst rechnet — sondern indem er die richtige Rückfrage stellt.
Bei den Seiteneffekten. Die teuersten Überraschungen entstehen nicht dort, wo gearbeitet wird, sondern an den Rändern: eine Migration, die eine Schnittstelle stillegt, an die seit Jahren niemand gedacht hat.
Bei den Anforderungen. Hier liegt der größte Hebel, und er ist messbar. Rund vierundsechzig Prozent aller Fehler in Softwarevorhaben entstehen in der Anforderungs- und Entwurfsphase — nicht in der Umsetzung. Die Nacharbeit an fehlerhaften Anforderungen verbraucht je nach Erhebung achtundzwanzig bis zweiundvierzig Prozent der Entwicklungskosten (ScopeMaster, Requirements Defects). Wer Anforderungen nur protokolliert, statt sie zu hinterfragen, produziert den größten Teil der späteren Nacharbeit selbst.
Das ist der Grund, warum ich die Anforderungsaufnahme nie an den Anfang stelle und dann abhake. Sie läuft mit, so lange das Vorhaben läuft.
Bei der Übersetzung. Die Geschäftsführung fragt: Warum verzögert sich das, was kostet es, was ist das Risiko? Das technische Team antwortet in Abhängigkeiten und Systemgrenzen. Ohne Übersetzung reden beide Seiten aneinander vorbei — und die Entscheidung, die getroffen werden müsste, fällt nicht.
Was ändert sich durch KI-gestützte Werkzeuge?
Hier verschiebt sich die Anforderung, und zwar nicht in die Richtung, die viele erwarten.
KI-Werkzeuge übernehmen zunehmend die verwaltenden Anteile: Statusberichte, Protokolle, Risikohinweise, Ressourcenabgleich. Diese Arbeit fällt weitgehend weg. Das entlastet — und es entzieht der Rolle gleichzeitig den Teil, in dem sich Unwissen bisher verstecken ließ.
Denn was übrig bleibt, ist Beurteilung. Ein Werkzeug schlägt eine Umplanung vor. Ein anderes meldet ein Risiko. Ein drittes hält eine Schätzung für zu optimistisch. Alle drei klingen gleich überzeugend.
Wer nicht beurteilen kann, welche Empfehlung auf tragfähigen Annahmen beruht, führt kein Projekt mehr. Er führt ein Werkzeug aus.
Genau hier wird fachliches Verständnis vom Vorteil zur Voraussetzung. Nicht, um die Rechnung selbst zu machen. Um zu erkennen, wann sie falsch ist.
Die Kehrseite: Wissen ist kein Mandat
Das größte Risiko für Projektmanager mit technischem Hintergrund ist der Rückfall in die Fachrolle.
Wer früher selbst entwickelt oder Systeme betrieben hat, kennt die Versuchung: In der Diskussion über eine Architekturentscheidung hat man eine Meinung — und sie ist oft gut. Nur ist es nicht mehr die eigene Entscheidung.
Der Schaden ist doppelt. Das Team hört auf, eigene Lösungen zu entwickeln, weil ohnehin von oben entschieden wird. Und die Projektleitung ist mit einer Frage beschäftigt, die jemand anderes besser beantworten kann, während die Fragen liegen bleiben, die nur sie beantworten kann.
Technisches Wissen sollte bleiben, was es ist: ein Werkzeug für bessere Fragen. Kein Mandat für eigene Antworten.
Die Grenze in einem Satz
Ein Projektmanager sollte tief genug sehen, um die richtige Frage zu stellen — und nicht so tief, dass er die Antwort selbst geben will.
Was tun, wenn das technische Verständnis fehlt?
Nicht jeder kommt aus der Technik. Das ist kein Makel, es bedeutet nur, dass man gezielt investieren muss.
Zuhören mit System. Nicht protokollieren, was gesagt wird, sondern verstehen, warum es gesagt wird. Wer nach dem Grund fragt, bekommt die Annahme dahinter — und die ist das eigentlich Interessante.
Fragen stellen, die etwas kosten. „Was passiert, wenn wir diese Abhängigkeit ignorieren?“ zeigt mehr Kompetenz als jedes vorgetäuschte Verständnis. Und sie zwingt das Gegenüber, die Konsequenz auszusprechen.
Nichtwissen offen benennen. Wer zugibt, etwas nicht zu verstehen, gewinnt im Team Respekt. Wer so tut als ob, verliert ihn — nur später und dauerhafter.
Gezielt aufbauen. Domänenwissen lässt sich lernen: durch Gespräche mit den Fachleuten im eigenen Vorhaben, durch strukturierte Einarbeitung in die eingesetzten Systeme, notfalls durch eine Zertifizierung. Was nicht funktioniert, ist der Versuch, sich das Wissen nebenbei aus Statusberichten zusammenzureimen.
Wie tief muss ich sehen?
In der Praxis lässt sich die Frage schärfer stellen als „viel oder wenig“. Es gibt vier Tiefen, und ein Projektmanager braucht drei davon.
| Ebene | Muss die Projektleitung beurteilen können | Gehört an die Fachleute |
|---|---|---|
| Ergebnis | Was ändert sich für den Fachbereich, wenn das fertig ist? | — |
| Funktion | Welche Systeme sind beteiligt, welche Schnittstellen hängen daran? | — |
| Architektur | Warum diese Lösung und nicht die andere, was kostet der Unterschied? | die Auswahl selbst |
| Umsetzung | — | Werkzeuge, Konfiguration, Reihenfolge im Detail |
Bis zur dritten Ebene muss die Projektleitung mitdenken können — nicht, um zu entscheiden, sondern um die Entscheidung zu verstehen und ihre Folgen für Termin und Budget zu benennen. Die vierte Ebene gehört den Fachleuten. Wer dort mitredet, verliert die drei darüber aus dem Blick.
Der teuerste Fehler ist übrigens nicht, zu wenig zu verstehen. Es ist, auf der falschen Ebene zu arbeiten.
Die Faustregel
Eine brauchbare Faustregel aus der Praxis: Sie brauchen so viel Verständnis, dass Sie eine technische Erklärung in eine Entscheidungsvorlage übersetzen können — Wirkung auf Termin, Kosten und Risiko, dazu zwei bis drei Optionen.
Wenn Sie das können, reicht es. Wenn Sie merken, dass Sie stattdessen den Vorschlag selbst korrigieren wollen, ist es zu viel geworden.
Fazit
Die klassische Antwort lautet „es kommt darauf an“. Das stimmt — aber die entscheidende Größe ist nicht, ob technisches Wissen vorhanden ist. Sie ist, wie es eingesetzt wird.
Ein Projektmanager mit tiefem technischem Hintergrund, der in die Fachrolle zurückfällt, ist gefährlicher als einer ohne technisches Wissen, der sauber führt und die richtigen Leute fragt.
Der beste IT-Projektmanager ist der, der weiß, wie viel er wissen muss — und wann er die Fachleute reden lässt.
Häufige Fragen
Muss ein IT-Projektmanager programmieren können?
Nein. Er muss verstehen, was Programmierung im konkreten Vorhaben bedeutet: welche Abhängigkeiten bestehen, warum eine Schätzung so ausfällt, welche Entscheidung sich später nur teuer korrigieren lässt. Selbst zu programmieren ist dafür nicht nötig und kostet Zeit, die der Rolle an anderer Stelle fehlt.
Ist ein Quereinsteiger ohne IT-Hintergrund im IT-Projektmanagement chancenlos?
Nein, aber er muss die Lücke aktiv schließen. Wer methodisch stark ist, konsequent nachfragt und Nichtwissen offen benennt, arbeitet sich in ein bis zwei Vorhaben ein. Wer die Lücke überspielt, wird vom Team nicht ernst genommen — und merkt es zuletzt.
Wo genau kippt technisches Wissen ins Schädliche?
An dem Punkt, an dem die Projektleitung anfängt, technische Entscheidungen selbst zu treffen statt sie zu moderieren. Das Anzeichen ist meist unauffällig: Die Fachleute bringen keine eigenen Vorschläge mehr mit, weil sie wissen, dass ohnehin von oben entschieden wird.
Wie erkenne ich als Auftraggeber, ob ein Projektleiter genug versteht?
Stellen Sie eine offene technische Frage zum Vorhaben. Eine gute Antwort ordnet ein, nennt die Unsicherheit und benennt, wen man fragen müsste. Eine schlechte Antwort ist entweder ein Fachvortrag oder eine Ausweichbewegung. Beides ist ein Signal.
Verändert KI die Anforderungen an technisches Verständnis?
Sie erhöht sie. Verwaltende Arbeit fällt weg, beurteilende bleibt. Wenn ein Werkzeug eine Umplanung vorschlägt oder ein Risiko meldet, muss jemand entscheiden, ob die Annahmen dahinter tragen. Diese Entscheidung lässt sich nicht delegieren — und ohne fachliches Verständnis auch nicht treffen.
Passend dazu
- Warum Ihr bester Techniker die IT-Projektleitung gefährdet — Was passiert, wenn Fachtiefe und Leitung in einer Person liegen
- Warum IT-Projekte echte Projektleiter brauchen — Warum Projektleitung kein Nebenbei-Job ist
- KI im IT-Projektmanagement: Werkzeug ja, Verantwortung nein — Wie KI die Anforderungen an Urteilsvermögen verschiebt