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.
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ß.
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.
40 Systeme — und die Lücken dazwischen
Im selben Umfeld: die Integration von 40 Systemen. Rechnungssysteme, CRM, Network-Commands. Jede Komponente wird einzeln betrachtet — 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.
Das eCommerce-Projekt — der Moment, der alles veränderte
Ein komplexes Projekt, parallel geführt auf zwei Plattformen. Das klassische PM-Team vertraute dem agilen Vorgehen nicht: kein GANTT-Diagramm — also kein echtes Vertrauen. Man wollte einen Plan B. 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.
Transformation mit vollen Händen und leeren Rücken
Das erste: Management sagt 100% Ja. Trotzdem können Teammitglieder nur Teilzeit mitwirken, ein unerfahrener Transformation Lead wird eingesetzt, irgendwann gibt er auf. Die Transformation bleibt halbfertig.
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, maximale Auslastung überall.
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?
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.
Was wirklich benötigt wird
Systemtheorie allein genügt nicht. Was Projekte heute brauchen, ist keine weitere Methode — sondern drei Fähigkeiten, die in keinem Framework stehen, aber in jedem erfolgreichen Projekt vorhanden sind.
Systemisches Denken
Das Ganze sehen, bevor man eingreift. Projekte nicht als Aufgabenlisten begreifen, sondern als lebendige soziale Systeme mit eigener Logik, eigenen Spannungen, eigenen unsichtbaren Spielregeln.
Menschliche Klarheit
Commitment und Orientierung schaffen. In Unsicherheit nicht reaktiv werden, sondern bewusst führen — mit einem gemeinsamen Bild, das trägt.
Adaptive Kompetenz
In Unsicherheit handlungsfähig bleiben. Den Kurs anpassen, ohne sich zu verlieren. Aus Lernschleifen echte Konsequenzen ziehen.
Diese drei Dimensionen bilden das Fundament von C² — Change Competence: die Fähigkeit, in Komplexität, Unsicherheit und Widerspruch wirksam zu handeln. Nicht die Fähigkeit, ein Projekt zu planen, sondern die Fähigkeit, es zu gestalten.
Nach IQ und EQ ist C² die Schlüsselkompetenz, die Führungskräfte heute wirklich brauchen. Nicht die Fähigkeit, Veränderung zu planen. Sondern die Fähigkeit, sie zu gestalten — mit Menschen, die unterschiedliche Realitäten bewohnen, unter Druck, im Widerspruch, im Unklaren.
ARCHITECT9™ ist der Prinzipienrahmen, der C² trainierbar und anwendbar macht — für Einzelpersonen, Teams und Organisationen.
ARCHITECT9™ — neun Prinzipien, ein Kompass
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.
ARCHITECT9™ ist kein Ersatz für PMBOK, PRINCE2, Scrum oder SAFe. Es ist der Prinzipienrahmen, der diese Methoden wirksam macht — indem er das Denken schärft, bevor die Methode greift. Ein Kompass, der in der Komplexität des Projektalltags die Richtung zeigt.
ARCHITECT9™ · Human Excellence · Technical Excellence · Adaptive Excellence · © Commonblue
Drei Exzellenzen. Neun Prinzipien. Ein Rahmen.
Die neun Prinzipien sind in drei Exzellenzen organisiert, die gemeinsam das Fundament für wirksame Transformation bilden. Keine Exzellenz allein reicht — erst ihr Zusammenspiel macht ARCHITECT9™ zu einem ganzheitlichen Rahmen.
Human Excellence stellt sicher, dass Menschen wirklich mitgehen — nicht weil sie müssen, sondern weil sie wollen. Technical Excellence sorgt dafür, dass Struktur und Prozesse auch unter Druck halten. Adaptive Excellence macht Organisationen, Teams und Menschen dauerhaft wandlungsfähig.
Human Excellence
Menschen sind der entscheidende Faktor — immer. Mindset, Haltung, Führungskultur und echtes Commitment bilden die menschliche Grundlage, ohne die keine Transformation trägt.
Technical Excellence
Struktur und Prozesse müssen auch unter Druck halten. Klarheit in Zielen, Rollen, Entscheidungswegen und Roadmaps — damit das Projekt seinen Kurs behält.
Adaptive Excellence
Anpassungsfähigkeit ist heute keine Option mehr — sie ist Überlebensstrategie. Organisationen, Teams und Menschen in Komplexität und Unsicherheit handlungsfähig halten.
A · R · C · H · I · T · E · C · T — aus der Praxis destilliert
Das ist keine einmalige Aufgabe zu Projektbeginn. Es ist eine dauerhafte Haltung. Analyse & Ausrichtung schafft das gemeinsame Bild, das alle anderen Prinzipien trägt. Ohne dieses Bild arbeiten Teams aneinander vorbei — methodisch sauber, aber systemisch blind.
Anfang der 2000er-Jahre, Telekommunikationsbranche. Ein externes Team führt ein CRM-System ein — methodisch korrekt, sorgfältig dokumentiert. Was niemand analysiert hat: das Systemökosystem. Viele Anforderungen wurden bereits von bestehenden Systemen erfüllt. Menschen im Unternehmen wussten das — aber sie wurden nicht gefragt. Das Ergebnis: Ein paralleles System wurde gebaut, das dieselben Services anbot, die schon da waren. Das Projekt scheiterte nicht am Wissen. Es scheiterte, weil das vorhandene Wissen im System unsichtbar blieb.
Das klingt nach Intuition — ist aber trainierbar. Es geht darum, die richtigen Fragen zu stellen, bevor etwas eskaliert: Wo sind die Übergaben zwischen Teams, Systemen oder Verantwortlichkeiten? Welche Annahmen werden gemacht, ohne sie je überprüft zu haben? Risiko-Früherkennung verbindet strukturierte Analyse mit dem Mut, dorthin zu schauen, wo niemand hinschaut.
Die Integration von 40 Systemen — Rechnungssysteme, CRM, Network-Commands. Jede Komponente wird einzeln betrachtet, isoliert spezifiziert, isoliert getestet. Einzelne Teile funktionieren. Das Gesamtsystem nicht. Die Lücken entstehen genau dort, wo die Übergaben stattfinden — zwischen den Systemen, an den Schnittstellen. Weil die Lücken zu keinem Modul gehören, gehören sie niemandem. Seitdem ist eine der ersten Fragen, die ich stelle: Wo sind die Übergaben — und wer ist für die Lücken dazwischen verantwortlich?
Dieses Prinzip stellt unbequeme Fragen: Ist das ausgesprochene Commitment auch ein gelebtes? Sind Rollen, Ziele und Entscheidungswege wirklich klar — oder nur angenommen? Stimmen die bereitgestellten Ressourcen mit dem überein, was offiziell zugesagt wurde? Commitment & Klarheit schützt Teams vor der häufigsten Enttäuschung im Projektalltag: dem Gefühl, mit vollen Händen zu arbeiten — und trotzdem keinen Rückhalt zu haben.
Zwei agile Transformationsprojekte, beide mit derselben Ausgangslage. Im ersten: Management sagt 100% Ja — Teammitglieder können nur Teilzeit mitwirken, ein unerfahrener Lead gibt irgendwann auf. Im zweiten: Lokale Transformation Owner ohne Agile Coaches, Teilnahme nur in der „Freizeit", kein priorisiertes Portfolio. Beide Male dasselbe Muster: Guter Wille wurde mit Commitment verwechselt. Und ein Mindset, das niemand wirklich trägt, verändert nichts.
Wer Handlungsfähigkeit sichert, fragt nicht nur: „Wer ist verantwortlich?" — sondern auch: „Hat diese Person überhaupt die Mittel, ihre Verantwortung wahrzunehmen?" Das schützt vor einem der häufigsten Projektfehler: das Scheitern als menschliches Versagen zu interpretieren, obwohl das System strukturell nie handlungsfähig war.
Im zweiten Transformationsprojekt gibt es keine Agile Coaches, keine echte Kapazität, kein priorisiertes Portfolio. Maximale Auslastung überall. Die Transformation Owner nehmen teil — in ihrer Freizeit. Das ist kein Commitment-Problem. Das ist ein strukturelles Problem: Die Rahmenbedingungen machen Handlungsfähigkeit von Anfang an unmöglich. Die Transformation kommt nicht voran — nicht weil die Menschen nicht wollen, sondern weil das System sie nicht lässt.
In der Praxis bedeutet das: regelmäßige, ehrliche Reflexion — nicht als Pflichtformat, sondern als echten Lernimpuls. Die Bereitschaft, den Kurs anzupassen, ohne das Ziel zu verlieren. Und den Mut, auch aus Erfolgen zu lernen — nicht nur aus Fehlern.
Das eCommerce-Projekt zeigt, was passiert, wenn man Komplexität mit einem starren Plan kontrollieren will. Das klassische Team plant wochenlang einen Plan B — aufwändig, detailliert, ressourcenintensiv. Das agile Teilprojekt denkt in Iterationen, passt sich an, lernt aus jedem Sprint. Am Ende ist es früher fertig. Plan B wird nie benötigt. Der Unterschied liegt nicht in der Disziplin — sondern in der Grundannahme: Das agile Team hat mit Veränderung gerechnet. Das klassische Team hat versucht, sie zu verhindern.
Transparenz schaffen bedeutet nicht, alles zu teilen. Es bedeutet, das Richtige sichtbar zu machen: Ziele, Risiken, Entscheidungsgrundlagen, den tatsächlichen Stand. Und es bedeutet, eine Kultur zu schaffen, in der es sicher ist, Probleme früh anzusprechen — bevor sie eskalieren.
Im eCommerce-Projekt schaut das klassische PM-Team und das agile Team auf dasselbe Projekt — und sehen etwas völlig anderes. Die einen sehen ein Vorhaben auf Kurs. Die anderen sehen ein Risiko ohne GANTT-Diagramm. Kein gemeinsames Bild, kein gemeinsames Verständnis. Plan B entsteht — nicht weil das Projekt ihn braucht, sondern weil das Vertrauen fehlt, das nur ein gemeinsames Bild hätte geben können.
Empowerment bedeutet konkret: Menschen nicht nur zu informieren, sondern ihnen tatsächlich Entscheidungsraum zu geben. Widerstand nicht als Problem zu behandeln, sondern als Signal, das das System sendet. Wer echtes Empowerment praktiziert, braucht weniger Kontrolle — weil das System von innen heraus trägt.
Im eCommerce-Projekt wissen wir früh und sicher, dass Plan B technisch nicht funktionieren wird. Wir sagen es — klar, frühzeitig, mit Begründung. Man glaubt uns nicht. Wochenlange Meetings, enorme Ressourcen, detaillierte Planung für eine Lösung, die selbst im Einsatz gescheitert wäre. Das agile Projekt ist früher fertig. Plan B wird nie gebraucht. Was wäre passiert, wenn die, die es wussten, wirklich gehört worden wären?
Dieses Prinzip erfordert, Lernkultur nicht als Nebenprodukt zu behandeln, sondern als explizites Projektziel. Es bedeutet, Routinen zu schaffen, die auch nach dem Projektabschluss tragen — und die Menschen in ihrer Entwicklung zu begleiten, nicht nur während des Projekts, sondern in dem, was danach kommt.
Beide Transformationsprojekte enden mit demselben Ergebnis: halbfertiger Wandel. Die Projekte sind abgeschlossen — aber die Kultur hat sich nicht verändert. Neue Methoden wurden eingeführt — aber niemand hat sie wirklich verinnerlicht. Transformation, die nicht verankert wird, hinterlässt keine Spur. Was gebaut wurde, wird langsam wieder abgetragen — von der alten Logik, die nie wirklich überwunden wurde.
In einer Welt, in der Veränderung der Normalzustand ist, reicht es nicht, Projekte zu liefern. Es braucht Projekte, die die Kapazität zur Veränderung selbst stärken. Transform & Thrive macht aus einem Projekt nicht nur ein Ergebnis — sondern einen Ausgangspunkt.
Das KI-Projekt ist das klarste Bild dieses Prinzips — in seiner Abwesenheit. Infrastruktur ist beschafft, Budget freigegeben, Pilotphase gestartet. Aber niemand hat die entscheidenden Fragen gestellt: Welchen Business-Wert soll die KI liefern? Wer entscheidet, wenn das Modell empfiehlt — und wer ist verantwortlich, wenn es falsch liegt? Was lernt die Organisation aus diesem Projekt für die nächste Initiative? Ein Projekt, das nicht über sich selbst hinausdenkt, ist eine verpasste Chance — nicht nur für die Organisation, auch für die Menschen darin.
Veränderung findet nicht auf einer Ebene statt.
Sie passiert in Projekten, in Teams und Organisationen — und in jedem einzelnen Menschen. Deshalb wirkt ARCHITECT9™ auf allen drei Ebenen gleichzeitig, nicht nacheinander.
ChangeARCHITECT9™
Für die gesamte Organisation, die lernen muss, Wandel nicht zu erleiden, sondern zu gestalten. Wandlungsfähigkeit als dauerhafte Kompetenz verankern — über einzelne Projekte hinaus.
ProjektARCHITECT9™
Orientierung, Fokus und Dynamik in jede Projektumgebung. Von der Initiierung bis zur Übergabe — Risiken früh sichtbar machen, Rollen klären, Teams handlungsfähig halten.
ARCHITECT9™-4YOU
Echte Transformation beginnt innen. Für jeden Menschen, der in Komplexität nicht nur reagieren, sondern gestalten und wachsen will.
Die drei Ebenen verstärken sich gegenseitig: Ein Team, das systemisch denken gelernt hat, verändert auch die Organisation. Eine Führungskraft, die persönlich gewachsen ist, schafft ein anderes Projektklima. Eine Organisation, die Wandel als Kompetenz verankert hat, gibt ihren Projekten den nötigen Rückenwind.
Ein Projekt, das auf Projektebene perfekt gesteuert wird, aber in einer Organisation stattfindet, die nicht gelernt hat, Wandel als Kompetenz zu verankern, wird seine Wirkung verlieren. Das ist der Unterschied zwischen einem gut geführten Projekt und einem wirklich transformativen Projekt.
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.
