Tag 17 - Vom Ja zum Auftrag: Wie man ein Umsetzungprojekt sauber aufsetzt

Marc

Stell dir vor, du stehst im Sitzungszimmer der Geschäftsleitung. Fünf Minuten Pitch, vier Teile, harte Zahlen, saubere Wirtschaftlichkeit. Am Ende nicken alle, der CEO lächelt und sagt: Ja, machen wir, klingt überzeugend. Du packst deine Sachen zusammen, fühlst dich wie der König der Welt und willst am liebsten direkt anfangen zu bauen. Und genau in diesem Moment, exakt da, beginnt die gefährlichste Phase des gesamten Projekts.

Stefan

Der klassische Siegerkater. Man verwechselt ein freundliches Nicken mit einem rechtsgültigen Freibrief. Ein Ja ist nämlich kein Auftrag. Ein Ja ist streng genommen nur die Erlaubnis, überhaupt erst einen verbindlichen Auftrag zu formulieren.

Marc

Genau das erleben wir doch ständig. Wenn du diesen Zwischenschritt auslässt, arbeitest du mit einem sogenannten stillschweigenden Mandat. Das geht zwei Wochen gut, vielleicht vier. Aber in Woche zwölf knallt es an der Wand. Die Geschäftsleitung dachte, das System löst alle Kundenbeschwerden vollautomatisch, und das Projektteam hat lediglich eine interne Wissensdatenbank für drei Sachbearbeiter aufgesetzt. Und wer badet es aus? Immer derjenige, der ohne schriftliche Charta losgerannt ist.

Stefan

Man übernimmt das komplette persönliche Haftungsrisiko für alle unausgesprochenen Wünsche der Führungsetage. Und das führt uns direkt zur grossen Zäsur im AIBS Programm. Wir sind an Tag 17. Und für alle, die gerade schwitzen: Alles, was wir heute zu den Handlungskompetenzen D1 und D2 besprechen, gehört ausdrücklich nicht mehr in die Projektarbeit, die am Donnerstag, den ersten Oktober um 23 Uhr 59 fällig ist.

Marc

Das muss man wirklich dreimal unterstreichen. Bitte schreibt die Projektcharta von heute nicht mehr in eure Projektarbeit hinein! Was dort reingehört, war bis Tag 16 vollständig unterrichtet. Tag 17 zielt auf etwas anderes: auf Prüfungsteil zwei am dreissigsten Oktober 2026 in der BernEXPO, hundertzwanzig Minuten in smartlearn, und natürlich auf das spätere Fachgespräch, wenn die Experten fragen: Wie wären Sie denn nach dem Ja konkret vorgegangen?

Stefan

Werfen wir kurz den Blick in die Kohorte, so wie die Datenbank am 28. September stand. 23 Teilnehmende. Sieben haben Aufgabe vier bereits eingereicht. Bei acht Personen ist bisher noch gar nichts passiert. Aber die Spitze zeigt eine bemerkenswerte Disziplin. Schau dir Strato Christodulo an: 19 von 19 Zielen erreicht, und er lässt in seiner Rechnung stehen, dass der Nutzen rechnerisch unter den Kosten liegt. Er rechnet es nicht schön, er biegt nichts hin. Genau diese schonungslose Ehrlichkeit braucht ein echter Business Case.

Marc

Absolut stark. Oder Daniele Calabrese: Sein Mitigationsplan von Tag 14 war ein echtes Lehrstück. Klare Massnahme mit Rolle und Termin, Kosten getrennt in einmalig und laufend, und das Restrisiko ganz bewusst namentlich getragen. Aber Stefan, wir haben auch vier Teilnehmende mit deutlichem Nachholbedarf. Denen fehlen zwei oder drei Wochenaufgaben. Eine reine Erinnerungsmail bringt da nichts mehr, da braucht es ein echtes Standortgespräch.

Stefan

Und für die acht ohne Spur bei Aufgabe vier gilt: Keine Panik schieben. Ihr habt noch Zeit bis Sonntag, den vierten Oktober, 18 Uhr. Die Frist selbst ist machbar, nur die lähmende Vorstellung, es sei schon alles zu spät, die bricht einem das Genick. 48 Stunden vor der grossen Donnerstagsabgabe zählt nur eins: Fokus auf den Kern, Lückenliste abarbeiten, und heute Abend sauber mitdenken, wie man aus einem Ja ein belastbares Mandat formt.

Marc

Kommen wir zu diesem Werkzeug, das den Streit verhindert, bevor er überhaupt entstehen kann: die Projektcharta. Im Lektionenplan heisst das Umsetzungsauftrag. Das Ding hat genau eine A4 Seite und acht feste Felder. Stefan, nenn mir die acht Bausteine im Schlaf.

Stefan

Ganz ohne Spickzettel: Erstens Auftraggeber und Entscheid mit genauem Datum. Zweitens das Ziel in genau einem messbaren Satz. Drittens der Umfang mit dem berühmten Draussen. Viertens die Erfolgskriterien. Fünftens die Muss Anforderungen. Sechstens Ressourcen und Zeitfenster. Siebtens die Rollen nach Personen. Und achtens das Abbruchkriterium samt Grundannahmen.

Marc

Acht Felder. Und das Faszinierende ist ja: Fast alle stürzen sich sofort auf Feld zwei, das Ziel, oder auf Feld fünf, die Technik. Aber das Feld, an dem Projekte in der Praxis tatsächlich gerettet oder zerstört werden, ist Feld drei. Genauer gesagt: die zweite Hälfte von Feld drei. Das Draussen.

Stefan

Warum ist das Draussen für dich wertvoller als das, was drin ist?

Marc

Weil in Projekten fast nie darüber gestritten wird, ob das Vereinbarte schlecht geliefert wurde. Der Streit entzündet sich immer daran, dass jemand auf Führungsebene etwas erwartet hat, das nie aufgeschrieben war! Wenn du in Feld drei nicht mindestens drei glasklare Punkte definierst, die ausdrücklich nicht geliefert werden, hast du verloren. Beim Verbandsassistenten ISA Desk heisst das: Keine Rechtsauskünfte, keine Einzelfallentscheide zu Mitgliedschaften und absolut keine Verarbeitung von Personendaten Dritter.

Stefan

Und das hat sofort architektonische Konsequenzen. Wenn Personendaten Dritter draussen sind, muss die Middleware technisch so konfiguriert werden, dass sie diese Felder gar nicht erst an das Sprachmodell weiterleitet. Eine organisatorische Grenze wird zu einer technischen Barriere. Und das bringt uns direkt zu Feld acht, den Annahmen. Da lauert die grösste Illusion moderner Unternehmen: die Datenlage.

Marc

Du meinst die Zahlen von Gartner, oder? Die haben mich wirklich umgehauen.

Stefan

Gartner prognostiziert ganz nüchtern: Bis Ende 2026 werden sechzig Prozent aller KI Projekte aufgegeben, die nicht auf KI tauglichen Daten aufbauen. 63 Prozent der Organisationen verfügen schlichtweg nicht über die nötigen Datenpraktiken oder wissen nicht einmal, ob sie darüber verfügen. Wer die Prüfung der Datenqualität in Sprint drei verlegt, baut ein Schloss auf Treibsand. Die Datenprüfung gehört als harte Annahme mit Stichtag und Prüfauftrag in Feld acht der Charta.

Marc

Und wer entscheidet das Ganze? Da sehe ich in Schweizer KMU und Verbänden immer wieder denselben Kardinalfehler: In Feld sieben steht dann unter Entscheidungsrolle: die IT Abteilung oder die Geschäftsleitung. Stefan, warum treibt dich das zur Weissglut?

Stefan

Weil eine Abteilung kein Gewissen hat, keine Unterschrift leistet und nachts nicht wach liegt. Eine Abteilung kann keine Abwägungsentscheidung treffen. Ob eine Antwortqualität ausreicht oder ob ein Restrisiko getragen wird, ist eine Geschäftsentscheidung, keine Informatikfrage. In Feld sieben muss genau ein einzelner voller Name stehen. Wenn zwei Personen entscheiden, entscheidet niemand. Und das Projekt stirbt den langsamen Tod durch endlose Koordinationsmeetings.

Marc

Lass uns über Feld vier sprechen: die Erfolgskriterien. Viele denken ja, man nimmt einfach die Kennzahl aus dem Business Case von Tag 15 oder 16 und kopiert sie rüber. Aber das ist ein fundamentaler Denkfehler. Die Zahl wechselt komplett ihre Rolle.

Stefan

Exakt. Im Business Case war die Kennzahl ein Überzeugungsinstrument, ein Argument. Man wollte zeigen, dass sich das Investment lohnt. Da durfte man mit Schätzkorridoren und plausiblen Potenzialen arbeiten. In der Charta aber wird die Kennzahl zur unerbittlichen Abnahmebedingung. Sie entscheidet darüber, ob der Auftrag erfüllt ist oder nicht. Und dafür gilt eine harte Regel: Ein Erfolgskriterium ist nur dann ein Kriterium, wenn es scheitern kann.

Marc

Der Sechs Wochen Test! Ich liebe diesen Test. Wenn ich in einer Charta lese: Die Mitarbeitenden arbeiten effizienter oder die Kundenzufriedenheit steigt, dann frage ich den Projektleiter: Kannst du in sechs Wochen vor die Geschäftsleitung treten und mit diesem Satz sagen: Kriterium nicht erreicht? Geht nicht! Weil Zufriedenheit ein Kaugummi Begriff ist. Man kann sich immer herausreden.

Stefan

Genau darum braucht jedes Erfolgskriterium zwingend fünf Angaben. Erstens: eine Grösse, die man ohne Interpretation zählen kann. Zweitens: eine harte Schwelle. Drittens: einen genauen Zeitpunkt, ab wann gemessen wird, also nach der Anlaufphase. Viertens: die Messfrequenz. Und fünftens: eine namentlich benannte Person, die misst. Beim ISA Desk lautet das: Ab Woche acht werden mindestens 52 Prozent der Support Tickets ohne Rückfrage beantwortet, wöchentlich erhoben aus dem Ticketsystem durch die Geschäftsstellenleitung. Alle fünf Angaben drin. Da gibt es null Interpretationsspielraum.

Marc

Da kann niemand mehr schwurbeln. Und wer das nicht tut, endet wie McDonald's mit IBM. Diese Geschichte muss man sich wirklich auf der Zunge zergehen lassen.

Stefan

Ein faszinierendes Lehrstück. McDonald's hat ab 2021 gemeinsam mit IBM die automatisierte Sprachbestellung an Drive thru Schaltern getestet. Das lief nicht nur in einem kleinen Labor, sondern zuletzt an über hundert Filialen in den USA. Und im Juni 2024, nach gut drei Jahren, ziehen sie plötzlich den Stecker. Die Begründung: Man glaube weiterhin an Sprach KI, suche sich jetzt aber einen anderen Partner.

Marc

Drei Jahre! Überleg mal, was das an Millionen gekostet hat. Die Entscheidung aufzuhören war fachlich völlig richtig. Aber sie kam Jahre zu spät! Warum? Weil am Anfang niemand ein klares, automatisches Abbruchkriterium definiert hatte. Wenn du nicht vorher festlegst, bei welcher Fehlerquote oder welchen Latenzen nach sechs Monaten Schluss ist, läuft so ein Vorhaben einfach immer weiter, solange irgendjemand im Konzern noch Budget zuschiesst.

Stefan

Und das gilt im Schweizer Kontext genauso wie im Silicon Valley. Ein Kriterium ohne Scheitermöglichkeit ist kein Steuerungsinstrument, sondern reine Unternehmensfolklore. Wer steuern will, muss den Mut haben, den Punkt zu definieren, an dem das Projekt offiziell als gescheitert gilt.

Marc

Jetzt kommen wir zu dem Punkt, der bei vielen klassischen Projektleitern für echte Verwirrung sorgt. Man hat gelernt: Wir machen zwei Wochen Sprints nach Scrum, wir schätzen Story Points, wir packen alles ins Backlog. Und dann kommt ein KI Projekt, und plötzlich funktioniert das ganze schöne Lehrbuch nicht mehr. Warum zerschellt agiles Standardvorgehen an maschinellem Lernen?

Stefan

Weil in einem KI Projekt zwei völlig unterschiedliche Arten von Arbeit aufeinandertreffen, die man unmöglich mit derselben Methode steuern kann. Wir haben auf der einen Seite die klassische Engineering Arbeit. Das ist das Bauen: Serverumgebung einrichten, Datenpipelines legen, Schnittstellen programmieren, Benutzeroberfläche gestalten, Monitoring aufsetzen. Das ist bekannte Arbeit mit bekanntem Ergebnis. Das lässt sich wunderbar schätzen und in Sprints mit klarer Definition of Done abarbeiten.

Marc

Aber daneben liegt die Forschungsarbeit. Das Herausfinden.

Stefan

Ganz genau. Die Frage lautet: Erreicht das Modell auf unseren spezifischen, oft unsauberen Unternehmensdaten die geforderte Qualitätsschwelle von sagen wir 85 Prozent Genauigkeit? Das weiss vorab kein Mensch auf der Welt. Jede Schätzung in Story Points wäre an dieser Stelle eine glatte Lüge. Und wenn du Entwickler dazu zwingst, in einem zweiwöchigen Sprint ein fixes Qualitätsversprechen abzugeben, erzeugst du toxischen Druck. Die Teams fangen an, Fortschritt vorzutäuschen, Schwachstellen zu kaschieren und Halluzinationen kleinzureden, statt die Wahrheit auf den Tisch zu legen.

Marc

Und wie löst man dieses Dilemma in der Praxis? Im Themenpaper wird dafür die Architektur von Sprint null vorgeschlagen.

Stefan

Ein Vier Wochen Plan mit zwei parallelen Bahnen. Oben die Bau Bahn für die planbare Infrastruktur. Unten die Forschungs Bahn mit genau einer einzigen Frage. Zum Beispiel: Schafft das System auf fünfzig echten Mitgliederanfragen mindestens 75 Prozent korrekte Antworten ohne Halluzination? Die Forschungsbahn läuft nicht nach Schätzung, sondern über eine feste Zeitbox. Und am Ende dieser vier Wochen steht kein gemütlicher Meilenstein mit Kaffee und Folien, sondern ein echter Entscheidungspunkt.

Marc

Ein Entscheidungspunkt mit genau drei zulässigen Antworten. Weiter wie geplant, anders herangehen oder abbrechen. Wenn die dritte Option fehlt, ist es kein Entscheidungspunkt, sondern ein banaler Statusbericht.

Stefan

Richtig. Und damit dieser Entscheidungspunkt technisch überhaupt fundiert gefällt werden kann, brauchen wir MLOps. Für uns als Business Specialists lässt sich das auf vier glasklare Prinzipien reduzieren. Erstens: Nicht nur Code versionieren, sondern drei Dinge synchron: Code, Daten und Prompts beziehungsweise Modelle. Zweitens: Das Prüfset entsteht vor der ersten Zeile Code. 30 bis 50 reale, historische Fälle mit menschlich validierter Ideallösung. Das nennt man Eval Driven Development.

Marc

Und drittens und viertens?

Stefan

Drittens: Monitoring ab Minute eins, nicht erst nach dem Go Live, sonst hast du keinen Baseline Vergleich. Und viertens: Ein automatisierter Rollback innerhalb von wenigen Minuten. Wenn eine neue Prompt Version im Betrieb versagt, musst du per Knopfdruck zurück zur stabilen Version können. Sonst ist dein Abbruchkriterium eine leere Drohung.

Marc

Jetzt müssen wir den Blick nach vorne werfen. BernEXPO, dreissigster Oktober 2026. Prüfungsteil zwei. Sechs Fallstudien in der Prüfungsumgebung smartlearn. Challenge 03 dreht sich um Systemintegration. Und da hat ICT Berufsbildung Schweiz klargestellt: Es wird technisch. Es geht um Tiefe. Stefan, warum darf ein KI Agent niemals direkt in die Datenbank eines Unternehmens greifen?

Stefan

Das ist das eiserne Prinzip API first über eine Zwischenschicht, eine Middleware. Wenn du einer generativen KI direkten Schreib oder Lesezugriff auf deine produktive SQL Datenbank gibst, hast du jede Kontrolle verloren. Du kannst nicht nachvollziehen, wer wann welche sensiblen Datensätze abgefragt hat. Eine Middleware sitzt genau dazwischen: Sie nimmt die Anfrage des Agenten entgegen, übersetzt sie in eine sichere Abfrage, filtert unerlaubte Felder wie Passwörter oder Personendaten Dritter rigoros heraus und schreibt ein manipulationssicheres Zugriffsprotokoll.

Marc

Und diese Middleware muss mit den harten physikalischen Grenzen alter Systeme klarkommen. Schauen wir uns die Latenzrechnung aus dem Technik Briefing an. Das ist Stoff, der am dreissigsten Oktober eins zu eins sitzen muss. Rechne uns das mal vor.

Stefan

Die Zahlen sind ernüchternd. Eine typische KI Pipeline mit Vektorsuche, Kontextaufbereitung und LLM Generierung benötigt 30 bis 90 Sekunden. Ein bestehendes Legacy Backend, eine alte Mitgliederverwaltung, braucht für eine komplexe Abfrage oft 40 bis 90 Sekunden. Wenn du im schlechtesten Fall 90 Sekunden KI Strecke plus 90 Sekunden Legacy Backend zusammenrechnest, landest du bei exakt 180 Sekunden. Und bei 180 Sekunden greift bei fast allen Webgateways der harte Verbindungsabbruch, der Timeout!

Marc

90 plus 90 ergibt 180. Kein Puffer. Null Millisekunden Reserve. Die Verbindung bricht ab, der User bekommt einen Fehlerbildschirm. Und noch viel wichtiger: Kein normaler Mensch wartet drei Minuten vor einem weissen Ladebildschirm auf eine Antwort.

Stefan

Exakt. Und wenn das Altsystem dann auch noch keine Filter oder Paginierung kennt, sondern nur einen sogenannten Volldump liefert, also bei jeder Anfrage die gesamte Mitgliederdatenbank überträgt, geht das System komplett in die Knie. Dagegen gibt es vier Standardmuster: Zwischenspeichern im Cache, nächtlicher Index Abgleich, ein eigener dedizierter Suchindex oder Delta Aktualisierungen, wo nur veränderte Datensätze geladen werden.

Marc

Und daraus müssen die Prüfungskandidaten eine Muss Anforderung formulieren. Aber nicht irgendwie als Fliesstext, sondern nach dem Vier Teile Schema der Prüfungskommission. Dimension, Satz, Begründung und Treiber.

Stefan

Genau. Erstens Dimension in einem Wort: Antwortzeit. Zweitens der Satz: Die Zwischenschicht muss innerhalb von 20 Sekunden entweder ein Teilergebnis oder eine qualifizierte Statusmeldung liefern. Drittens Begründung mit Datenbezug: Da Altsystem und KI Strecke im Worst Case bis zu 180 Sekunden summieren und damit die Timeout Grenze erreichen. Und viertens der Treiber: Gemessene maximale Antwortzeit des Mitglieder Endpunkts über zwei Wochen. Wenn der Treiber fehlt, ist die Anforderung eine blosse Meinung und gibt null Punkte.

Marc

Damit haben wir das methodische Rüstzeug beisammen. Zum Schluss noch ein ganz persönliches Wort an unsere Kohorte: Wir wissen, dass viele von euch gerade am Anschlag laufen. Leute wie Claudia Wyss oder Sabine van Putten, die fachlich extrem weit vorne sind, aber komplett im Stillen arbeiten: Nutzt die Feedbackschleifen! Geht in den Dialog mit der KI Plattform Mary, holt euch die Rückmeldung aktiv ab. Und an alle, die jetzt noch an ihrer Projektarbeit für Donnerstag feilen: Bleibt ruhig. Ihr habt die Substanz. Bringt die Entscheidungsvorlage sauber zu Ende, lasst die Charta für die Prüfung am dreissigsten Oktober im Hinterkopf, und zieht das Ding durch. Ihr schafft das.

Stefan

Dem ist nichts hinzuzufügen. Viel Erfolg beim Endspurt, wir sehen uns in Bern.