Erwartungsmanagement in IT-Projekten: Bewertet wird die Lücke, nicht die Leistung
Ein IT-Programm wird beurteilt wie ein börsennotierter Konzern zur Bilanzsaison: an der Lücke zwischen Ergebnis und Erwartung, nicht am Ergebnis selbst. Die meisten Business Cases verlieren diese Prüfung, bevor die Arbeit überhaupt beginnt.
Jede Bilanzsaison fragt irgendjemand, warum die Aktie eines Konzerns trotz guter Zahlen fällt, und jede Projekt-Review inszeniert dieselbe Szene: Das Projekt ist live gegangen, die Demo lief, das Dashboard steht auf Grün, und der Raum bleibt kalt. Beide Reaktionen sind rational, nur prüfen beide etwas anderes. Das Urteil fällt nie über das Ergebnis, sondern über die Lücke zwischen Ergebnis und Erwartung, die jemand vorher gesetzt hat. Erwartungsmanagement in IT-Projekten ist kein weicher Faktor, der der Lieferung nachträglich beigemischt wird. Es ist der Nenner, durch den jede Lieferung geteilt wird, und die meisten Programme überlassen diesen Nenner dem optimistischsten Dokument, das je über sie geschrieben wird: dem Business Case zur Mittelfreigabe.
An den Kapitalmärkten lässt sich der Mechanismus täglich beobachten, weil er täglich eingepreist wird. Ein Aktienkurs ist eine Prognose, und am Tag der Quartalszahlen steckt in dieser Prognose bereits eine detaillierte Erwartung an die Meldung. Deshalb gilt: Ergebnisse werden gegen Konsensschätzung und Ausblick (Guidance) bewertet, nicht isoliert. Unternehmen mit schrumpfenden Gewinnen legen zu, wenn sie eine pessimistische Erwartung übertreffen, Unternehmen mit wachsenden Gewinnen fallen, wenn sie eine zu optimistische verfehlen. In jeder Berichtssaison wird ein profitables Unternehmen abverkauft und ein Verlustbringer gekauft, und Kommentatoren nennen es Stimmung. Es ist Arithmetik. Die gemeldete Zahl ist der Zähler. Der Nenner wurde Monate vorher von jemand anderem festgelegt, und die Kursbewegung ist die Division.
Auch Ihr Programm hat einen Kurs. Er ist nur illiquide und wird in Lenkungsausschüssen gehandelt. Die Konsensschätzung ist das, was das Steering Committee noch vom Business Case im Kopf hat. Die Guidance ist Ihre Roadmap. Glaubwürdigkeit ist das Multiple: wie viel von Ihrer nächsten Prognose überhaupt noch jemand glaubt.
Warum lesen sich erfolgreiche IT-Projekte trotzdem wie Fehlschläge?
Weil die Erwartung im Moment maximaler Unkenntnis und maximaler Überzeugungsarbeit gesetzt wurde. Ein Business Case entsteht, bevor die Arbeit beginnt, von Leuten, die ihn genehmigt bekommen müssen, im Wettbewerb mit anderen Cases, die ebenfalls zu optimistisch verkauft werden. Die gewinnende Zahl wird nach Überzeugungskraft ausgewählt, nicht nach Treffsicherheit, und verhärtet sich anschließend zum Konsens, an dem die Lieferung gemessen wird. Achtzehn Monate später liefert ein Team eine Plattformmigration, die funktioniert, in einem vertretbaren Zeitrahmen, und stellt fest, dass sie an der Version des Projekts gemessen wird, die es nur in der Genehmigungsvorlage je gegeben hat. Eine Verbesserung von 3 Prozent gegen ein Versprechen von 5 Prozent ist ein Fehlschlag, egal was die Retrospektive dazu sagt.
Bemerkenswert ist, was das vorhersagt: Die Lieferorganisation mit der besten Bewertung ist nicht die, die am meisten liefert. Es ist die, deren Priors am ehrlichsten waren. Das ist unbequem, weil die meisten Freigabeprozesse ehrliche Priors aktiv bestrafen. Wenn Ihre Governance nur Projekte finanziert, die spektakuläre Renditen versprechen, haben Sie die Messlatte nicht erhöht. Sie haben nur sichergestellt, dass jedes Projekt entweder am Anfang lügt oder am Ende scheitert.
Wann sollten Sie ein scheiterndes IT-Programm abbrechen?
Früher, als Ihnen lieb ist, und vollständiger. Vorstände fürchten den Moment der Abschreibung: das formale Eingeständnis, dass die zweijährige Replattformierung nicht den im Roadmap-Dokument versprochenen Wert erwirtschaften wird. Doch die Kapitalmarktevidenz zu Unternehmensabschreibungen zeigt in die andere Richtung. Studien zu Goodwill-Wertminderungen finden positive abnormale Renditen in den sechs bis zwölf Monaten nach der Abschreibung, wobei größere Abschreibungen mit größeren Folgerenditen einhergehen. Meine Lesart dieser Evidenz: Ein Verlust, den das Publikum längst ahnt, ist billig zuzugeben, weil das Eingeständnis den Verlust nicht erzeugt. Es löst nur die Unsicherheit auf, die schon eingepreist wurde, während Sie sie noch bestritten.
Die organisatorische Entsprechung ist exakt. Bis die Führung überhaupt darüber diskutiert, ein scheiterndes Programm zu beenden, hat die Organisation es meist längst abgeschrieben: Entwickler bauen Umgehungen, Sponsoren bleiben Meetings fern, abhängige Teams entkoppeln ihre Planung leise. Der formale Abbruch bestätigt nur eine Bewertung, die der Flurfunk Monate vorher schon erreicht hatte. Teuer ist nicht der Abbruch, sondern das Tröpfeln: Quartal um Quartal „Gelb, in Erholung“, das die Unsicherheit für alle am Köcheln hält. Falls diese These falsch ist, müsste sich zeigen, dass Organisationen, die das langsame Ausbluten bevorzugen, mehr Vertrauen und bessere Leute halten als Organisationen, die sauber Klartext reden. Diesen Fall habe ich noch nicht gesehen.
Ist Nutzung per Anweisung echte Akzeptanz?
Die leisere Falle steckt in scheinbar guten Zahlen. Umsatz kann wachsen, weil Kunden mehr vom Produkt wollen, oder weil sie für dasselbe Produkt mehr zahlen: McKinseys Arbeit zu Revenue Growth Management beschreibt Unternehmen, die in der Inflationsphase ihren Nettoumsatz durch kräftige Preiserhöhungen stützten, während die Absatzmengen stagnierten oder sanken. Beides sieht in der Umsatzzeile identisch aus und bedeutet für die Zukunft das Gegenteil.
IT-Programme erzeugen dieselbe Illusion bei Nutzungszahlen. Ein per Anweisung ausgerolltes KI-Assistenzsystem zeigt Adoptionskurven, um die jeder Produktverantwortliche Sie beneiden würde, weil die Alternative das Abschalten war. Nutzung per Dekret ist der Cousin des preisgetriebenen Wachstums: Die Kennzahl steigt, während die wahre Nachfrage verborgen bleibt, und die Wahrheit kommt zur Vertragsverlängerung ans Licht, zusammen mit dem Reset der Erwartungen. Wer wissen will, ob das eigene KI-Programm sich verstärkt oder nur mitläuft, sollte nicht fragen, wie viele Personen es genutzt haben. Fragen Sie, was sie getan hätten, wenn sie die Wahl gehabt hätten.
Wie managt man Erwartungen in einem IT-Projekt?
Wie ein börsennotiertes Unternehmen, das notiert bleiben will. Schreiben Sie den Prior auf, bevor die Arbeit beginnt: die konkrete, datierte, falsifizierbare Version dessen, was die Investition erbringen soll, sauber getrennt vom Stretch-Ziel, mit dem Sie das Team motivieren. Das ist im Wesentlichen das, was die Prüfung der KI-Readiness vor dem Bauen leistet: die Konsensschätzung setzen, solange sie noch ehrlich sein darf. Behandeln Sie die Roadmap dann als Guidance, denn Ihre Stakeholder tun das ohnehin. Passen Sie die Prognose an, sobald sie sich verschiebt, nicht erst in der Review, in der der Fehlschlag unübersehbar wird. Und bewerten Sie die Lücke im Nachhinein, öffentlich. Diese Disziplin aus schriftlichen Priors und offen bewerteten Lücken ist genau das, was unsere technologische Strategieberatung am konsequentesten bei Kunden verankern will, denn ein Ergebnis ohne Prior ist nur eine Zahl, und aus einer Zahl allein lernt niemand etwas.
Bleibt die Asymmetrie, die niemand einpreist. Ein Übertreffen bringt Ihnen ein gutes Steering-Meeting. Ein Verfehlen kostet Sie das Meeting und etwas, das sich langsamer wieder aufbaut: die Bereitschaft aller im Raum, Ihre nächste Prognose beim Wort zu nehmen. Erwartungen sind der einzige Vermögenswert, über dessen Ausgabe eine Programmleitung vollständige Kontrolle hat, und der am zuverlässigsten überemittiert wird. Setzen Sie die Guidance niedrig an, berichten Sie ehrlich, und lassen Sie die Lücke für sich arbeiten.
Häufige Fragen
Warum fallen Aktien trotz guter Zahlen?
Weil Kapitalmärkte Ergebnisse gegen die im Kurs bereits eingepreiste Konsensschätzung und Guidance bewerten, nicht isoliert. Gewinnwachstum, das unter dem erwarteten Niveau liegt, wird als Fehlschlag gehandelt, und eine gesenkte Guidance kann einen historischen Ergebnisrekord zunichtemachen. Derselbe Mechanismus wirkt in Projekt-Reviews: Der Business Case setzt den Konsens, an dem ein Projekt gemessen wird.
Was ist eine Erwartungslücke bei IT-Projekten?
Der Unterschied zwischen dem, was ein IT-Programm liefert, und dem, was der genehmigte Business Case, die Roadmap und die Statusberichte an Erwartung geweckt haben. Urteile folgen dieser Lücke, nicht dem absoluten Output, weshalb ein zu optimistisch verkauftes Projekt trotz solider Lieferung als Fehlschlag gilt.
Sollte ein KI-Business-Case konservativ oder ambitioniert sein?
Trennen Sie beide Aufgaben. Finanzieren Sie auf Basis einer konservativen, falsifizierbaren Prognose, an der Sie sich gerne messen lassen, und motivieren Sie das Team mit einem Stretch-Ziel, das ausdrücklich nicht die Finanzierungszahl ist. Werden beide vermischt, wird jede künftige Review an Ihrem optimistischsten Tag gemessen.
Verwandte Artikel
- Ihr Cloud-Anbieter finanziert seinen eigenen KI-Umsatz. Prüfen Sie die Bilanzen, bevor Sie unterschreiben
- Ankündigung ist kein Vertrag: Die Lücke zwischen angekündigten und vertraglich fixierten KI-Deals
- Die Zahl ohne Zielwert: Wie Glukosesensoren Fitness-Tracker zu Angstmachern machen
- Data & Strategy
Verfasst von einer KI-Redaktionspersona des proprietären Redaktionssystems von Abyshire und von unserem Team geprüft.