Ausgangspunkt

Warum ich meine Geschichte teile

Es gibt Momente in der Projektarbeit, die man nicht vergisst. Nicht weil sie besonders dramatisch waren — sondern weil sie einem etwas gezeigt haben, das man vorher nicht sehen konnte. Ich habe solche Momente gesammelt. Über 25 Jahre. In Telekommunikationsprojekten, KI-Einführungen, agilen Transformationen.

Und irgendwann wurde mir klar: Das, was mich in diesen Momenten wirklich weitergebracht hat, stand in keinem Lehrbuch. Es stand auch in keinem PMI-Standard — nicht weil die Standards falsch waren, sondern weil sie eine Frage nicht beantworten können: Wie denkt, fühlt und handelt man in einem lebendigen sozialen System, das sich verändert, während man es gestaltet?

Ich teile diese Geschichte, weil ich weiß, wie es sich anfühlt, mit vollständiger Methoden-Expertise in einem Projekt zu stehen — und trotzdem nicht zu verstehen, warum es ins Stocken gerät. Weil die Anforderungen stimmen, der Plan solide ist, das Team kompetent — und es trotzdem nicht fließt.

Dieses Gefühl ist unter Projektmanager:innen weiter verbreitet, als wir zugeben. Und es verdient eine ehrliche Antwort.

Was andere PMs aus dieser Geschichte mitnehmen können: keine neue Methode, die sie anwenden sollen. Sondern eine andere Art, Projekte zu denken — als lebendige soziale Systeme mit eigener Logik, nicht als Aufgabenlisten, die man abarbeitet. Wer diesen Perspektivwechsel einmal vollzogen hat, sieht Projekte anders. Und führt sie anders — mit mehr Klarheit, mehr Wirksamkeit, und vielleicht auch mit mehr Gelassenheit in der Komplexität.

Der Ursprung

Es war nicht ein Projekt. Es waren viele.

Wenn Menschen fragen, warum ich ARCHITECT9 entwickelt habe, suche ich nicht lange nach einer Antwort. Ich denke an die Projekte zurück, die mich geprägt haben. Nicht weil sie erfolgreich waren — sondern weil sie auf eine Weise scheiterten, die mich nicht losließ.

01

Das CRM-Projekt, das ein System nicht sah

Anfang der 2000er-Jahre, Telekommunikationsbranche. Ein externes Projektteam soll ein CRM-System einführen. Die Anforderungen werden sorgfältig aufgenommen. Alles wirkt methodisch sauber.

Was niemand einbezog: Es gab Menschen im Unternehmen, die das Gesamtsystem kannten. Die wussten, dass viele dieser Anforderungen bereits von bestehenden Systemen erfüllt wurden. Aber sie wurden nicht gefragt. Oder nicht ernst genommen.

Das Ergebnis: Der externe Projektleiter baute ein paralleles System — mit denselben Services, die schon da waren. Das Projekt scheiterte nicht, weil das Wissen fehlte. Es scheiterte, weil das vorhandene Wissen im System unsichtbar blieb.

Das ist kein Methoden-Fehler. Das ist kein Wissensproblem. Das ist ein Fehler im Umgang mit Menschen — und mit dem Wissen, das sie tragen.
02

40 Systeme — und die Lücken dazwischen

Im selben Umfeld: die Integration von 40 Systemen. Rechnungssysteme, CRM, Network-Commands für Aktivierung und Deaktivierung von Kundendiensten. Jede Komponente wurde einzeln betrachtet. Anforderungen wurden pro Modul aufgenommen — isoliert, ohne den End-to-End-Ablauf zu analysieren.

Einzelne Komponenten funktionierten. Das Gesamtsystem nicht. Die Lücken entstanden genau dort, wo die Übergaben stattfanden — zwischen den Systemen. Dort, wo niemand hingeschaut hatte. Die Lücken gehörten zu keinem Modul. Also gehörten sie niemandem.

Dieses Muster tritt heute in hundert anderen Kontexten auf — nicht zwischen Systemen, sondern zwischen Abteilungen, Teams, Führungsebenen. Das Problem entsteht an den Schnittstellen.
03

Der Moment, der alles veränderte — das eCommerce-Projekt

Ein komplexes Projekt, parallel geführt auf zwei Plattformen. Eine klassisch geplant, eine hybrid-agil. Das klassische PM-Team vertraute dem agilen Vorgehen nicht: kein GANTT-Diagramm, kein klassischer Meilensteinplan — also kein echtes Vertrauen.

Was folgte, war kein Zufall. Es war eine Entscheidung. Man wollte einen Plan B — eine technische Ausweichlösung. Wir haben früh und deutlich gesagt, dass diese Lösung technisch nicht funktionsfähig ist. Man glaubte uns nicht.

Enorme Ressourcen, wochenlange Meetings, detaillierte Planung — für eine Lösung, die selbst im Einsatz nicht funktioniert hätte. Das agile Projekt war am Ende früher fertig. Plan B wurde nie gebraucht.

Das war der Moment, in dem ich wusste: Methoden allein reichen nicht. Wir brauchen ein anderes Denken — über Projekte, Systeme und Wandel.

04

Transformation mit vollen Händen und leeren Rücken

Das erste: Management sagte 100% Ja. Trotzdem lief alles klassisch. Teammitglieder konnten nur Teilzeit mitwirken. Ein interner Transformation Lead wurde eingestellt — ohne Erfahrung. Irgendwann gab er auf. Die Transformation blieb halbfertig. Weil echtes Commitment und ausgesprochene Unterstützung zwei verschiedene Dinge sind.

Das zweite: Großer Konzern. Globale Initiative. Lokale Transformation Owner — ohne Agile Coaches, ohne echte Kapazität. Teilnahme nur in der „Freizeit". Kein priorisiertes Portfolio, keine Projektstruktur, maximale Auslastung überall.

Guter Wille ist kein Commitment. Und ein Mindset, das niemand trägt, verändert nichts.
05

KI-Infrastruktur ohne Use Case

Das jüngste Muster, das ich immer wieder sehe: Ein KI-Projekt startet. Infrastruktur ist beschafft. Budget ist freigegeben. Die Pilotphase beginnt.

Nur: Welchen Business-Wert soll die KI liefern? Wer trifft die Entscheidung, wenn das Modell empfiehlt? Wer ist verantwortlich, wenn es falsch liegt? Was passiert nach dem Piloten?

Niemand hat diese Fragen vorab gestellt. Weil alle mit der Technologie beschäftigt waren — nicht mit dem Warum.
Die Wende

Luhmann, schlaflose Nächte und eine Brücke, die es nicht gab

Ich begann zu lesen. Ich las Niklas Luhmanns „Soziale Systeme". Und plötzlich fielen mir die Schuppen von den Augen.

Systeme sind autopoietisch. Sie können von außen nicht gesteuert, nur perturbiert werden.

Genau das war mein Projekt. Ich hatte versucht, ein komplexes soziales System zu steuern wie eine Maschine. Kein Wunder, dass es nicht funktionierte.

Aber dann kam die ernüchternde Erkenntnis: Luhmann war brillant im Erklären — aber er sagte mir nicht, was ich am Montag im Projekt-Meeting tun sollte. Die Systemtheorie gab mir ein Verständnis, aber keine Handlungsanleitung.

Ich brauchte eine Brücke. Von der Theorie zur Praxis. Von der Analyse zur Intervention. Und weil ich diese Brücke nirgendwo fand, begann ich, sie selbst zu bauen. Aus Luhmann und Kybernetik. Aus 25 Jahren Praxis in Telekommunikation, Digitalisierung, KI-Projekten und agilen Transformationen. Aus allem, was in Lehrbüchern fehlte — und in echten Projekten entscheidend war.

ARCHITECT9 ist die Brücke, die ich selbst gebraucht hätte. Von der Theorie zur Intervention. Vom Verstehen zum Handeln. Heute baue ich sie — für andere.

Das Modell

ARCHITECT9 — wie ich heute über Projekte denke

Wenn ich heute in ein Projekt gehe, trage ich innerlich eine Struktur mit mir — nicht als Checkliste, sondern als Orientierung. Sie hat sich aus all diesen Momenten destilliert. Die neun Prinzipien sind keine abstrakten Konzepte. Jedes einzelne ist aus konkreten Momenten meiner Projekterfahrung entstanden.

Human Excellence

— weil Menschen der entscheidende Faktor sind. Immer.
Analyse & Ausrichtung
Verstehe das System, bevor du es veränderst.
Im CRM-Projekt wurden Anforderungen sorgfältig aufgenommen — methodisch sauber. Und trotzdem scheiterte es, weil niemand das bestehende Systemökosystem analysiert hatte. Das vorhandene Wissen war im System. Nur unsichtbar.
Commitment & Klarheit
Rollen, Ziele, Verantwortungen: alle an einem Strang, alle mit Plan.
In beiden Transformationsprojekten sagte das Management 100% Ja. Und meinte strukturell Nein. Guter Wille ist kein Commitment. Das ist der Unterschied, den ich heute zuerst prüfe — bevor das Projekt startet.
Empowerment
Menschen wachsen lassen, statt sie zu kontrollieren.
Im eCommerce-Projekt wussten wir, dass Plan B nicht funktionieren würde. Wir haben es früh und deutlich gesagt. Man glaubte uns nicht. Empowerment bedeutet für mich: Das Wissen im System sichtbar machen — und den Menschen vertrauen, die es tragen.

Technical Excellence

— weil Struktur und Prozesse tragen müssen, auch unter Druck.
Risiko-Früherkennung
Schwächen aufspüren, bevor sie zum Problem werden — mit strukturiertem Bauchgefühl.
Bei der Integration von 40 Systemen funktionierten alle Komponenten einzeln. Die Lücken entstanden an den Übergaben — zwischen den Systemen, dort, wo niemand hingeschaut hatte. Weil die Lücken zu keinem Modul gehörten, gehörten sie niemandem. Seitdem schaue ich bewusst dorthin, wo niemand hinschaut.
Handlungsfähigkeit sichern
Prozesse, die tragen — auch unter Druck.
Im zweiten Transformationsprojekt gab es keine Agile Coaches, keine echte Kapazität, kein priorisiertes Portfolio. Die Menschen arbeiteten an der Transformation — in ihrer Freizeit. Heute ist eine der ersten Fragen: Sind die Rahmenbedingungen so gestaltet, dass das Team überhaupt handeln kann?
Transparenz schaffen
Ein gemeinsames Bild — nicht nur Reporting.
Im eCommerce-Projekt hatte keiner ein gemeinsames Bild davon, was das Projekt wirklich war. Die einen sahen ein agiles Vorhaben auf Kurs. Die anderen sahen ein Risiko ohne GANTT-Diagramm. Beide schauten auf dasselbe Projekt — und sahen etwas völlig anderes.

Adaptive Excellence

— weil Anpassungsfähigkeit heute Überlebensstrategie ist.
Iteratives Vorgehen
Mit Veränderung rechnen, statt sie zu kontrollieren.
Das eCommerce-Projekt zeigte, was passiert, wenn man Komplexität mit einem starren Plan zu kontrollieren versucht. Wochenlange Meetings für einen Plan B, der nie gebraucht wurde. Das agile Teilprojekt war früher fertig — nicht weil es keinen Plan hatte, sondern weil es mit Veränderung gerechnet hatte.
Kontinuität & Kultur
Transformation verankern — nicht nur starten.
In beiden Transformationsprojekten blieb am Ende eine halbfertige Veränderung übrig. Die Projekte endeten — aber die Kultur hatte sich nicht verändert. Ein Mindset, das niemand wirklich trägt, verändert nichts. Transformation, die nicht verankert wird, hinterlässt keine Spur.
Transform & Thrive
Über das Projekt hinausdenken.
Das KI-Projekt ohne Use Case ist das deutlichste Bild. Infrastruktur beschafft, Budget freigegeben, Pilotphase gestartet — ohne zu wissen, welchen Business-Wert die KI liefern soll. Ein Projekt, das nicht über sich selbst hinausdenkt, ist eine verpasste Chance — nicht nur für die Organisation, auch für die Menschen darin.
Was bleibt

ARCHITECT9 — ein Kompass, kein weiteres Framework

Was ARCHITECT9 wirklich ist

ARCHITECT9 ist kein weiteres Framework. Es ist ein systemtheoretisch fundierter Prinzipienrahmen für Change Competence — ein strategischer Kompass für wirksamen Wandel im Zeitalter der KI und der Digitalisierung.

Es arbeitet mit jedem bestehenden Methoden-Set — PMBOK, PRINCE2, Scrum, SAFe — und macht es wirksamer, indem es das Denken dahinter schärft.

Nach IQ und EQ ist C² — Change Competence — die Schlüsselkompetenz, die Führungskräfte und Projektverantwortliche heute wirklich brauchen. Nicht die Fähigkeit, Veränderung zu planen — sondern die Fähigkeit, sie zu gestalten. Im Unklaren. Im Widerspruch. Unter Druck.

Projekte sind die Mikrosysteme des Wandels.
Wer sie meistert, gestaltet die Zukunft.

Éva Almási – Gründerin Commonblue

Éva Almási

Gründerin Commonblue · Entwicklerin ARCHITECT9™

Mit über 25 Jahren Erfahrung als Projekt- und Programmmanagerin, Transformationsownerin und Digitalisierungsverantwortliche in der Telekommunikations- und Technologiebranche begleitet sie Führungskräfte, Projektteams und Organisationen dabei, Projekte nicht nur zu managen — sondern wirklich zu meistern.

PMP Business Agility Coach SAFe SPC Agile Trainerin