Genug lamentiert über den Niedergang von openPM und den PMCamps, denn es gibt ja noch ein kleines gallisches Dorf, das sich wacker hält: Zürich. Und am Freitag war PMCamp Zürich.

Mit dem Debattierhaus Karl der Große, eine wunderbare Location im Herzen der Altstadt (und ich Idiot hab anfangs ernsthaft darüber nachgedacht mit dem Auto anzureisen, dabei war es umso schöner Bahnhof, Hotel und Location alles fußläufig zu haben, wobei man bei den Hotelpreisen in Zürich schon mal schlucken darf).

Aber zum PMCamp, in Zürich eintägig, in besagter historische Umgebung mit ganz tollen Gastgebern – ein herzliches Dankeschön an Lucia, Anne, Katrin und Mathias. Ihr hattet ein hervorragendes Händchen bei der Auswahl der Keynote (Stefan Schwitter), denn das Thema Achtsamkeit hat tatsächlich in die eine andere Session und das eine oder Gespräch am Rande ausgestrahlt und zum Mindsetting beigetragen. Die Sessions waren in bester Barcamp-Tradition bunt und vielfältig. Bemerkenswert: es gab keine einzige „PM und KI“-Session. Gott sei dank. (Die Vertreter dieser Fraktion sind wohl gerade alle beim IPMA World Kongress in Berlin.) Ich empfand das als sehr wohltuend, weil mir die Gespräche durchaus gezeigt haben, dass die meisten von uns sich selbstverständlich damit beschäftigen und KI nutzen, aber eben ganz normal und nicht als Hype und dass es gerade in Projekten immer um Menschen geht, die eben achtsam miteinander umgehen müssen, wobei die konkrete Perspektive viel persönlicher war: wie gehe ich mit mir in dieser (Projekt-)Welt achtsam um. Die Themen der Sessions reichten vom Zielparadoxon, PMO, Projektfinanzierung bis hin zu psychologischen Effekten, um nur einige zu nennen. Natürlich gab es auch eine Session zu Table of Elements. In den Sessions an denen ich teilgenommen habe, haben wir alle auf den Präsentationscharakter verzichtet, was sehr angenehm war und gleich zu vertrauensvollen Gesprächen geführt hat. Ein kleines persönliches Highlight für mich war Ivanas Session, die ihr ganz persönliches „Problem“ mit ihrem Auftraggeber mitgebracht hat und Rat von den Teilnehmern gesucht hat. Auch wenn wir am Schluss in ihrer Runde nur mehr 5 oder 6 Teilgenberinnnen waren, haben Menschen die sich vorher nicht kannten, miteinander diskutiert, Mut gemacht und Wege gesucht. Auch so etwas ist in einem Barcamp möglich. Danke, liebe Ivana, für deine Bereitschaft dich so zu öffnen und deinen Mut uns zu fragen und mit uns zu diskutieren.

Nach dem Closing gab es den für Zürich obligatorischen Apero und die Gespräche und das Vernetzen gingen auf der Terrasse noch bis in den Abend weiter.

Haltet die Stellung! Gut möglich, dass ich wiederkomme.

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.

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.

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.

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.

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 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/).

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.

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.

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.