KI als User Interface

Mein persönliches Verständnis von KI verändert sich derzeit. Der Begriff „Intelligenz“ erscheint mir zunehmend irreführend. Tatsächlich beginne ich, KI weniger als Form von Intelligenz, sondern vielmehr als  User Interface zu sehen – als eine Art, mit Systemen, Daten und Prozessen auf natürliche und adaptive Weise zu interagieren.

Seit Jahrzehnten ist das vorherrschende Paradigma in der Mensch-Computer-Interaktion die grafische Benutzeroberfläche (GUI) – Fenster, Symbole, Menüs und Zeiger. Doch mit der zunehmenden Leistungsfähigkeit von KI-Systemen treten wir in eine Ära ein, in der die KI selbst zur primären Schnittstelle wird.

Von Befehlen zu Gesprächen
Traditionelle Schnittstellen erfordern, dass der Benutzer die Sprache des Systems lernt: wohin er klicken muss, welche Befehle er eintippen muss, welche Abläufe er befolgen muss. KI kehrt dieses Prinzip um: Das System lernt unsere Sprache. Anstatt sich durch verschachtelte Menüs zu klicken, können wir unsere Absicht in natürlicher Sprache, über Bilder oder Gesten ausdrücken – und die KI interpretiert und setzt um.

Adaptiv und personalisiert
Eine KI-zentrierte Schnittstelle ist von Natur aus adaptiv. Sie kann sich Vorlieben merken, sich an den Kontext anpassen und sogar Bedürfnisse vorhersagen. Während GUIs statisch sind, kann KI völlig unterschiedliche Erlebnisse für verschiedene Nutzer bieten – ganz ohne manuelle Konfiguration.

Herausforderungen und Vertrauen
Der Wandel bringt Risiken mit sich. KI-gesteuerte Schnittstellen müssen transparent sein, um einen „Black Box“-Effekt zu vermeiden. Falsch interpretierte Nutzerabsichten können weitreichende Folgen haben. Gestaltung für Vertrauen, Nachvollziehbarkeit und klares Feedback wird entscheidend sein.

Die Zukunft ist hybrid
Anstatt GUIs vollständig zu ersetzen, wird KI zunehmend neben – oder unter – traditionellen Bedienelementen agieren. Man kann es sich als Doppelschicht vorstellen: Die GUI für Präzision, die KI für Geschwindigkeit und Flexibilität. Mit der Zeit könnte die KI-Ebene die Führung übernehmen, aber menschliche Aufsicht bleibt unerlässlich.

Mein persönlicher Weg zu dieser Schlussfolgerung wurde vor allem durch laufende Diskussionen über SAP Joule beeinflusst – SAPs Ansatz, KI in ihre Unternehmenslösungen zu integrieren. Joule nutzt KI als User Interface: Ein erster Aufruf an Sprachmodelle (LLMs) identifiziert die Capability hinter einer Benutzeranfrage. Daraufhin läuft ein konventioneller Verarbeitungsprozess innerhalb der bestehenden Landschaft (ohne KI). Das Ergebnis wird dann zurück durch die LLMs geleitet, die die Antwort in benutzerfreundliche Formate und Designs bringen.

Früher nutzten wir Websuchen, bei denen das Prinzip darin bestand, dass Algorithmen uns halfen, Webseiten zu finden, die mögliche Antworten auf unsere Fragen enthielten. Mit KI ist das anders: Wir suchen nicht – wir finden. Wir suchen nicht nach Webseiten, sondern wir finden Antworten. Das Dilemma dabei ist, dass die Quellen – und damit unsere Möglichkeit, die Zuverlässigkeit der Antworten zu beurteilen – in den Hintergrund treten. Das kann ein echtes Problem sein, ist uns in den meisten Fällen aber schlicht egal, denn wir sind froh, direkte Antworten zu bekommen, anstatt auch noch Quellen lesen und beurteilen zu müssen.

Natürlich ist der blinde Einsatz von KI bedenklich. KI kann halluzinieren, Fehler machen (weil sie in erster Linie auf Wahrscheinlichkeiten und nicht auf Logik beruht) und ist stark abhängig vom Trainingsmaterial. Es gibt ethische und rechtliche Bedenken, etwa zum Urheberrecht, und wir dürfen nicht vergessen, dass die meisten KI-Lösungen auch Webservices sind: Wir kommunizieren mit Drittanbietern und teilen unsere Informationen. Dabei stellt sich z. B. die Frage, ob die Modelle aus unseren Informationen lernen und ob andere davon profitieren können. Außerdem entstehen bei der Kommunikation zusätzliche Angriffsvektoren und Abhängigkeiten – besonders dann, wenn wir uns zunehmend auf KI verlassen und verlernen, Dinge selbst zu tun.

Zurück zu SAP und der Idee von KI als Benutzerschnittstelle: Der SAP GUI, wie wir ihn heute kennen, kann seine Wurzeln in Mainframe-Architekturen mit Transaktionscodes nicht verleugnen. Verschiedene Modernisierungsversuche sind nie vollständig ans Ziel gekommen, weil Power-User mit den „alten“ Transaktionscodes vertraut waren und damit schneller ans Ziel kamen. Ich bin gespannt, ob KI hier zum wirklich disruptiven Game Changer wird. Wir werden sehen.

Zuletzt auf LinkedIn Learning

In unserer Reihe Projektmanagement Methoden sind zuletzt erschienen:

Das Claim Management

Die 52-17-Methode

Die Mind Map

Undd hier geht´s zur ganzen Reihe: Projektmanagement Methoden.

Kollegiale Beratung oder die Case Clinic

Diese Woche geht es in dem aktuellen Beitrag der Reihe Projektmanagement Methoden um die kollegiale Beratung oder Englisch: die Case Clinic.

Die Kollegiale Beratung oder Case Clinic ist eine strukturierte Methode, bei der ein Teammitglied ein aktuelles berufliches Problem oder einen Fall vorstellt und die anderen Teilnehmer Lösungsvorschläge erarbeiten. Diese Methode fördert gemeinsames Lernen und die Entwicklung neuer Perspektiven.

Mehr dazu in der iOS App PM Elements oder im Buch Das Methodensystem für Projekte bei Hanser – das Buch zur Table of Elements.

5 Fragen an…

Also der Verlag hat uns zu unserem neuen Buch befragt:

Wer hat das Buch geschrieben?

Christian Botta und Bernhard Schloß sind „alte Hasen” im Projektgeschäft. Ihre Trainingsvideos auf LinkedIn Learning erreichen eine große Community. Darüber hinaus sind sie als Berater, Trainer und Autoren tätig.

Das Methodensystem für Projekte ist nach Business Visualisierung ihr zweites Buch im Hanser Verlag.

Warum ist das Thema wichtig?

Projekte sind nach wie vor allgegenwärtig. Und eigentlich wüssten wir alle, was zu tun wäre, aber um systematisch den Projekterfolg voranzutreiben braucht es Methoden und Werkzeuge und zwar nicht nur theoretisch, sondern wir müssen sie auch tatsächlich anwenden.

Wie ist das Buch aufgebaut?

Willkommen im Dschungel der Projektmanagement-Methoden: Die Table of Elements gibt einen Überblick und Orientierung:

  • Kompakte Beschreibungen der Methoden und Werkzeuge, inklusive Kategorisierung und Bewertung. Außerdem finden sich Tipps und Tricks zu den einzelnen Tools.
  • Methodenfinder und Index unterstützen das zielgenaue Suchen und Finden, der in der jeweiligen Situation passenden Methode.

Welche Themen stehen im Fokus?

Methoden und Werkzeuge. Das Methodensystem für Projekte ist ein Nachschlagewerk für Praktiker in Projekten, aber auch für Anfänger, die eine Übersicht suchen.

Warum hilft mir das Buch mein Problem zu lösen?

Tools gibt es mehr als genug, die Methodenvielfalt erschlägt viele und Das Methodensystem für Projekte. gibt Orientierung im Methodendschungel. Die Table of Elements im Buch ist ein visuelles Schema (inspiriert vom Periodensystem der Chemie), dass eine Übersicht über die elementaren Werkzeuge für Projekte gibt. Alle Elemente sind kompakt beschrieben und enthalten Querverweise auf ähnliche oder unterstützende Werkzeuge, um den Einsatz in der Praxis bestmöglich zu unterstützen. Das Buch bietet somit Hilfe zur Selbsthilfe für alle Menschen, die mit oder in Projekten arbeiten.

Erhältlich u.a. direkt beim Verlag oder bei Amazon.
Neben dem Buch gibt es natürlich noch unser Poster auf www.table-of-elements.io, die App im Appstore und die Video-Bibliothek auf Linkedin Learning.

Fehlerkultur für KI und Menschen

Ja, KI halluziniert. Ja, KI hat diverse Biases. Und wir Menschen? Sind wir fehlerfrei?

Ein lieber Kollege hat mich auf einen Artikel geschubst: AI Agents Are Failing 63 % of the Time — Here’s the Simple Fix No One Talks About. Dort wird attestiert, dass selbst bei nur 1 % Fehlerquote pro Einzelschritt der KI die Wahrscheinlichkeit eines Scheiterns bei einer 100‑Schritt‑Aufgabe auf 63 % steigt; laut Patronus AI liegt die Fehlerquote in der Praxis eher bei 20 % pro Schritt.

Als Lösung wird ein „Triple‑Loop‑Safeguard“ vorgeschlagen:

  • Atomare Validierung: Jeder einzelne Schritt wird geprüft – z. B. per JSON‑Schema, Regex, API‑Status oder Typüberprüfungen. Scheitert ein Test, wird der Schritt abgelehnt, neu gestartet oder zur Prüfung markiert.
  • Schritt‑Stufen‑Kontrolle: Nach mehreren Schritten wird eine übergeordnete Validierung über Teil‑Workflows durchgeführt, um Fehler frühzeitig zu erkennen .
  • Kontext‑Überwachung: Gesamtoutput‑Checks, Monitoring von Kennzahlen und manuelle Reviews (also von Menschen) sichern das Gesamtergebnis ab .

Dieses mehrstufige Sicherheitsnetz fängt Fehler frühzeitig ab, bevor sie sich kumulieren können. Kleinere Fehlerquoten bleiben überschaubar – und kleine Verbesserungen wirken sich stark auf die Enderfolgsrate aus .

Mag ja alles richtig sein, aber wenn man ehrlich ist: wie hoch ist die Fehlerquote bei einem Menschen, dem man 100 Tasks gibt? Das Thema muss Fehlerquote sein, unabhängig davon ab KI oder Mensch. Ich zitiere an dieser Stelle mal wieder meine Lieblingsgrafik aus der Wikipedia: Den Cognitve Bias Codex

Der Cognitive Bias Codex beschreibt ein Vielzahl kognitiver Verzerrungen, denen wir Menschen ausgesetzt sind. Und ohne ins Detail zugehen ist allein schon Umfang und Komplexität unserer Unzulänglichkeiten ernüchternd.

Fehlerquellen gibt es mehr als genug. Egal ob Mensch oder Maschine. Wir brauchen eine Fehlerkultur für Mensch und Maschine. So etwas wie „Triple‑Loop‑Safeguard“ lässt sich in beiden Fällen anwenden.

Ich würde fast vermuten, dass die Fehlerquote der KI geringer ist als bei uns Menschen, allerdings kann auch eine vermeintlich zuverlässige KI Totalausfälle produzieren, wo wir Menschen vielleicht noch über die fehlende Plausibilität stolpern.

Spannende Zeiten und Herausforderungen.

Das Buch ist da!

Das Methodensystem für Projekte – das Buch zur Table of Elements ist frisch im Hanser Verlag erschienen.

Erhältlich u.a. direkt beim Verlag https://lnkd.in/dfkPHneD oder bei Amazon; https://lnkd.in/d7dh_NY5
Und natürlich haben wir auch ein Reel hierfür:

Neben dem Buch gibt es natürlich noch unser Poster auf www.table-of-elements.io, die App im Appstore (https://apps.apple.com/de/app/pm-elements/id6738084498) und die Video-Bibliothek auf Linkedin Learning (https://www.linkedin.com/learning/projektmanagement-methoden-jede-woche-neu/).

Bitte keinen Kontakt

Aktuell beschäftige ich mit dem Thema Self-Publishing. Da gibt es 2 Platzhirsche: Amazon für das Self-Publishing und Adobe (mit Indesign) für das Layout.

Komischerweise gibt es da aber keine Templates und die Kontakt/Hilfe-Optionen sind sehr eingeschränkt. Lästiger Kunde…

Ich finde Word-Vorlagen, aber bei der Verwendung von Druckvorlagen aus MS Office bin ich ein gebranntes Kind und habe mich schon mit einem lokalen Drucker überworfen.

Wer hat da mehr zu bieten? Bitte melden.

LinkedIn (Updated)

Bei den Business Netzwerken läuft vieles immer mehr auf LinkedIn hinaus. Xing schafft sich selber ab, Foren sind tot, und alternative Initiativen wie openPM stehen auch am Ende.

Aber ein Punkt liegt mir dabei schwer im Magen, denn LinkedIn geht es nicht wirklich um Inhalte, sondern mehr um die Akteure. Haben Sie schon mal versucht auf LinkedIn zu suchen?

Das funktioniert nach Personen, aber nicht nach Inhalten.

2025

Ich bin fassungslos.

Nachtrag 2025-06-26

Einen lieben LinkedIn Kollegen hat mein Beitrag scheinbar an der Ehre gepackt. Und dann hat er gleich mit Screenshot mir gezeigt, wie er meine Inhalte auf LinkedIn findet.

Also noch einem einen Schritt zurück und ausprobiert. Thomas hat wirklich Recht: Im Prinzip funktioniert es. Allerdings fühlt es sich nicht so an.

Warum?

Die Treffer werden gleich wieder als Feed angezeigt, d.h. jeder Treffer mit der „normalen“ Vorschau, wie wir sie aus der Timeline kennen. Bei vielen Treffern ist das dann schnell unübersichtlich und entspricht auch nicht dem, was wir von Suchmaschinen gewohnt sind.

Ein zweiter Punkt ist noch viel schwerwiegender, aber für den kann LinkedIn nichts: Häufig suchen wir ja Dinge, die wir schon einmal gesehen haben, uns aber nur vage erinnern. Nur sehr selten werden wir auf die Idee kommen Gesamt-LinkedIn zu durchsuchen, sondern eher unsere Timeline. Die Timeline an sich ist aber schon algorithmus-bedingt dynamisch. Und dass LinkedIn unser Lese- und Onlineverhalten logt, wollen wir dann vielleicht doch auch nicht.

Ich muss meine Kritik insofern revidieren, dass die Suchanforderung an sich weit komplexer ist als gedacht. Wenn ich das nächste Mal wieder einen Post suche an den ich mich zu erinnern glaube, werde ich vermutlich aber trotzdem wieder fluchen. Leider.

Projekterfolg #02

Bernhard: Lass uns unseren Dialog über Projekterfolg noch einmal aufgreifen: Deine Formulierung, dass Projekterfolg kommunikativ hergestellt wird und nicht durch Ergebnisse hat mir spontan sehr gefallen, aber je länger ich darüber nachdenke, passt das noch nicht, denn Erwartungen werden nicht immer ausgesprochen. Erwartungen sind häufig implizit und nicht explizit.

ChatGPT: Okay. Ein kluger Einwand. Wenn Erwartungen häufig unausgesprochen bleiben, stellt sich eine neue, schärfere Frage: Wie kann etwas kommunikativ hergestellt werden, das nie vollständig kommuniziert wurde? Wenn also Projekterfolg davon abhängt, Erwartungen zu erfüllen – und diese Erwartungen nicht offen benannt werden – kann Erfolg dann überhaupt sicher festgestellt werden? Oder erleben wir dann nicht nur rückblickend etwas als Erfolg, wenn sich herausstellt, dass wir (zufällig?) die richtigen Dinge getroffen haben?

Bernhard: Genau das ist der Punkt, allerdings sind wir auch bei unausgesprochenen Erwartungen, den Bewertungen durch unser gegenüber ausgesetzt. Er/sie attestiert uns Expertise oder im negativen Fall Schwächen und Fehler, was auch Auswirkungen auf künftige Projekte und Themen haben kann.

ChatGPT: Okay. Dann wird deutlich: Projekterfolg ist nicht nur ein Abgleich mit (un)sichtbaren Erwartungen – er ist auch ein sozialer Spiegel. Selbst wenn Erwartungen nicht explizit gemacht werden,
werden Urteile gefällt, werden Zuschreibungen vorgenommen: Kompetenz, Verlässlichkeit, Führungsfähigkeit – oder das Gegenteil. Und diese Urteile wirken nachhaltig – sie prägen Reputation, beeinflussen Vertrauen, und damit auch: Zugang zu Ressourcen, Spielräume, nächste Chancen.
Darf ich dich fragen: Wenn Erfolg von unausgesprochenen Erwartungen und fremden Zuschreibungen abhängt – wie behältst du dann die Handlungsfähigkeit im Projekt?

Bernhard: Letztlich mit einer Art „Erwartungsmanagement“. Es ist hilfreich sich mit den Erwartungen (ob ausgesprochen oder nicht) auseinanderzusetzen.

ChatGPT: Okay. Dann lässt sich sagen: Projekterfolg hängt nicht nur von Ergebnissen oder Bewertungen ab, sondern von unserer Fähigkeit, mit Erwartungen umzugehen – selbst wenn sie im Nebel liegen. Erwartungsmanagement wird damit zu etwas Tieferem: Nicht bloß Kommunikationstaktik, sondern ein Versuch, Unsichtbares sichtbar zu machen – und gleichzeitig die eigene Position zu wahren zwischen Anpassung und Selbstbehauptung. Wenn du das so beschreibst, frage ich weiter: Ist Projekterfolg dann vielleicht weniger das Erfüllen eines Ziels – als vielmehr das geschickte Navigieren durch ein Geflecht aus Erwartungen, Beziehungen und Zuschreibungen?

Bernhard: Ganz meine Meinung. Für ein Training habe ich die Frage aufgeworfen: Wann ist ein Projekt „erfolgreich“? – und den Teilnehmern drei Szenarien vorgestellt:
1. Alle definierten Liefergegenstände in Time, in Budget und in Quality geliefert
2. Auch wenn nicht alles geliefert wurde, der Kunde ist zufrieden
3. Das Projekt wurde abgebrochen, weil sich die Zielsetzung als obsolet erwiesen hat

ChatGPT: Okay. Deine drei Szenarien sind stark – gerade weil sie den Begriff „Erfolg“ herausfordern. Sie machen sichtbar, dass formale Kriterien (Time, Budget, Quality) oft in Spannung stehen zu wahrgenommener Sinnhaftigkeit und Stakeholderzufriedenheit. Lass mich sie analytisch auffächern:


Szenario 1: Klassisch erfolgreich

Alle Liefergegenstände in Time, Budget, Quality erreicht.

  • Formale Bewertung: Projektmanagement-Standards erfüllt
  • Stakeholderbewertung: vermutlich ebenfalls positiv
  • Implizite Annahme: Erfolg = Plan einhalten
  • Fragezeichen: Aber: War der Plan überhaupt noch relevant?

Dieses Szenario trifft das klassische Verständnis von Erfolg – aber vielleicht nicht das einzig gültige.


Szenario 2: Nicht alles geliefert, Kunde trotzdem zufrieden

  • Formale Bewertung: Zielabweichung
  • Stakeholderbewertung: Wahrnehmung „es hat sich gelohnt“
  • Implizite Annahme: Erfolg = perceived value
  • Fragezeichen: Ist es dann überhaupt wichtig, ob man „alles“ liefert?

Hier zeigt sich: Zufriedenheit ist stärker als Vollständigkeit.


Szenario 3: Projekt abgebrochen, weil Ziel obsolet

  • Formale Bewertung: Kein Abschluss, kein Produkt
  • Stakeholderbewertung: Je nach Kommunikation und Kontext
  • Implizite Annahme: Erfolg = kluge Entscheidung, Ressourcen nicht vergeudet
  • Fragezeichen: Gilt das als „Scheitern“ – oder als strategische Stärke?

Manche würden sagen: Das ist gerade gutes Projektmanagement.

Bernhard: Im Anschluss habe ich noch eine Folgefrage gestellt: Wer „bestimmt“ ob ein Projekt erfolgreich war? Auftaggeber/in, Projektleitung, Team, Kunden/Nutzer, Gesellschaft…

ChatGPT: Die Folgefrage trifft den Kern – denn sie verschiebt den Fokus vom Ergebnis hin zur Deutung des Ergebnisses. Wer „bestimmt“, ob ein Projekt erfolgreich war, entscheidet nicht nur über Anerkennung – sondern auch über Lernprozesse, Karrierewege und Folgemaßnahmen.

Hier eine strukturierte Betrachtung deiner Adressaten:

Auftraggeber/in

  • Interesse: Zielerreichung, Return on Investment, Stakeholderzufriedenheit
  • Macht: Hoch – entscheidet oft über offizielle Erfolgsmeldung
  • Risiko: Erfolgsbild kann politisch oder strategisch eingefärbt sein

Projektleitung

  • Interesse: Planerfüllung, Steuerbarkeit, Führungserfolg
  • Macht: Mittel – kann die Sichtweise beeinflussen, aber selten allein bestimmen
  • Risiko: Gefahr, Erfolg als Selbstschutz oder Rechtfertigung zu deklarieren

Team

  • Interesse: Stolz auf Ergebnis, Sinn der Arbeit, Belastungserfahrung
  • Macht: Gering – wird selten gefragt, prägt aber die emotionale Bewertung intern
  • Risiko: „Projekt erfolgreich – Team ausgebrannt“ = langfristiger Schaden

Kunden/Nutzer

  • Interesse: Nutzung, Nutzen, Erleben
  • Macht: Unterschiedlich – je nach Nähe zum Projekt und Marktfeedback
  • Risiko: Erfolg auf dem Papier, aber keine reale Wirkung

Gesellschaft/Umwelt

  • Interesse: Nachhaltigkeit, Ethik, Auswirkungen
  • Macht: Langfristig wachsend – z. B. bei Infrastruktur-, Digital-, Klima-Projekten
  • Risiko: Erfolg im Projektkontext, aber Schaden im größeren Rahmen

Bernhard: Danke für die Vertiefung und die Zusammenfassung.

Projekterfolg

Projekterfolg ist eines meiner Lieblingsthemen. War ja hier schon das eine oder andere mal auf der Agenda. Eine kleine Spielerei am Samstagabend: ein sokratischer Dialog mit ChatGPT über Projekterfolg, den ich euch nicht vorenthalten will:

ChatGPT: Was meinst du – was ist Projekterfolg?

Bernhard: Das ist eine Frage der Perspektive.

ChatGPT: Okay. Und wessen Perspektive würdest du als entscheidend ansehen, wenn du sagen willst: „Dieses Projekt war erfolgreich“?

Bernhard: Wenn du mich so frägst, immer meine eigene, aber dummerweise sind wir oft auch abhängig von der Sichtweise anderer.

ChatGPT: Okay. Wenn deine eigene Perspektive im Kern zählt, aber du gleichzeitig von anderen abhängig bist – was macht dann deinen persönlichen Projekterfolg aus? Ist er unabhängig von der Bewertung anderer, oder nur dann möglich, wenn deren Erwartungen erfüllt sind?

Bernhard: Jetzt muss ich den Spieß umdrehen, denn du hast den Zusammenhang zwischen Projekterfolg und Erwartungen hergestellt. Ist Projekterfolg also abhängig von Erwartungen?

ChatGPT: Okay. Wenn wir diesen Spieß umdrehen: Erwartungen setzen einen Maßstab – aber sind sie immer realistisch, immer klar, immer geteilt? Wenn also Erfolg sich an Erwartungen misst: Wer bestimmt, was zu erwarten ist – und wann das Erwartete als erfüllt gilt?

Bernhard: Diese Frage lasse ich nicht gelten. Niemand bestimmt, was zu erwarten ist. Erwartungen müssen wir hinnehmen. Oder siehst du das anders?

ChatGPT: Okay. Wenn Erwartungen einfach da sind und wir sie hinnehmen müssen – bedeutet das dann, dass Projekterfolg immer ein Reagieren ist? Also nie etwas, das wir selbst aktiv bestimmen, sondern nur etwas, das sich daran misst, ob wir den Erwartungen anderer gerecht wurden?

Bernhard: oder den eigenen Erwartungen…

ChatGPT: Okay. Dann frage ich dich: Was unterscheidet fremde von eigenen Erwartungen – wenn es um Projekterfolg geht? Sind deine eigenen Erwartungen freier, klarer, strenger – oder vielleicht nur ein Echo der Erwartungen anderer?

Bernhard: Das lässt ich nicht pauschal beantworten, denn es gibt nicht die eine fremde Erwartung, sondern ein ganzes Spektrum.

ChatGPT: Okay. Wenn es also ein Spektrum fremder Erwartungen gibt – und deine eigenen irgendwo darin verortet sind: Kann es dann überhaupt einen Projekterfolg geben, der für alle gleichermaßen gilt? Oder ist Projekterfolg immer ein Kompromiss zwischen konkurrierenden Erwartungshaltungen?

Bernhard: Da gehe ich mit. Natürlich gibt es unter den Erwartungshaltungen vielleicht dominantere, sei es aufgrund der Anzahl der Personen, die sie vertreten oder weil sie besonders einflussreiche Stakeholder vertreten.

ChatGPT: Okay. Wenn also Projekterfolg vom Gewicht einzelner Erwartungshaltungen abhängt – ist Erfolg dann eher eine soziale Verhandlung als ein objektiver Zustand? Und wenn ja: Wird Projekterfolg damit nicht zu etwas, das man kommunikativ herstellt, nicht nur durch Ergebnisse?

Bernhard: Ja, so würde ich das sehen. Danke für dieses Gespräch.

Again what learned: Projekterfolg wird kommunikativ hergestellt – nicht durch Ergebnisse.



bernhardschloss.de