Erst denken, dann loslaufen – vom ehrlichen Umgang mit Projekten und mit sich selbst

Erst das System, dann das Handeln

Am Anfang steht nicht das Tun, sondern das Nachdenken, welches ein System braucht. Einen Weg, Gedanken erst zu sammeln und dann in eine Form zu bringen, die möglichst nichts Wichtiges verliert. Wie dieses System aussieht, ist dabei zweitrangig: Es kann eine Checkliste sein, ein Kanban-Board oder eine strukturierte Fragensammlung. Entscheidend ist nicht das Format, sondern dass überhaupt eines existiert. Ein System, das den Blick auf dem Thema hält, statt ihn der eigenen Tagesform zu überlassen. Ich nehme im Folgenden Beispiel einfach die Checkliste, weil sie die schlichteste dieser Formen ist und allen bekannt sein dürfte. Das Prinzip dahinter gilt aber für jedes andere System.

Checklisten erscheinen zunächst erst mal unsexy. Damit lässt sich in einer Besprechung nicht auftrumpfen, und im Vergleich zu agilen Methoden oder dem neuesten Tool wirken sie zugegeben etwas altmodisch und banal. Für manch einen erfahrenen Projektleiter fühlt sich eine Checkliste sogar an wie ein Eingeständnis, dass man seine Aufgabe nicht beherrscht oder das Projekt nicht ernst nimmt, weil man es zunächst augenscheinlich in einen Standard pressen will. Bemerkenswert ist dabei nur, dass in den Bereichen, in denen Fehler unmittelbar Menschenleben kosten, in der Luftfahrt und im Operationssaal, niemand auf die Idee käme, auf sie zu verzichten. Dort sind Checklisten kein Zeichen von Unsicherheit, sondern schlicht Ausdruck von Professionalität. Genauso sollte man sie auch im Projekt verstehen: als das stille Rückgrat jedes gut geführten Projektstarts. Gerade in der Projektanfangsphase, beim Kick-off, in den ersten Workshops, bei der Aufnahme der Anforderungen, entscheidet sich erstaunlich viel. Wer hier eine entscheidende Frage vergisst, merkt das oft erst Monate später, wenn die Korrektur ein Vielfaches an Zeit und Geld kostet. Denn der Kick-off ist der Moment, in dem zum ersten Mal sichtbar wird, dass alle Beteiligten glauben, dasselbe Projekt vor Augen zu haben, in Wahrheit aber jeder ein anderes. Die Aufgabe ist es, diese Erwartungen anzugleichen. Und genau hier kann eine Checkliste dafür sorgen, dass nicht die Tagesform des Projektleiters darüber entscheidet, ob die richtigen Fragen an alle beteiligten gestellt werden.

Und, damit hier gleich ein Missverständnis aus dem Weg geräumt wird: Wenn hier von Checklisten die Rede ist, sind nicht die gemeint, die man stumpf abhakt. Raum reserviert – Haken. Teilnehmer eingeladen – Haken. Hotel gebucht – Haken. Solche Listen sind nützlich, aber sie organisieren nur den Rahmen, nicht das Projekt selbst. Die Checkliste, um die es hier geht, ist eine andere Art. Sie fragt nicht „Teilnehmer eingeladen?“, sondern: Wer sitzt da eigentlich am Tisch, wieso genau der? Weshalb ist er dabei, was ist seine Rolle, und was muss er bis zum Termin erledigt haben, damit die Runde überhaupt etwas bringt? Es geht um Listen, die einen zwingen, sich mit dem Projekt auseinanderzusetzen, statt sich mit abgehakten Kästchen in Sicherheit zu wiegen.

Der Praxisnutzen ist nicht von der Hand zu weisen. Bei geplanter Einführung einer neuen Software klingt vieles im Kick-off zunächst klar: Die Software soll einen bestimmten Prozess unterstützen, ein paar Anwender werden geschult, Berechtigungskonzepte und Testszenarien definiert, fertig. Ein paar Punkte, schnell notiert. Doch kaum beginnt man, diese scheinbar simple Aufgabe mal ernsthaft zu durchdenken, schiebt sich hinter jedem der Punkte eine ganze Reihe von Fragen hervor. Fangen wir bei den Daten an: Wer pflegt sie eigentlich, dauerhaft, wenn das Projektteam längst weg ist? Und wer gibt sie überhaupt ein. Wer übernimmt die laufende Erfassung und die manuelle Nacharbeit, die fast immer anfällt, und ist dafür überhaupt Kapazität eingeplant? Wie läuft die Datenmigration aus den Altsystemen und was passiert mit dem Müll, der dort über Jahre gewachsen ist?

Auch damit ist man noch nicht am Ende, sondern wohl erst am Anfang. Klappt das Zusammenspiel mit den vor- und nachgelagerten Abteilungen nicht nur technisch, sondern auch organisatorisch – liefern die einen die Daten so, wie wir sie brauchen, und können die anderen mit unserem Ergebnis überhaupt weiterarbeiten? Bleiben wir im Standard der Software, oder bauen wir uns eine Sonderlocke, die uns bei jedem Update später wieder auf die Füße fällt? Welche Schnittstellen zu bestehenden Systemen braucht es, und wer ist dafür verantwortlich? Wie sind Benutzerrechte und Rollen definiert, wer darf was sehen, ändern, freigeben, löschen? Und – gern bis zuletzt vergessen – was soll hinten eigentlich herauskommen? Was ist der wirtschaftliche Vorteil? Welche Auswertungen, welche Reports braucht der Betrieb? Liefert das System diese auch und wer hat die geprüft? Wer übernimmt nach dem Go-live den Support? Sind Lizenzmodell und Datenschutz wirklich geklärt oder nur angenommen? Das sind keine Detailfragen für später. Genau an diesen Punkten, Eingabe, Rechte, Rollen, Schnittstellen, Standard oder Sonderlocke, Datenqualität und Reporting, geraten Projekte dann Monate später ins Stocken, während im Kick-off alle nur über die schönen neuen Funktionen gesprochen haben und nicht über die damit verbundenen Aufgaben und Zuständigkeiten.

Bei der Auswahl einer Maschine oder dem Retrofit geht es selten nur um die Maschine selbst. Passt sie überhaupt durch die Tür und auf das vorhandene Fundament? Welche Medien – Strom, Druckluft, Kühlung – müssen bereitgestellt werden? Wie sind Wartung, Ersatzteilversorgung und Reaktionszeiten des Herstellers geregelt? Welche Schulung brauchen die Bediener, und wie sieht es mit Arbeitssicherheit und CE-Konformität aus? Eine Maschine, die technisch perfekt ist, aber nicht in die Halle passt ist eine teure Fehlentscheidung.

Bei der Digitalisierung von Prozessen ist die wichtigste Frage oft die unbequemste: Ist der Prozess überhaupt sauber definiert, bevor man ihn versucht zu digitalisieren? Ein schlechter Prozess wird durch Digitalisierung nicht besser, sondern nur schneller schlecht. Die Checkliste fragt hier nach den beteiligten Rollen, nach Datenquellen und Datenqualität, nach Ausnahmen und Sonderfällen und danach, wie der alte und der neue Weg während der Übergangszeit nebeneinander funktionieren.

Dabei geht es auch um mehr als um den Prozess selbst. Ein Prozess ist nie neutral. Prozesse spiegeln die dahinterstehende organisatorische Ausrichtung wider. Deshalb lautet die eigentliche Frage oft nicht „Muss der Prozess geändert werden?“, sondern „Muss die Organisation hinter dem Prozess geändert werden?“ Bevor man vorschnell digitalisiert, lohnt es sich, das Bestehende ehrlich zu hinterfragen und zwar samt seiner inoffiziellen Unterschicht. In fast jedem Betrieb existiert ein mehr oder weniger großes Schatten-ERP aus Excel-Tabellen und Einzeldokumenten, in dem der Prozess in Wahrheit abläuft, vorbei am offiziellen System. Wer diese Schattenwelt nicht aufdeckt und vor allem versteht, gerade auch in der weitreichenden Konsequenz auf die Ki Thematik, digitalisiert am Ende nur die schöne Oberfläche und lässt den echten Prozess und das Verbesserungspotential unangetastet weiterlaufen. Vor allem sollte man sich darüber im Klaren sein, dass ein wirklich geänderter Prozess selten nur technisch bleibt. Er bringt fast immer organisatorische Veränderungen mit sich, andere Abläufe, andere Zuständigkeiten. Wer den Prozess anfasst, muss bereit sein, auch die Organisation anzufassen und alte Zöpfe abzuschneiden.

Wobei selbst das unter Umständen noch zu kurz greift, da ein Prozess niemals an der Grenze des Projekts wirklich endet. Auch dann nicht, wenn der Prozess innerhalb des eigenen Projektrahmens sauber definiert ist. Denn die Frage ist: sind es die vor- und nachgelagerten Prozesse ebenfalls? Allzu oft wird vorgelagert schlicht angenommen, dass die benötigten Informationen oder technischen Gegebenheiten „schon da sind“. Und nachgelagert wird ebenso selbstverständlich vorausgesetzt, dass die Ergebnisse irgendwo sinnvoll weiterverarbeitet werden. Beides sind Annahmen und Annahmen sind im Projektmanagement die teuersten Bausteine überhaupt. Eine gute Checkliste zwingt deshalb dazu, an beiden Schnittstellen konkret nachzufragen: Woher kommen die Eingangsdaten wirklich, in welcher Qualität und Form? Und ist im nachgelagerten Schritt die Weiterverarbeitung überhaupt gegeben?

Dahinter steht eine grundsätzliche Haltung: - Prozessdenken – Dieses muss immer die Gesamtheit des Prozesses in seiner Wertschöpfungskette betrachten, inklusive der Mitarbeiter, die ihn tragen. Ein Prozess ist vor allem kein isoliertes Kästchen im Projektplan, sondern ein Glied in einer Kette, die nur so stark ist wie ihr schwächstes Bindeglied. Wer nur den eigenen Abschnitt optimiert und Anfang wie Ende der Kette als gegeben hinnimmt, verlagert das Problem lediglich und damit meist zu den Kollegen davor oder dahinter, die es dann ausbaden müssen.

Ganz am Anfang steht aber noch etwas, das so selbstverständlich ist, dass es reihenweise übersprungen wird: das Ziel selbst. Ist überhaupt klar definiert, was am Ende des Projekts herauskommen soll? So klar, dass man es nachprüfen kann? Wir wollen effizienter und besser werden ist kein Ziel, sondern nur ein Wunsch. Ein Ziel erkennt man daran, dass am Ende Auftraggeber und Auftragnehmer zweifelsfrei sagen können, ob das Ziel erreicht wurde. Woran ist der Erfolg genau zu messen, was muss vorliegen, damit das Projekt als fertig gilt? Wo dieses gemeinsame Verständnis fehlt, arbeiten am Ende alle hart, aber nur leider jeder auf ein anderes, unausgesprochenes Ziel hin. Das merkt man erfahrungsgemäß genau dann, wenn es am teuersten ist, nämlich kurz vor der Abnahme oder im schlimmsten Fall direkt im oder nach Go-Live.

Ist das Ziel fest definiert, folgt auch sofort die nächste unbequeme Frage: Was bringt uns das eigentlich? Ein geänderter Prozess ist kein Selbstzweck. Bevor ein Projekt startet, muss geklärt sein, welchen konkreten Nutzen die Änderung für den Betrieb bringt. Schneller, günstiger, sicherer, weniger Fehler? Stehen Aufwand und Nutzen in einem Verhältnis, das den Aufwand rechtfertigt? Ein Projekt, das niemand in Nutzen und Kosten beziffern kann, ist kein Projekt, sondern nur eine teure Beschäftigung. An der Stelle nicht zu vergessen, dass die Kostenwahrheit weiter reicht, als viele im Moment vielleicht denken. Es geht nicht nur um das, was das Projekt kostet, sondern auch um das, was es später kostet, wenn man es jetzt zu klein, zu schnell oder gar nicht richtig macht. Diese Rechnung gehört auf den Tisch, bevor der erste Meilenstein überhaupt gesetzt wird. Das nicht als grobe Schätzung aus dem Bauch, sondern als ehrliche belastbare Grundlage, an der sich das ganze Vorhaben messen lassen muss.

Bevor man aber über Prozesse und Werkzeuge spricht, gehört für mich noch eine andere Frage ganz an den Anfang. Es ist die Frage nach den Menschen und ihren Ressourcen. Welche Qualifikation verlangt dieses Projekt tatsächlich und ist sie im Team vorhanden? Diese Eignungsprüfung steht am Beginn jeder ernsthaften Betrachtung und nicht am Ende. Stellt sich dabei heraus, dass Kompetenzen fehlen, müssen unter Umständen Externe eingebunden werden oder interne geschult. Das Einbinden von externen, sollte und muss dann vor allem früh genug erfolgen, damit sie das Projekt und die handelnden Personen darin kennenlernen, bevor es ernst wird. Ein Spezialist, der erst dazukommt, wenn die Hütte schon brennt, kann selten direkt löschen; er muss erst einmal verstehen, wo er überhaupt steht und wo der Brandherd entstanden ist.

Zu dieser ehrlichen Bestandsaufnahme gehört vor allem auch eine Frage, die man sich viel zu selten stellt: Von wo komme ich eigentlich her und wo will ich hin? Hier nicht nur als Frage auf der personellen Seite, sondern vor allem auch auf der technologischen und organisatorischen Basis. Wie vertraut ist mein Team überhaupt mit Projekten dieser Art und mit den Anforderungen, die solche Projekte stellen? Daneben mindestens genauso wichtig: habe ich meine Anforderungen und meine Erwartungshaltung wirklich klar genannt und auch vermittelt, oder setze ich stillschweigend voraus, dass die Teammitglieder es schon können und wissen? Das ist ein feiner, aber wesentlicher Unterschied. Eine Erwartung, die man nie ausgesprochen hat, ist keine Erwartung, sondern eine Enttäuschung mit unheimlichem Anlauf, und der geht mit tödlicher Sicherheit - immer - zulasten des Projekts.

Daneben gibt es da noch einen Risikofaktor, den kaum jemand wirklich berücksichtigt: Die Rede ist hier von der Distanz zwischen der Ausgangsbasis und dem Ziel. Man verliert oft die Ausgangsbasis zu leicht aus den Augen und konzentriert sich nur auf das Ziel. Dabei entscheidet gerade der Abstand zwischen beiden erheblich über den Aufwand und das Risiko. Ein Bild aus der IT macht es vielleicht deutlicher: Es ist ein gewaltiger Unterschied, ob du von Windows 10 auf Windows 11 wechselst, ob du von Windows 7 kommst und mehrere Versionssprünge auf einmal machst, oder ob du von Apple oder Linux kommst und nicht nur das System, sondern die ganze Denkweise wechselst. Das Ziel mag in allen drei Fällen gleich sein, aber die zurückzulegende Strecke, der Schulungsbedarf und die Zahl der Stolpersteine sind völlig verschieden. Im industriellen Umfeld ist es dasselbe: Ein Upgrade einer Maschine innerhalb derselben Generation ist ein anderes Projekt als der Sprung von einer handgeführten Anlage direkt zur vollautomatisierten, vernetzten Linie. Die technologische und organisatorische Reife der Ausgangsbasis ist, gemessen an der Zielsituation, ein eigener Risikofaktor. Wer sie nicht ehrlich einschätzt, plant nicht ein Projekt, sondern mehrere übereinander und merkt es zu spät. Dass diese Reife messbar ist, zeigt der acatech Industrie 4.0 Maturity Index, ein sechsstufiges Reifegradmodell, das den digitalen Reifegrad eines Betriebs nicht nur an der Technik festmacht, sondern ausdrücklich auch an Organisationsstruktur und Kultur. Genau darum geht es hier: Die Ausgangsbasis ehrlich einzuordnen, bevor man den Sprung plant und nicht anzunehmen, man stünde schon weiter, als man tatsächlich ist."

Gerade auch innerhalb digitaler Projekte reicht der Blick auf das eigene Team nicht aus. Die Ressourcenfrage muss auch mit den beteiligten Dienstleistern, wie etwa dem ERP- oder MES-Anbieter, sauber geklärt werden. Es nützt nichts, intern zehnmal schneller arbeiten zu wollen, als der Dienstleister Kapazitäten bereitstellen kann. Das eigene Tempo ist wertlos, wenn es am Flaschenhals des Dienstleisters zerbricht. Deshalb gehören Ressourcen und Abhängigkeiten vollständig auf den Tisch, bevor das Projekt Fahrt aufnimmt. Die internen genauso wie die externen, und vor allem die zwischen beiden. Auch hat dieser Flaschenhals zwei Seiten. Häufig ist der umgekehrte Fall, der Dienstleister übernimmt die Projektplanung und setzt dabei stillschweigend voraus, dass auf Kundenseite das nötige Wissen, die Kapazität und die Entscheidungsbereitschaft vorhanden sind, während der Kunde umgekehrt annimmt, der Dienstleister macht das schon. Beide bauen ihren Plan auf einer ungeprüften Annahme über den jeweils anderen. Wenn dann klar wird, dass der Kunde die zugelieferten Aufgaben gar nicht in der erwarteten Zeit oder Qualität stemmen kann, steht der schönste Projektplan des Dienstleisters auf Sand. Deshalb muss auch diese Erwartung ausgesprochen werden: Wer liefert wem was zu, bis wann, und mit welcher Kompetenz im Rücken? Und noch etwas aus persönlicher Erfahrung, für alle mit ERP-Projekten: Glaub keiner Zahl und keiner Auswertung, die dir ein ERP-Dienstleister als wahr verkauft, ohne sie selbst geprüft zu haben.

Bei IoT-Projekten kommt zusätzlich eine dritte Partei mit ins Spiel, die gern übersehen wird. Der Anlagenhersteller. Wer eine Maschine digital anbinden will, ist auf ihn meist angewiesen. Auch der braucht Kapazität dafür. Vor allem aber muss er der technischen Anbindung überhaupt positiv gegenüberstehen. An der Stelle sollte man nicht von einer Selbstverständlichkeit durch den Anlagenhersteller ausgehen. Viele öffnen ihre Anlagen nur ungern, sei es aus Sorge um Gewährleistung, um das eigene Know-how zu schützen oder schlicht, weil sie keinen Vorteil darin sehen. Man darf hier nicht davon ausgehen, dass er anbinden muss, sondern kann nur darauf hoffen, dass er anbinden will und kann. Selbst wenn er will, ist die Kostenfrage damit ja auch noch nicht geklärt. Solche Anbindungen, Schnittstellen, Dokumentation der Datenautobahn sowie die Freigaben der Datenmodelle kosten Geld. Es sollte daher geklärt sein, bevor man sich auf den guten Willen des Herstellers verlässt oder glaubt er muss.

Gleiches gilt für die fachlichen und technischen Grundlagen. Es ergibt keinen Sinn, über High-End-Technologien zu sprechen, wenn die dafür nötigen Grundvoraussetzungen noch gar nicht vorhanden sind. Erst der Unterbau, dann das, was darauf aufsetzt. Ohne dieses Fundament lässt sich auch nicht sinnvoll testen: Ein valider Test braucht eine valide Grundlage. Und Daten allein sind kein Ersatz dafür. Daten nur um der Daten willen zu erzeugen, schafft die Illusion von Fortschritt, ohne die eigentliche Frage zu beantworten, ob das System unter realen Bedingungen dafür ausgelegt ist. Oder anders gesagt: Niemand baut zuerst das Dach, damit es beim Ausschachten des Kellers nicht hereinregnet.

Ebenfalls ist die zeitliche Dimension ein nicht zu unterschätzender Einflussfaktor: Ein Prozess muss durchgängig stabil am Laufen gehalten werden. Es ist wenig hilfreich, ein Projekt anzufangen, Leute einzuweisen und anschließend vier Monate nichts mehr zu tun. Was in dieser Pause an mühsam aufgebautem Wissen verloren geht, muss danach noch einmal aufgebaut werden. Gerade im ERP-Umfeld kann man die Mitarbeiter nach einer solchen Lücke oft gleich komplett neu schulen. Durchgängigkeit ist deshalb kein Komfort, sondern eine Voraussetzung dafür, dass das einmal Gelernte und Eingeführte überhaupt Wirkung entfaltet.

An dieser Stelle lohnt eine Anmerkung, gerade weil derzeit alle Welt darauf hofft: Künstliche Intelligenz macht das nicht automatisch besser. Man könnte meinen, bzw. wird einem verkauft, ein KI-System ließe sich auf einen Prozess ansetzen, um die Lücken, Schnittstellen und Sonderfälle schon zu finden. In der Praxis stößt das gerade am Anfang an eine knallharte Grenze. KI kann hervorragend Muster in vorhandenen Daten erkennen, Dokumente zusammenfassen oder Vorschläge generieren. Was sie zu Beginn eines Projekts aber nicht liefert, ist die menschliche Klarheit darüber, wie das Zusammenspiel zwischen den technischen und den menschlichen Akteuren tatsächlich aussieht und wer wann was wirklich tut. Das, was zwischen den Zeilen vereinbart ist, wo die informellen Wege verlaufen und wo eine Annahme nur deshalb nie hinterfragt wurde, weil sie allen als selbstverständlich erschien. Ein Beispiel: Bittet man eine KI früh im Projekt, den Soll-Prozess für eine ERP-Einführung zu beschreiben, liefert sie einen plausibel klingenden, sauber strukturierten Ablauf. Nur beschreibt dieser Ablauf die idealisierte und standardisierte Lehrbuchversion. Nicht die Realität, in der die Kollegin aus dem Einkauf eine bestimmte Information seit Jahren per Zuruf weitergibt und der vorgelagerte Lieferant ein Datenfeld liefert, das offiziell gar nicht vorgesehen ist. Genau diese Brüche zwischen Technik und Mensch muss man zu Beginn selbst sichtbar machen. Die KI kann dabei unterstützen, sobald Klarheit herrscht, kann sie aber nicht ersetzen, solange sie fehlt.

Noch heikler wird es, wenn KI nicht nur ein Werkzeug im Projekt ist, sondern das Projekt selbst. Das Ziel also lautet, KI einzuführen. Denn dann holt man sich mit der KI gleich eine ganze Kaskade weiterer Projekte ins Haus: Datenanbindung, das Herstellen sauberer Beziehungen zwischen den Daten, deren Plausibilisierung. All das wandert automatisch mit nach oben. Was als ein Projekt geplant war, ist in Wahrheit ein mehrstufiges Vorhaben, bei dem eine Stufe auf der anderen steht. Und am Ende hat man ein Team, das aus der Validierung von Daten gar nicht mehr herauskommt. Gerade im ERP-Umfeld bedeutet jede Anpassung, den KI-Output erneut zu prüfen. Denn was die KI ausgibt, muss stimmen, und ob es stimmt, weiß nur, wer es kontrolliert. Das sollte, auch hier aus persönlicher Erfahrung, nicht der Dienstleister selbst sein. Aber das sagte ich ja schon.

Vor allem aber muss man sich über eine Sache wirklich im Klaren sein: KI kann eine Verbesserung auf einen bestehenden Prozess bringen. Sie kann aber nichts verbessern, was im Fundament gar nicht existiert. Wenn ein Prozess schon in seiner operativen Betrachtung – also ganz ohne KI – nie zu einer Verbesserung geführt hat, dann wird es kritisch. Die verbreitete Annahme, KI macht unseren Prozess um zehn Prozent besser, ist dann schlicht falsch. Denn die Wahrheit ist unbequem: Existiert der Prozess heute zu neunzig Prozent gar nicht sauber und digital, dann wirken zehn Prozent KI-Verbesserung eben nur auf diese magere Grundlage und aus der vollmundigen Verbesserung wird real gerade einmal ein Prozent. Wären der Prozess und die Daten dagegen sauber vorhanden und gepflegt von Mitarbeitern mit ausreichendem Prozessverständnis, läge der weitaus größere Hebel längst genutzt vor der KI. Die KI bekommt am Ende die Lorbeeren für eine Hausaufgabe, die längst hätte gemacht sein müssen.

Das ist auch der Punkt, den man nie vergessen darf: KI braucht jemanden, der ihr beibringt zu denken. Nur Daten in einen Topf zu werfen und zu hoffen, dass schon etwas Brauchbares herauskommt – etwas, das dann auch noch jemand versteht –, das ist, als würde man eine Buchstabensuppe aus der Schüssel direkt auf den Teller knallen in der Erwartung, dass sich daraus die Weisheit der Welt in leserlicher Form abzeichnet. Wer glaubt, damit könne man Chaos nicht noch vergrößern, der irrt gewaltig. Und wer obendrein das Vertrauen der Mitarbeiter in KI leichtfertig aufs Spiel setzt, weil das erste, was sie sehen, völlig unbrauchbar ist, der hat genau diese Buchstabensuppe im eigenen Kopf.

Und damit gehört ans Ende dieses Abschnitts eine ehrliche Warnung. Der gefährlichste Grund, KI einzusetzen, ist der, der heute am häufigsten vorkommt: der Hype. KI, weil alle KI machen. KI, um vor dem Vorstand, dem Markt oder den Mitbewerbern zu zeigen, dass man vorne mit dabei ist. Das ist die exakte Umkehrung von allem, was hier steht. Nicht das Projekt bestimmt das Werkzeug, sondern das Werkzeug ist gesetzt, und man sucht sich nachträglich ein Projekt dazu. Das Pferd wird von hinten aufgezäumt, und am Ende steht kein gelöstes Problem, sondern eine teuer bezahlte Ignoranz. Teuer, weil sie viel Geld und Vertrauen kostet. Ignoranz, weil man es hätte wissen können und weder wahrhaben noch wissen wollte.

Damit das um Gottes willen nicht falsch verstanden wird: Das ist kein Plädoyer gegen KI. Genau das Gegenteil ist hier der Fall. Ich bin überzeugt, das Unternehmen, die in den nächsten drei bis fünf Jahren keine KI eingeführt haben, es aller Voraussicht nach schwerer haben werden. Die Dringlichkeit ist also real und wer sie ignoriert, macht denselben Fehler wie der Hype-Getriebene, halt nur mit umgekehrtem Vorzeichen. Der Punkt ist ein anderer: Die Versäumnisse der Vergangenheit einfach zu ignorieren macht es nicht besser. Wer über Jahre sein Prozess-, Daten- und Maschinenpark hat verrotten lassen, holt das nicht dadurch auf, dass er jetzt hektisch KI daraufsetzt. Das Wort „verrotten" ist hart, aber ehrlich. Ehrlich, weil genau vor dieser Entwicklung seit vielen Jahren beständig gewarnt wurde. Dass der Mittelstand die Digitalisierung nicht verpassen darf, ist kein neuer Gedanke und schon gar kein Geheimwissen: Der Weckruf an den Mittelstand erschallt, wie es in einer Fachpublikation treffend hieß, seit Jahren „wie Donnerhall" auf Tagungen und Kongressen; ganze Studienreihen von Bitkom, McKinsey oder EY, unzählige Beiträge in den Wirtschaftsmedien und dutzende Fachbücher haben das Thema über Jahre von allen Seiten beleuchtet. McKinsey allein bezifferte das ungenutzte Wertschöpfungspotenzial des deutschen Mittelstands auf über 100 Milliarden Euro und stellte zugleich fest, dass nur jeder zweite Betrieb die Digitalisierung überhaupt als Chance begreift. Wer heute vom Nachholbedarf bei Industrie 4.0 überrascht ist und zugleich meint, KI werde diesen Schritt einfach überspringen und ihn ohne dieses Fundament direkt ins nächste Level heben, hat etwas Grundsätzliches nicht verstanden. Denn das eine setzt das andere voraus, technisch wie auch beim Personal. Industrie 4.0 war nie nur Technik: In ihrem Kern stehen vernetzte Anlagen und durchgängig verfügbare, saubere Daten. Genau das ist heute die Grundnahrung jeder KI. Ohne diese Basis hat eine KI schlicht nichts, worauf sie aufsetzen könnte. Und ebenso wichtig: Die Menschen, die einen Industrie-4.0-Weg gegangen sind, haben dabei ein Grundverständnis für datengetriebenes, vernetztes Arbeiten mitgenommen. Ein Verständnis, das man nicht per KI nachrüsten kann. Wer diese Stufe überspringt, steht am Ende genau wieder an der alten Schwelle: Woher komme ich, und wo will ich wirklich hin? Fairerweise muss man dazusagen: Gerade dem Mittelstand und vor allen den Gießereien fehlten oft schlicht die finanziellen Mittel und auch Möglichkeiten, all das rechtzeitig anzugehen. Doch was man nicht anfängt, wird eben auch nie fertig und hinter dem Zögern steckt am Ende oft nicht nur das fehlende Geld, sondern schlicht auch manchmal das Nichtwissen, das über die Jahre in Handlungsunfähigkeit übergegangen ist. Beides ist wahr und muss zusammen gedacht werden: KI kommt, und man sollte sich darauf vorbereiten. Aber die Vorbereitung besteht zuerst darin, die Hausaufgaben zu machen, die man ohnehin schon hätte machen müssen. Dringlichkeit ist ein Grund, endlich anzufangen, kein Grund, das Fundament zu überspringen.

Interessant ist, dass diese Getriebenheit meistens von oben kommt. Aus einer Initiative, die aus Prestige angestoßen wurde. Ausbaden muss sie am Ende oft der Projekt- oder Abteilungsleiter. Genau hier zeigt sich, was Führung wirklich bedeutet, und es ist unbequem: Es reicht nicht, nur nach unten für Klarheit zu sorgen und ein einmal beschlossenes Projekt konsequent umzusetzen. Zur Führung gehört auch, nach oben das offene Wort zu wagen und sachlich zu sagen: Das ist aus meiner Sicht nicht der richtige Grund, wir sind an dieser Stelle noch nicht so weit und so wird es teuer. Das ist kein Widerspruch zu der Konsequenz, mit der man ein beschlossenes Projekt durchzieht, sondern die andere Hälfte derselben Haltung. Wer nach unten führt, aber nach oben schweigt, obwohl er es besser weiß, nimmt ein absehbares Risiko billigend in Kauf. Dann ist die teuer bezahlte Ignoranz nicht mehr nur die des Managements, sondern auch die eigene. Rückgrat kennt an diese Stelle beide Richtungen, oder es ist keins.

Das Verhältnis von KI und Projektmanagement verdient dabei eine eigene, ausführliche Betrachtung, und es wird späterer dazu einen eigenen Artikel geben. Für hier reicht die Erkenntnis: Das das menschliche Durchdenken eines Prozesses am Projektanfang unersetzlich ist – ganz gleich, wie leistungsfähig die eingesetzten Werkzeuge inzwischen heute auch sind.

Diese Erkenntnis ist nicht nur Erfahrungswissen, sie lässt sich mit Zahlen unterlegen. Die Analysten von Gartner prognostizieren, dass Organisationen bis Ende 2026 rund 60 Prozent ihrer KI-Projekte aufgeben werden, sofern diese nicht auf KI-tauglichen, sauber aufbereiteten Daten beruhen – nicht, weil die Algorithmen schlecht wären, sondern weil die Datengrundlage darunter es ist. Branchenübergreifende Auswertungen kommen zu ähnlich ernüchternden Ergebnissen: Je nach Quelle scheitern 70 bis über 80 Prozent der KI-Vorhaben an datenbezogenen Problemen, und Datenfachleute verbringen geschätzt 60 bis 80 Prozent ihrer Zeit nicht mit der eigentlichen Modellentwicklung, sondern mit dem Aufräumen von Daten. Dahinter steht ein altes Prinzip der Informatik, das durch KI nur an Schärfe gewonnen hat: „Garbage in, garbage out.“ Wer einen unklaren Prozess und schlechte Daten in ein KI-System gibt, bekommt keine Klärung zurück, sondern ein schnelles und überzeugendes formuliertes Durcheinander. Genau deshalb ist die unbequeme menschliche Vorarbeit – Prozess sauber definieren, Schnittstellen klären, Datenqualität sicherstellen – kein Gegenspieler der KI, sondern ihre unmittelbare Voraussetzung.

Mich begleitet dieses Thema in den letzten Jahren sehr intensiv. Irgendwann stand für mich dabei die eigentlich entscheidende Frage im Raum: Wie ermittelt man überhaupt, ob ein Unternehmen – oder ein einzelner Prozess – „KI-Ready" ist? Ganz neu ist diese Art zu fragen dabei nicht. Schon beim Thema Industrie 4.0, als an KI noch niemand ernsthaft dachte, hat sich ja selbst auch die Gießereibranche mit der Reifegradfrage beschäftigt und im Kontext von Industrie 4.0 einen entsprechenden Fragenkatalog erarbeiten lassen. Genau dieselbe Grundfrage kommt beim Thema KI heute wieder hoch, nur eine oder zwei Stufen höher: Trägt die heutige Datenlage überhaupt das Vorhaben, das man plant? An genau dieser Frage arbeite ich an anderer Stelle gerade selbst, dazu später mal mehr. Für diesen Artikel genügt der Kern: Bevor man fragt, was die KI kann, muss man ehrlich beantworten, ob der eigene Boden für sie überhaupt bereitet ist.

Wie sehr dieser Boden trägt oder eben nicht, wird sich in Zukunft bei vielen Projekten recht schnell zeigen. Bei der Einführung neuer ERP-Systeme etwa potenziert sich all das. Hier geht es um Stammdaten, um die Frage „Standard anpassen oder Prozess anpassen?", um Berechtigungskonzepte, Testphasen, Key-User, Schulungsumfänge und einen realistischen Go-live-Termin. ERP-Projekte scheitern selten an der Software – sie scheitern an unausgesprochenen Annahmen, die nie auf einer Liste standen.

Und beim Neubau einer Produktionsanlage schließlich verbinden sich technische, bauliche, logistische und regulatorische Themen zu einem hochkomplexen Geflecht: Genehmigungen, Materialfluss, Personalbedarf, Anbindung an Logistik und Infrastruktur, Inbetriebnahme, Probebetrieb, Brandschutz, Umweltauflagen. Niemand hat das alles im Kopf und niemand sollte so tun, als ob.

Das ist auch der Kern: Erfahrene Projektleiter haben selten alles im Kopf. Sie wissen vielmehr, dass das menschliche Gedächtnis unter Druck unzuverlässig ist. Im Stress eines Kick-offs, zwischen drängenden Terminen des Tages und vielen Gesprächspartnern, fällt selbst dem Routinier manchmal etwas Wichtiges unter den Tisch. Wer seit zwanzig Jahren Projekte leitet, vertraut deshalb nicht nur auf sein Gedächtnis, sondern auf sein System. Die Checkliste ist dabei in ihrer Form das wohl einfachste System von allen. Bemerkenswert ist daneben aber auch, was empirische Untersuchungen als die wichtigsten Erfolgsfaktoren von Projekten ausweisen. Dabei steht ganz oben nicht Technik oder Budget, sondern das frühe Einbinden der Anwender, die Unterstützung durch das Management sowie klare Anforderungen, gefolgt von realistischen Erwartungen, kompetenten Mitarbeitern und eindeutigen Zuständigkeiten. Es sind also fast durchweg die menschlichen und vor allem die Klarheits-Faktoren, die über Erfolg oder Misserfolg entscheiden. Also genau jene Dinge, die eine gute Checkliste am Anfang abfragt und die im Eifer des Aufbruchs so gern übersprungen werden.

Dabei gilt eine wichtige Einschränkung: Eine gute Checkliste ersetzt kein Denken. Sie nimmt einem nicht die Entscheidung ab, sie analysiert keine Risiken und sie versteht den Kontext eines Projekts nicht. Was sie leistet, ist etwas anderes und ebenso Wertvolles: Sie verhindert zuverlässig, dass offensichtliche Dinge übersehen werden. Sie sorgt dafür, dass die Energie des Projektleiters für die wirklich schwierigen Fragen frei bleibt, statt an vermeidbaren Pannen verschwendet zu werden.

Wie sehr diese Reihenfolge – erst denken, dann handeln – gerade am Anfang zählt, macht ein alltägliches Beispiel klarer. Am Anfang eines Projekts entsteht oft die Aufgabe, einen Bericht für eine fundierte Entscheidung zu erstellen – etwas Vorzeigbares, um dem Management oder den Entscheidern den Sinn und den wirtschaftlichen Nutzen des Vorhabens zu verdeutlichen. Diese Mühe kann man sich an dieser Stelle getrost sparen. Denn diesen Nutzen kann man gar nicht überzeugend darstellen, solange man ihn nicht selbst durchdacht und die Lage vernünftig eingeschätzt hat. Ohne die richtigen Fragen kommen auch nicht die Antworten, die überhaupt berichtswürdig wären. Ein Bericht oder ggf. eine Präsentation ist immer nur so gut wie das Denken, das ihm vorausgeht. Wer dabei Folien oder Tabellen füllt, bevor die zentralen Fragen gestellt und geklärt sind, präsentiert am Ende nur die eigene Ahnungslosigkeit in einer schöneren Form. Erst kommen die unbequemen Fragen, dann die Antworten. Wenn dann die Antworten stehen, schreibt sich der Bericht fast von selbst, weil er dann einen substanziellen Inhalt hat. Die Reihenfolge ist entscheidend: Erst denken, dann ausarbeiten bzw. gestalten. Nicht umgekehrt. Und heute lässt sich dasselbe Prinzip noch eindrucksvoller vorführen: Bitte einmal eine KI, dir eine Präsentation oder einen Bericht zu bauen, ohne ihr vorher ausreichende Grundlagen mitgegeben zu haben. Was zurückkommt, ist die gleiche Ahnungslosigkeit in schöner Form, nur schneller und in noch glänzenderer Optik. Die KI füllt bereitwillig jede Lücke mit plausibel klingendem Nichts. Der Fehler liegt dann nicht bei ihr, sondern in der Erwartungshaltung: Wer Substanz erwartet, wo er keine geliefert hat, bekommt eine schöne Hülle und verwechselt sie mit einem Ergebnis. Auch hier gilt, was für die ganze Vorarbeit gilt, erst das Denken, dann das Werkzeug, ganz gleich, wie mächtig das Werkzeug inzwischen ist. Und genau darum geht es, nicht um die Checkliste als solche, sondern um das, was hinter ihr steht: ein System, das dieses logische Denken erzwingt, bevor irgendetwas gebaut, präsentiert oder automatisiert wird. Ob Liste, Board oder ein anderes Format, ist dabei zweitrangig. Wichtig ist nur, dass man sich nicht allein auf das eigene Gedächtnis verlässt.

Die Excel-Falle – wenn das Werkzeug das Projekt bestimmt

Es gibt einen Reflex, der in erstaunlich vielen Betrieben zu beobachten ist: Sobald irgendetwas organisiert, geplant oder verfolgt werden muss, öffnet sich wie von selbst eine leere Tabelle. Neues Projekt? Excel. Maßnahmenliste? Excel. Risikomanagement? Excel. Terminplanung, Budget, Aufgabenverteilung, Statusberichte? Excel, Excel, Excel und noch einmal Excel. Für manche Menschen ist Excel nicht ein Werkzeug unter vielen, sondern die Antwort auf jede denkbare Frage. Manchmal auch, bevor die Frage überhaupt gestellt wurde.

Um zu verstehen, warum das ein Problem ist, hilft ein kleines Gedankenspiel. Stell dir vor, du musst von Bremen nach Stuttgart reisen. Zur Auswahl stehen ein Panzer, ein Sportwagen, ein Reisebus und die Bahn.

Wenn Geschwindigkeit das wichtigste Ziel ist, greift wohl jeder spontan zum Sportwagen. Schnell, wendig, kraftvoll und damit die naheliegende Wahl. Doch was ist, wenn sich die Anforderung ändert, und du während der Reise Berichte schreiben musst, E-Mails bearbeiten und an Besprechungen teilnehmen. Plötzlich sieht die Entscheidung völlig anders aus. Im Sportwagen kannst du weder tippen noch telefonieren, geschweige in Ruhe nachdenken. Die Bahn dagegen, eben noch scheinbar zu langsam, wird zur besseren Wahl. Du kommst an, und die Reisezeit war zugleich Arbeitszeit. Der Panzer wäre robust, aber absurd unpraktisch; der Reisebus bequem, aber unflexibel. Das vermeintlich beste Werkzeug hängt also nicht an seinen Eigenschaften, sondern an den tatsächlichen Anforderungen der Aufgabe.

Übertragen auf das Projektmanagement heißt das: Auch Excel ist ein Fahrzeug und sicherlich kein schlechtes. Aber es ist nicht für jede Strecke das richtige. Ein paar Grundwahrheiten helfen, das vernünftig einzuordnen:

• Jedes Werkzeug besitzt Stärken und Schwächen. Es gibt kein universelles Werkzeug, das alles gleich gut kann, was prinzipiell auch für die Mitglieder eines Projektteams gilt.

• Excel ist ein hervorragendes Werkzeug – flexibel, schnell verfügbar und von fast allen beherrscht. Excel ist aber damit nicht automatisch das richtige Werkzeug für das Projekt bzw. das Projektmanagement. Flexibilität ist hier nicht dasselbe wie Eignung.

• Kleine überschaubare Projekte lassen sich oft sehr gut mit Excel organisieren. Eine Aufgabenliste, ein einfacher Terminplan, ein kleines Budget brauchen keine teure Spezialsoftware.

• Große oder komplexe Projekte benötigen dagegen oft spezialisierte Werkzeuge, die für Aufgabenmanagement, Dokumentation, Zusammenarbeit im Team oder professionelle Terminplanung mit Abhängigkeiten und Ressourcen ausgelegt sind.

Daraus folgt eine Kernaussage, die man sich über den Schreibtisch hängen sollte: Das Projekt bestimmt durch die Anforderungen das Werkzeug und nicht die Vorlieben des jeweiligen Projektleiters. Die Fachwelt hat, wie kann es auch anders sein, für dieses Zuschneiden einen eigenen Begriff: Tailoring. Daud Alam und Uwe Gühl beschreiben in ihrem Praxis-Leitfaden, dass Projekte sich in Zielen, Größe, Zeitrahmen und Umfang so stark unterscheiden, dass Vorgehensmodelle und Werkzeuge projektspezifisch angepasst werden müssen, statt ein Standardvorgehen stur über alles zu stülpen. Nichts anderes ist mit dem Satz oben gemeint, nur ohne Fachwort.

Und, um einem naheliegenden Ausweichmanöver gleich zuvorzukommen: Die Rettung ist, nach meiner Meinung, auch nicht das nächste Microsoft-Bordmittel. Ich habe es mit Planner, OneNote und Loop versucht und aus meiner Erfahrung sind auch sie keine Projektlösung. Sie sind schnell zur Hand und wirken praktisch, aber genau an dem, worauf es in einem größeren Projekt ankommt, belastbare Terminierung mit Abhängigkeiten, saubere Aufgabenzuweisung, echte Dokumentenlenkung und aussagekräftiges Reporting, scheitern sie für mich schon im Ansatz. Sie sind, wenn man so will, nur Excels jüngere Geschwister: bequem, vertraut und trotzdem für den Zweck nicht gemacht. Es geht eben nicht darum, das bequemste Werkzeug zu nehmen, das man ohnehin schon hat, sondern das, was das Projekt verlangt.

Hier liegt zugleich auch noch eine andere Falle. Viele Projektleiter versuchen, ein Projekt so zuzuschneiden, dass es zu ihren eigenen Fähigkeiten passt. Wer Excel liebt, formt das Projekt so lange, bis es in eine Tabelle passt. Wer ungern delegiert, definiert den Umfang so, dass er alles allein schafft. Wer eine bestimmte Methode beherrscht, presst jedes Vorhaben in dieses Schema. Das fühlt sich angenehm an und es passt schließlich zu den eigenen Stärken. Nur hat das am Ende mit den Anforderungen des Projekts meist nicht mehr viel zu tun.

Dass dieser Excel-Reflex nicht harmlos ist, zeigt auch hier die Forschung erstaunlich deutlich. Der amerikanische Wirtschaftsinformatiker Raymond Panko hat über Jahre Feldstudien zu Tabellenkalkulationen ausgewertet; quer durch diese Untersuchungen enthielt die überwiegende Mehrheit der geprüften operativen Tabellen mindestens einen Fehler. In mehreren Auswertungen lag dieser Anteil bei rund 90 Prozent und in einzelnen Stichproben aus dem Finanzbereich sogar bei 100 Prozent. Dabei ist der Grund nicht mangelnde Sorgfalt, sondern menschliche Normalität: Die Fehlerrate beim Erstellen von Tabellenformeln liegt in derselben Größenordnung wie beim Schreiben von Programmcode, nämlich bei einigen Prozent pro Zelle. Nur durchläuft Software in der Regel umfangreiche Tests, bevor sie produktiv geht, während Tabellen meist direkt nach dem ersten Entwurf verwendet werden. Weil sich dadurch aber Fehler über verkettete Berechnungen fortpflanzen, steigt die Wahrscheinlichkeit eines falschen Endergebnisses mit jeder zusätzlichen abhängigen Zelle. Eine kleine Aufgabenliste verträgt das problemlos, ein komplexes Projektbudget oder ein Risikomodell, mit hunderten von verknüpften Formeln, wird so jedoch zur tickenden Zeitbombe.

Umgekehrt belegt die Projektmanagement-Forschung den positiven Zusammenhang: Die angemessene Auswahl und Nutzung von Werkzeugen und Methoden, abgestimmt auf die jeweilige Projektsituation, auf Phase, Größe, Art und strategische Ausrichtung des Vorhabens, wirkt sich nachweislich positiv auf den Projekterfolg aus. Es geht also nicht darum, Excel grundsätzlich zu verteufeln, sondern um eine schlichte, empirisch gestützte Einsicht: Das passende Werkzeug für die jeweilige Aufgabe zu wählen ist kein Stilfrage, sondern ein messbarer Erfolgsfaktor.

In Wirklichkeit muss es also umgekehrt laufen: Nicht das Projekt passt sich dem Projektleiter an, sondern der Projektleiter passt sich den Anforderungen des Projekts an. Wenn sich dabei zeigt das auch notwendige Kompetenzen fehlen, ist die richtige Reaktion nicht, das Problem kleinzureden, sondern Unterstützung zu holen.

Dieses Zurückstoßen kommt dann selten höflich. Es kommt als überschrittener Termin, als gesprengtes Budget, als Tabelle, die niemand mehr versteht oder ein Team, das aneinander vorbeiarbeitet. Das Projekt nimmt sich am Ende den Raum, den man ihm eventuell anfangs verweigert hat. Wenn du erst dann feststellst, dass dir Wissen oder Fähigkeiten fehlen, dann such dir Menschen, die diese Lücke schließen, denn alles andere wird früher oder später sehr teuer oder Zeitintensiv.

Und wenn das hier alles gar nicht beherzigt wird? Auch gut. Nimand muss Angst haben, etwas Wichtiges zu vergessen. Niemand muss diesen Zeilen glauben. Man muss sich nur einer Sache bewusst sein: Nur weil man die Augen zumacht, sind die Dinge nicht weg. Das Projekt wird die Punkte einfordern, die es zur Erfüllung des Ziels benötigt. Alle, ohne Ausnahme. Die Frage ist nur, wann. Wer früh hinschaut und reagiert, kommt oft mit einem Pflaster davon. Später wird meistens mit sechs bis zwölf Stichen genäht.

Genau deshalb ist es klüger, den Dingen früh ins Auge zu sehen, statt sie wegzuschieben. Voraussetzung dafür ist allerdings eine Portion Demut und eine realistische Selbsteinschätzung. Man muss sich eingestehen können, dass man selbst die Weisheit nicht mit dem Löffel gefressen hat. Gerade erfahrene Projektleiter laufen Gefahr, ihre Routine mit Allwissenheit zu verwechseln. Es lohnt sich, hier eine kleine Rangordnung im Kopf zu behalten: Annahmen über das Vorhandensein von Technik, von Software, von den nötigen menschlichen Fähigkeiten ersetzen kein Wissen. Und selbst gesichertes Wissen ersetzt noch nicht die Realität. Man nehme das Beispiel einer simplen Schnittstelle:

• „Ich nehme an, dass die Schnittstelle existiert."

• „Ich weiß, dass sie spezifiziert wurde."

• „Ich habe gesehen, dass sie tatsächlich funktioniert."

Zwischen diesen drei Sätzen liegen Welten und genau in diesen Welten verbergen sich die meisten Projektrisiken. Wer Annahmen für Wissen hält und Wissen für Realität, baut sein Projekt auf einem Fundament, das er nie geprüft hat. Auch hier wiederrum ist es die Fachliteratur, die dazu rät an der Stelle genauer hinzusehen: Gerade wenn eine Aufgabe besonders klar und einfach erscheint, werden gern implizite Annahmen getroffen, die aber genau überprüft gehören. Idealerweise handfest an Szenarien, Modellen oder einem Prototyp, statt sie einfach für gesichert zu halten.

Auch an dieser Stelle, weil das hier sonst klingt, als würde jemand mit dem Finger auf alle anderen zeigen. Auf die Berater, die internen und externen Klugscheißer, die schlecht besetzten Rollen, gehört eine ehrliche Selbstauskunft dazu: Ich nehme mich von all dem Geschriebenen nicht aus. Ich habe in etlichen Jahren selbst nicht immer alle Projekte hinbekommen. Auch ich habe Annahmen für Wissen gehalten, mich auf Zusagen verlassen, die keine waren, und Warnzeichen übersehen, die im Rückblick mehr als überdeutlich waren.

Ich erinnere mich noch genau, wie ich 2008 – im Zuge der Anpassung einer Sandaufbereitung – nachts um zwei wach wurde und im Jogginganzug zur Firma fuhr, nur um die Stichmaße des Fundaments selbst nachzumessen. Einfach, weil ich echt Muffe hatte, mich auf das - passt schon - der anderen zu verlassen. Annahme ist eben nicht Wissen. Ehrlicherweise hätte ich in diesem Fall weiterschlafen können, es passte. Aber die Ruhe, es mit eigenen Augen gesehen zu haben, war den nächtlichen Ausflug allemal wert. Und genau darum geht es. Die aufgeschlagenen Knie und blutigen Nasen, von denen am Anfang die Rede war, sind keine Erfindung, sie sind echt. Genau daher kommt auch dieser Text. Nicht aus der Sicht von jemandem, der alles richtig macht, sondern von jemandem, der oft genug der Klügere im Raum sein wollte und dabei gelernt hat, dass der eigentliche Fortschritt genau dann beginnt, wenn man aufhört, sich für den Klügsten zu halten. Denn der gefährlichste und oft größte Risikofaktor im Projekt sitzt manchmal auf dem eigenen Stuhl und die erste Ehrlichkeit, die man aufbringen muss, ist die sich selbst gegenüber.

.

Damit klärt sich auch ein verbreitetes Missverständnis über gute Projektleitung. Gute Projektleiter müssen nicht alles können. Niemand beherrscht zugleich ERP-Architektur, Bauplanung, Datenschutzrecht, Maschinenbau und Change-Management Arbeitsschutz und IT-Sicherheit. Was gute Projektleiter aber auszeichnet, ist die Fähigkeit, präzise zu erkennen, was sie nicht können und rechtzeitig die - richtigen Menschen - ins Team zu holen. Stärke zeigt sich hier nicht im Alleskönnen, sondern im ehrlichen Umgang mit den eigenen Grenzen. Und genau das beginnt schon bei der scheinbar harmlosen Frage, ob für dieses Projekt wirklich eine Excel-Tabelle das richtige Fahrzeug ist.

Womit wir bei einem Muster wären, das in größeren Projekten immer wieder auftaucht: der Rolle des Beraters, der frisch zertifiziert kommt, aber noch nie ein Projekt gegen die Wand hat fahren sehen. Man erkennt den Typus an den makellosen Folien, dem Koffer voller Buzzwords und der unerschütterlichen Überzeugung, die Realität werde sich schon dem Modell, genauer seinem Modell, beugen. Geht es schief, war es nie der Projektplan und nie die eigene Rolle. Die Schuld liegt dann zuverlässig bei den anderen: bei den Anwendern, beim Altsystem, beim Datenstand, am Wetter. Was in solchen Fällen fehlt, ist das, was sich nicht zertifizieren lässt: Narben. Die Erfahrung, dass Pläne auf Papier und Projekte in der Wirklichkeit zwei verschiedene Dinge sind.

Das ist keine Lästerei, sondern eine Warnung. Externe Unterstützung zu holen ist richtig und oft unverzichtbar. Aber Erfahrung lässt sich nicht durch Selbstbewusstsein ersetzen, ein Zertifikat nicht durch ein paar durchwachte Nächte an einem realen Projekt und Verantwortung nicht durch einen Namen auf dem Türschild. Die psychologische Projektforschung bestätigt, warum gerade diese Selbstsicherheit so gefährlich ist: Christoph Lüttge beschreibt, wie aus gutem Vertrauen und Motivation unversehens Selbstüberschätzung und Selbstgefälligkeit werden und wie man dann blind wird für die sich anbahnenden Fehlentwicklungen im Projekt. Notwendige Kurskorrekturen bleiben aus, und bis man merkt, wie weit man sich vom Ziel entfernt hat, ist es für Rettungsversuche oft zu spät. Genau deshalb ist der überzeugte Selbstdarsteller kein harmloser Typ, sondern ein Risiko mit Ansage.

Noch schwieriger wird es, wenn solche Konstellationen hausgemacht sind, wenn Rollen nicht nach Eignung besetzt werden, sondern aus anderen Gründen: aus Nähe, aus Vertrauen oder schlicht aus Bequemlichkeit. Das ist kein Einzelfall, sondern ein Muster, das man in vielen Betrieben beobachten kann. Wer Rollen nicht nach Eignung besetzt, hat das teuerste Risiko des Projekts bereits am ersten Tag eingebaut. Gerät dann ein so besetztes Vorhaben ins Trudeln, stellt sich eine unbequeme Frage oft erst später: Wer trägt am Ende die Konsequenzen? Erfahrungsgemäß selten der, der die Rolle ohne die passende Eignung bekommen hat. Häufiger trifft es den, der am wenigsten dafür konnte und am wenigsten Rückendeckung hatte – nicht selten den hinzugezogenen Externen.

Die gefährlichsten Aussagen im Projektmanagement

Manche Sätze klingen harmlos und sind in Wahrheit ein Alarmsignal. Sie fallen beiläufig, in einem Meeting, am Rande eines Gesprächs, oft mit einem Lächeln und in bestem Glauben. Und doch markieren sie erstaunlich zuverlässig den Punkt, an dem ein Projekt beginnt, leise aus dem Ruder zu laufen. Drei dieser Sätze begegnen einem immer wieder:

• „Das haben wir schon immer so gemacht.“

• „Das machen wir später.“

• „Das bekommen wir schon irgendwie hin.“

Jeder dieser Sätze hat einen eigenen Geschmack, doch sie besitzen einen gemeinsamen Kern: Sie beenden das Nachdenken, statt es zu beginnen. Sie schließen eine Frage, die eigentlich offen bleiben müsste.

„Das haben wir schon immer so gemacht.“ ist die Weigerung, zu prüfen, ob die Bedingungen heute noch dieselben sind wie damals. Vergangener Erfolg ist kein Beweis für zukünftigen. Er ist oft nur der Grund, warum niemand mehr genau hinsieht.

„Das machen wir später.“ verschiebt nicht nur eine Aufgabe, sondern ein Risiko, wobei Risiken mit der Zeit selten kleiner werden. Was am Anfang ein einfacher Nebensatz war, ist am Ende der kritische Pfad.

„Das bekommen wir schon irgendwie hin.“ ersetzt einen Plan durch Optimismus. „Irgendwie“ ist keine Methode, sondern das Eingeständnis, dass es noch keine gibt. Sabrina Lange hat diesem Muster in ihrem Buch über Komplexität im Projektmanagement einen eigenen Namen gegeben: das „Prinzip Hoffnung“. Der Projektleiter, der sich mit der rosaroten Brille durch den Alltag manövriert und darauf vertraut, dass sich die Probleme schon von selbst lösen, schließlich hat es früher ja auch funktioniert. Man erkennt darin sofort die halbe Verwandtschaft unserer drei Sätze wieder. Francis Bacon hat das schon vor Jahrhunderten auf den Punkt gebracht: „Hoffnung ist ein gutes Frühstück, aber ein schlechtes Abendbrot.“ Als Antrieb am Morgen taugt sie, als Grundlage für ein Projekt nicht.

Warum sind solche Aussagen so verlässliche Frühwarnsignale? Weil sie sichtbar machen, wo niemand mehr genauer hinschauen will. Sie treten genau dort auf, wo eine Frage unbequem wäre und wo die ehrliche Antwort mehr Aufwand, mehr Geld oder ein Eingeständnis bedeuten würde. Der Satz selbst ist dann nicht das Problem, sondern der Deckel, der über das Problem gelegt wird.

Dieselbe Mechanik gibt es auch in der laufenden Berichterstattung, und dort ist sie besonders gefährlich. Man kennt das Muster: Ein Projekt steht im Statusbericht wochenlang auf Grün, Grün, Grün. Dann, scheinbar über Nacht und aus dem nichts, auf Rot. In Wahrheit ist es wohl nicht über Nacht gekippt. Die Probleme waren längst da, nur hat sie niemand nach oben getragen, solange sie noch klein und beherrschbar waren. Jeder hoffte, es bis zum nächsten Bericht selbst wieder einzufangen. Ein ehrliches Gelb zur richtigen Zeit ist tausendmal wertvoller als ein schönes Grün, das man später teuer bezahlt. Wer als Projektleiter ein Klima schafft, in dem schlechte Nachrichten früh und ohne Angst nach oben dürfen, hat eines der wirksamsten Frühwarnsysteme überhaupt und wer das nicht tut, erfährt von den Problemen zuletzt, obwohl er sie verantwortet.

Dann ist da noch die leiseste aller Gefahren, die sich hinter dem freundlichsten Satz versteckt: „Können wir nicht noch schnell …?“ Selten stirbt ein Projekt an einer einzigen großen Fehlentscheidung. Viel häufiger erdrückt es das schleichende Wachsen des Umfangs. Ein kleines Ja hier, eine Zusatzanforderung dort, eine Sonderlocke, die im Einzelfall harmlos wirkt. In Summe verschiebt sich dann das Ziel unmerklich, bis das Projekt ein anderes ist als das, das man einmal geplant, kalkuliert und besetzt hat. Jedes einzelne dieser kleinen Zugeständnisse lässt sich gut begründen; genau das macht sie so gefährlich. Ein Projektleiter, der nicht Nein sagen kann, oder der Änderungen nicht sauber bewertet und einordnet, verwaltet am Ende kein Projekt mehr, sondern einen Wildwuchs.

Das führt zu einer Einsicht, die jeden erfahrenen Projektleiter prägt: Risiken entstehen selten überraschend. Das große Problem am Ende eines Projekts ist fast nie ein Blitz aus heiterem Himmel. Es hat sich angekündigt. Meist über Monate, in genau solchen beiläufigen Sätzen, in ausgewichenen Fragen, in Punkten, die immer wieder vertagt wurden. Die Warnsignale waren da. Es war nur niemand bereit, hinzusehen oder hinzuhören.

Und noch etwas gehört zu diesen Frühwarnsignalen, das gerne übersehen wird – gerade von jüngeren Projektleitern: Risiko ist nicht nur technisch. Man betrachtet Risiken fast reflexhaft als etwas Technisches. Die Schnittstelle, die Datenmigration, die Systemlast. Aber der unzuverlässige Mitarbeiter, der Zusagen nicht hält, und der unorganisierte Kollege, bei dem nichts zusammenläuft, sind mindestens ebenso große Risiken. Menschen sind ein Risikofaktor, und wer sie aus der Risikobetrachtung heraushält, betrachtet nur die halbe Wahrheit. Das ist kein bloßes Bauchgefühl aus der Praxis, sondern deckt sich auch hier wieder mit der Fachliteratur: Ursula Kusay-Merkle bringt es in ihrem Buch zum agilen Projektmanagement auf den Punkt, wenn sie feststellt, dass viele Projektprobleme ihren Kern eben nicht in technischen, sondern in sozialen Themen haben. Wer also nur die Technik absichert, sichert die kleinere Hälfte des Risikos ab.

Besonders tückisch ist dabei der vermeintlich sichere Partner. Der Projektleiter auf Kundenseite, von dem es heißt, er habe schon hundert Projekte gemacht und auf den man sich blind verlassen könne. Genau darin liegt das Risiko: dass es eben nicht stimmt und du es erst merkst, wenn es zu spät ist. Verlässt du dich blind, stehst du am Ende allein da. Und wenn das Projekt dann kippt, wird man nicht ihn durch den Saal jagen, sondern dich.

Man könnte nun meinen, die Rettung sei sauberes Dokumentieren. Schriftlich festhalten, wer was zugesagt hat. Das hilft, aber es rettet dich nicht vor deinem eigentlichen blinden Fleck. Denn du kannst nicht aufschreiben, was du vergessen oder übersehen hast. Man dokumentiert nicht die eigene Ahnungslosigkeit. Genau deshalb brauchst du ein Team – und in diesem Team ganz besonders den einen, der die vermeintlich doofen Fragen stellt. Der, der wieso, weshalb, warum fragt und mit einem beiläufigen „ähh, ich hätte da mal eine Frage“ genau die Lücke trifft, die alle anderen übersehen haben. Dieser Mensch ist kein Störenfried. Er ist deine Versicherung gegen das, was du allein nicht sehen kannst. Während der zertifizierte Selbstdarsteller glaubt, alles zu wissen, weiß der unbequeme Frager, dass niemand alles sieht und genau das macht ihn wertvoll. Wie ein solches Team idealerweise zusammengesetzt ist und welche Rollen wirklich über Erfolg oder Scheitern entscheiden, habe ich in einem eigenen kurzen Beitrag beschrieben: „Das richtige Team für Gießerei-Projekte“.

Und dann ist da noch eine Figur, die man auf keinen Fall unterschätzen sollte: derjenige, der inhaltlich wenig beizutragen hat, dafür aber zur richtigen Zeit beim richtigen Zuhörer sitzt, oft ganz oben. Er muss fachlich nichts können. Es reicht, dass er gehört wird. Ein einziger unbedachter Satz kann dort eine Idee in die Welt setzen, die sich in den Köpfen festsetzt und die man später mit keinem Argument mehr eingefangen bekommt. Solche zufällig gestreuten Flausen haben schon mehr Projekte beschädigt als manches technische Problem. Nicht nur Technik ist ein Risiko. Menschen sind es genauso.

Darin liegt zugleich die gute Nachricht. Wer lernt, diese Sätze als das zu hören, was sie sind, nicht als Beruhigung, sondern als Hinweis, gewinnt Zeit, die das Projekt später dringend braucht. Die gefährlichste Aussage im Projektmanagement ist deshalb nicht ein einzelner dieser Sätze. Es ist die Bereitschaft, diese unwidersprochen so stehenzulassen.

Wie sieht er also aus, ein guter Projektstart, jenseits aller Warnungen? Überraschend unspektakulär. Er beginnt nicht mit einem Kick-off-Event und schönen Folien, sondern mit unbequemen Fragen und ehrlichen Antworten. Man klärt zuerst, was das Projekt wirklich braucht, und prüft nüchtern, ob Team, Dienstleister und Grundlagen dem gewachsen sind. Wo etwas fehlt, holt man rechtzeitig die richtigen Menschen dazu, nach Eignung, nicht nach Verfügbarkeit oder Sympathie. Man denkt den Prozess in seiner ganzen Kette zu Ende, vom vorgelagerten Lieferanten bis zur nachgelagerten Weiterverarbeitung, und wählt das Werkzeug danach aus, was das Projekt verlangt, nicht danach, was man selbst am besten kennt.

Und dann passiert das eigentlich Entscheidende: Man traut sich, Annahmen als Annahmen zu benennen, statt sie für Wissen zu halten. Man sagt „das weiß ich nicht“ und „das müssen wir prüfen“, ohne sich dafür zu schämen. Genau das unterscheidet den erfahrenen Projektleiter vom selbstbewussten Anfänger: nicht, dass er mehr Antworten hat, sondern dass er die richtigen Fragen früher stellt und die Eigenschaft besitzt, sie sich auch dann zu stellen, wenn die Antworten unbequem sind. Wer so startet, läuft nicht schneller los. Aber er läuft in die richtige Richtung. Letztendlich ist das der einzige Vorsprung, der zählt. Denn besser vordenken als nachdenken. Denn Nachdenken heißt im Projekt meistens nacharbeiten.

Das Wichtigste in Kürze

Wenn aus diesem Artikel nur eine Handvoll Sätze hängen bleiben sollen, dann diese:

• Erst fragen, dann arbeiten. Eine gute Checkliste ersetzt kein Denken, verhindert aber, dass Offensichtliches übersehen wird. Spar dir die PowerPoint am Anfang, denn ohne die richtigen Fragen gibt es keine präsentationswürdigen Antworten.

• Den ganzen Prozess denken. Ein Prozess endet nicht an der Projektgrenze. Vor- und nachgelagerte Schritte, die gesamte Wertschöpfungskette und die beteiligten Menschen gehören dazu.

• Ressourcen und Qualifikation zuerst. Am Anfang steht die Frage nach Menschen, Können und Kapazitäten. Sowohl im eigenen Team als auch beim Dienstleister (ERP/MES). Externe früh einbinden, Abhängigkeiten und Grundlagen klären. Verliere die Ausgangsbasis nicht aus den Augen: Der Abstand zwischen Ist und Ziel – technologisch wie organisatorisch – ist ein eigener Risikofaktor. Von Windows 10 auf 11 ist kein Projekt; von Vista oder von Apple kommend schon.

• Das Projekt bestimmt das Werkzeug. Nicht die Vorliebe des Projektleiters. Excel ist hervorragend, aber nicht für jedes Projekt das richtige Fahrzeug. Wer das Projekt an seine eigenen Grenzen anpasst, bekommt es früher oder später zurück.

• Annahme ist nicht Wissen, Wissen nicht Realität. Annahmen über Technik, Software und Fähigkeiten ersetzen kein Wissen – und selbst Wissen ersetzt nicht die geprüfte Realität.

• Fehlende Kompetenz ist kein Makel, sondern eine Aufgabe. Gute Projektleiter müssen nicht alles können. Sie müssen erkennen, was sie nicht können, und rechtzeitig die richtigen Menschen ins Team holen.

• KI ersetzt die Vorarbeit nicht. Ohne klar definierten Prozess und gute Daten liefert auch KI nur schneller formuliertes Durcheinander. Sie unterstützt, sobald Klarheit herrscht, sie schafft sie nicht.

• Warnsätze ernst nehmen. „Das haben wir schon immer so gemacht“, „Das machen wir später“, „Das bekommen wir schon irgendwie hin“. Risiken kündigen sich meist Monate vorher an. Man muss nur bereit sein, hinzusehen.

Das Ende ist der Anfang

Und dann ist das Projekt irgendwann fertig – oder das, was alle dafür halten. Hier lauert der letzte, gern übersehene Fehler: Man verwechselt „technisch abgenommen“ mit „läuft wirklich im Alltag“. Fertig ist nicht fertig. Die Abnahme im Projektmeeting sagt noch nichts darüber aus, ob das System unter realen Bedingungen und mit echten Anwendern trägt. Und mindestens ebenso wichtig ist die Übergabe an den Betrieb: Zu viele Projekte werden gefeiert, und drei Wochen später ruft der Support an, weil nie sauber geklärt wurde, wer das Ergebnis künftig am Leben hält. Ein Projekt endet nicht mit dem Applaus, sondern erst dann, wenn der Betrieb es ohne die Projektmannschaft stemmen kann.

Denn das Ende eines Projekts ist meist schon der Anfang des nächsten. Genau deshalb gehört ans Ende eine ehrliche Reflexion mit allen Beteiligten: Was war gut, was war schlecht, was nehmen wir mit? Das ist keine Pflichtübung. Es ist die konstruktive Auseinandersetzung auch mit den eigenen Unzulänglichkeiten. Und ja, das reibt. Aber genau diese Reibung ist es, an der alle wachsen, nicht nur der Projektleiter. Wer sie sich und dem Team erspart, verschenkt die wertvollste Ressource, die ein abgeschlossenes Projekt hinterlässt. Die Chance, beim nächsten Mal ein Stück besser zu sein. In der agilen Welt hat dieses bewusste Innehalten einen festen Namen und einen festen Platz. Die Retrospektive, die dort als eine der wichtigsten Keimzellen für Verbesserungen gilt. Sie funktioniert nur unter der Bedingung, die auch für jede ehrliche Projektnachbetrachtung gilt. Gemeint ist die Oberste Direktive von Norman Kerth: Die Grundhaltung, dass alle Beteiligten zu jedem Zeitpunkt nach bestem Wissen und Gewissen gehandelt haben. Erst diese Haltung macht aus der Reibung einen geschützten Raum, in dem man über Fehler sprechen kann, ohne Schuldige zu suchen. Ohne sie wird aus der Reflexion eine Abrechnung und dann schweigen beim nächsten Mal alle. Dass dieser geschützte Raum kein weiches Beiwerk ist, betont auch die psychologische Projektliteratur: Vertrauen gilt dort als der kultureller „Schmierstoff“, der Menschen überhaupt erst bereit macht, Unsicherheiten offen anzusprechen und bestehende Pfade zu verlassen. Ohne Vertrauen keine ehrliche Reflexion und ohne ehrliche Reflexion kein Lernen.

Zu dieser Ehrlichkeit gehört auch ein Wort zur Führung des Projekts selbst sowie zum Thema Kontrolle, das oft missverstanden wird. Wann immer die notwendigen Sitzungen angesetzt sind, dann sind diese nicht aus Angst vor Kontrollverlust oder aus Misstrauen zu betrachten. Sie sind notwendig, um das Projekt ziel- und termingerecht im Sinne des Unternehmens zu steuern und zum Erfolg zu bringen. Zu viele Sitzungen entstehen nicht durch das Kontrollbedürfnis der Projektleiter, sondern meistens dadurch, dass Aufgaben nicht erledigt werden, dass niemand über den eigenen Tellerrand hinausschaut oder dass die Fäden nicht an einer Stelle zusammenlaufen, wodurch der Gesamtblick auf Projekt und Risiko verloren geht. Am Ende ist das aber auch eine Frage der persönlichen Haltung. Ein Projekt im Sinne des Unternehmens zu Ende zu bringen, ist keine Verhandlungssache und kein Beliebtheitswettbewerb.

Wie es weitergeht

Dieser Artikel ist bewusst ein Anfang. Er handelt vom Fundament und vom klaren Denken, bevor die erste Zeile geplant, das erste Tool geöffnet und die erste Folie gebaut wird. Denn erst wenn dieses Fundament steht, lohnt der Blick auf die Werkzeuge, die darauf aufsetzen. In den folgenden Beiträgen geht es deshalb einen Schritt weiter: Der nächste widmet sich der Frage, welche Rolle künstliche Intelligenz im Projektmanagement wirklich spielen kann. Jenseits von Euphorie und Abwehr, mit Blick darauf, wo sie echte Unterstützung leistet und wo sie an die Grenzen stößt, die wir hier bereits gestreift haben. Ein weiterer Beitrag wird sich der praktischen Seite zuwenden: der Entwicklung guter Prompts für ein aussagekräftiges Reporting. Also der Frage, wie man einer KI die richtigen Anweisungen gibt, damit am Ende belastbare Berichte entstehen und nicht nur Daten um der Daten willen. Die Reihenfolge ist auch hier kein Zufall: Erst das Denken, dann das Werkzeug.

Zum Schluss – ganz persönlich

Wenn ich alles, was auf diesen Seiten steht, auf einen Kern reduzieren müsste, dann diesen: Trotz aller Risiken, aller Werkzeuge und aller Methoden ist das Rückgrat eines jeden Projekts das Team. Und ein Rückgrat ist keine starre Stange. es ist eher wie eine Wirbelsäule, die sich beugen und mitbewegen können muss, während das Projekt läuft. Denn Projekte laufen fast nie unter Idealbedingungen; sie laufen immer als Zusatz zum eigentlichen Tagesgeschäft, nebenher und unter Druck. Genau deshalb kommt es am Ende oft auch nicht auf die schönste Planung an, sondern auf etwas viel Unspektakuläreres: auf Ehrlichkeit.

Ehrlichkeit zu sich selbst und zu dem Team, das hinter einem steht. Der Mut, das Projekt ehrlich zu betrachten, gerade auch die Ausgangsbasis, das ungeschminkte Wo komme ich her und wo will ich hin. Die eigenen Fehler nicht totzuschweigen und nicht die Schuld auf andere zu schieben. Sowie bei alldem eines nie zu vergessen: Die oberste Verantwortung liegt immer beim Projektleiter. Nicht beim Berater, nicht beim Dienstleister, nicht beim Team, sondern ggf. bei dir. Das klingt hart, aber es ist in Wahrheit befreiend, denn es bedeutet auch: Du hast es selbst in der Hand.

Das ist der eigentliche Grund, warum ich das hier aufgeschrieben habe. Nicht, um recht zu haben, und nicht, weil ich es besser wüsste. Die aufgeschlagenen Knie waren echt. Aufgeschrieben, weil dieses Wissen sonst irgendwann mit mir in Rente geht, und weil die, die nach uns kommen, es gebrauchen können. Wenn davon ein einziger Satz hängenbleibt, dann dieser: Sei ehrlich zum Projekt, zum Team und vor allem zu dir selbst. Der Rest ergibt sich daraus.