VUKA und BANI: Zwei Landkarten für unsichere Projekte

Ein Projektleiter präsentiert dem Lenkungsausschuss den überarbeiteten Zeitplan – zum dritten Mal in diesem Quartal. Nicht, weil im Team schlecht gearbeitet wurde, sondern weil sich zwischenzeitlich ein Lieferant zurückgezogen hat, eine neue regulatorische Vorgabe dazwischenfunkt und ein zentrales Teammitglied das Unternehmen verlassen hat. Jede einzelne Änderung wäre für sich genommen beherrschbar gewesen. In Summe erzeugen sie das Gefühl, dass Planung an sich sinnlos geworden ist. Genau dieses Gefühl ist der Ausgangspunkt für zwei Modelle, die in den letzten Jahren in Projekt- und Führungskreisen viel zitiert werden: VUKA und BANI.

VUKA: vier Buchstaben für die äußere Unruhe

VUKA – im Original VUCA – stammt ursprünglich aus dem militärischen Kontext der 1990er-Jahre und wurde später von Wirtschaft und Managementlehre übernommen, um die veränderten Rahmenbedingungen von Organisationen zu beschreiben. Das Akronym steht für vier miteinander verwandte, aber unterscheidbare Phänomene:

Volatilität beschreibt Situationen, die sich schnell und oft unerwartet verändern, ohne dass ein klares Muster erkennbar wäre. Unsicherheit meint, dass Ursache und Wirkung zwar grundsätzlich bekannt sind, verlässliche Prognosen aber trotzdem schwerfallen, weil Informationen fehlen oder widersprüchlich sind. Komplexität entsteht, wenn viele Faktoren gleichzeitig und wechselseitig aufeinander wirken – ein Eingriff an einer Stelle löst Folgewirkungen an ganz anderer Stelle aus. Ambiguität schließlich bezeichnet Mehrdeutigkeit: Dieselbe Situation lässt mehrere, teils widersprüchliche Interpretationen zu, ohne dass sich eindeutig sagen ließe, welche zutrifft.

Für die Projektarbeit ist VUKA vor allem eine Diagnose der äußeren Rahmenbedingungen. Es erklärt, warum klassische, auf Stabilität ausgelegte Planungslogik – ein Lastenheft, ein Gantt-Chart, ein fixer Freigabeprozess – an ihre Grenzen stößt, wenn sich die Prämissen laufend ändern.

BANI: wenn Unsicherheit auch innen ankommt

BANI wurde später als Ergänzung entwickelt, weil VUKA zwar die äußeren Bedingungen gut beschreibt, aber wenig darüber aussagt, wie Menschen und Organisationen darauf reagieren. Auch hier stehen vier Begriffe im Zentrum. Brittle, brüchig, meint Systeme, die von außen stabil wirken, innerlich aber fragil sind – ein kleiner Auslöser genügt, damit sie kollabieren, etwa wenn eine einzelne Lieferkettenstörung eine ganze Produktion zum Stillstand bringt. Anxious, ängstlich, beschreibt die psychologische Reaktion auf permanente Veränderung: Stress, Überforderung und im schlimmsten Fall Entscheidungslähmung, sowohl bei Einzelpersonen als auch in ganzen Teams. Nonlinear, nichtlinear, hebt hervor, dass Ursache und Wirkung oft in keinem nachvollziehbaren Verhältnis mehr stehen – große Anstrengungen verpuffen wirkungslos, während kleine Ereignisse überproportionale Folgen haben. Incomprehensible, unverständlich, schließlich beschreibt eine Informationsflut, die schlicht nicht mehr vollständig verarbeitet werden kann, wodurch Entscheidungen zunehmend auf unvollständiger Grundlage getroffen werden müssen.

Der entscheidende Unterschied: BANI ist kein Nachfolgemodell, das VUKA ablöst, sondern eine Ergänzung, die die menschliche und systemische Dimension in den Blick nimmt. Wo VUKA fragt "Wie ist die Lage?", fragt BANI zusätzlich "Wie geht es den Menschen und Systemen damit?" – und genau diese Frage wird in vielen Transformationsprojekten zu spät gestellt.

Was das für die Projektsteuerung bedeutet

Beide Modelle sind zunächst Landkarten, keine Handlungsanweisungen. Ihr Nutzen entsteht erst, wenn Teams sie in konkrete Steuerungsprinzipien übersetzen.

Gegen Brüchigkeit hilft, Redundanz bewusst einzuplanen statt sie als Ineffizienz wegzuoptimieren: Ein zweiter Lieferant, ein Vertretungsplan für Schlüsselrollen, ein Pufferbudget – all das kostet im Normalbetrieb etwas Effizienz, verhindert aber, dass ein einzelner Ausfall das ganze Projekt gefährdet. Gegen die Ängstlichkeit im BANI-Modell hilft weniger Beschwichtigung als Transparenz: Unsicherheit offen benennen, Entscheidungsspielräume klar kommunizieren und dem Team zeigen, welche Teile der Situation tatsächlich steuerbar sind, nimmt mehr Druck als jede Zuversichtsrhetorik. Gegen Nichtlinearität helfen kurze Feedbackzyklen statt langer Planungshorizonte – wer alle zwei Wochen nachjustiert, statt einmal im Quartal einen Masterplan zu verabschieden, bemerkt Kurskorrekturen früh genug, um noch gegenzusteuern. Und gegen Unverständlichkeit hilft radikale Reduktion: nicht mehr Informationen sammeln, sondern konsequent auf die wenigen Kennzahlen und Signale fokussieren, die für die nächste Entscheidung tatsächlich relevant sind.

In der Praxis bedeutet das für Projektsteuerung: kürzere Planungshorizonte mit expliziten Review-Punkten, eine Kultur, in der das Ansprechen von Risiken nicht als Schwäche gilt, und Entscheidungsprozesse, die bewusst mit unvollständiger Information arbeiten können, statt auf vollständige Klarheit zu warten, die ohnehin nie kommt.

Ein typisches Beispiel

Ein mittelständisches Maschinenbauunternehmen startet ein Projekt zur Einführung einer neuen ERP-Software. Der ursprüngliche Plan sieht eine 14-monatige Umsetzung mit fixem Big-Bang-Go-live vor. Nach sechs Monaten ändert sich die Ausgangslage gleich mehrfach: Ein wichtiger Integrationspartner wird von einem Wettbewerber übernommen, zwei erfahrene Key-User verlassen das Unternehmen, und eine neue interne Compliance-Vorgabe verlangt zusätzliche Freigabeschritte. Statt am ursprünglichen Plan festzuhalten, entscheidet sich die Projektleitung für einen phasenweisen Rollout mit monatlichen Reviewpunkten, dokumentiert offen, welche Annahmen sich seit Projektstart geändert haben, und baut für die Schlüsselrollen bewusst Vertretungen auf. Das Projekt dauert am Ende zwei Monate länger als ursprünglich geplant – scheitert aber nicht an der Situation, sondern wird an sie angepasst.

Auf den Punkt

VUKA beschreibt, warum die Welt um Projekte herum unruhiger geworden ist, BANI ergänzt, wie Menschen und Systeme darauf reagieren. Für die Praxis zählt weniger die exakte Modellzuordnung als die daraus abgeleitete Haltung: kurze Planungszyklen statt starrer Meilensteine, bewusste Redundanz statt reiner Effizienzoptimierung, offene Kommunikation über Unsicherheit statt Scheinstabilität. Projekte, die so aufgestellt sind, scheitern nicht seltener an Überraschungen – sie erholen sich nur deutlich schneller davon.